PartitionMagic crash in data movement phase

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

I had PM8.01 crash in the data movement phase of a NTFS partition move.
Symantec support after four days has said I must use third party data
recovery tools to try and recover the data. I am looking for
suggestions on recovery tools at this point. Does anyone sell a data
recovery tool that is specialized for PM8 crashes?

I am a little surprised they don't have a data recovery tool for this
case.


Here is what has happened:

I had an extra ~40Gig of unused space in front of a ~30Gig NTFS XP
partition on my disk. I decided to use PM8 to move the partition to the
front of the disk. During the data movement phase of the partition
move, PM8 hung with about 16% of the data moved (caps and num lock keys
had no response on the keyboard, and it had been running for eight hours).

I rebooted at this point and PM8 found the a new ~70Gig partition of
type 3C. I then found the document "Fixing a Recoverable Partition with
PTEDIT" and changed the partition type back to 07 for NTFS.

Running PM8.01 on the disk shows two partitions:

Size Used Unused
69,013.6 9,365.5 20,638.7 Active Prim
121,766.1 117,637.6 4,128.5 None Prim

Running show info on the first partition returns these errors:

Error #1602 - File table backup mismatch
Error #1602 - File table backup mismatch (2nd time)
Error #1602 - File table backup mismatch (3rd time)
Error #1627 - Upcase table incorrect, file 10 (128)

PM then appears to hang, but later crashes and goes back to the dos
prompt.

I have not tried to boot XP.


Any help/suggestions would be appreciated.

Thanks,
Chris
5 answers Last reply
More about partitionmagic crash data movement phase
  1. Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

    I suggest you use Partition Table Doctor to resolve your
    problem.The software provides very useful functions:
    Backup partition table, Restore partition table, Rebuild
    partition table, undelete partition, Fix boot sector,
    rebuild mbr,etc.

    First thing I recommend you download the demo version of
    Partition Table Doctor.( http://www.ptdd.com/download.htm )

    Run the program and select "Rebuild Partition Table",
    then choose "Interactive" mode. If you can find the partition
    you need, that is Partition Table Doctor can help you. Otherwise,
    Partition Table Doctor cannot help you.

    See more: http://www.ptdd.com/recoverylostpartition.htm
    http://www.ptdd.com/recoverdeletedpartition.htm
    http://www.ptdd.com/partition-recovery.htm
  2. Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

    Chris Fisher <chfisher@att.net> wrote:

    > I had PM8.01 crash in the data movement phase of a NTFS partition move.
    > Symantec support after four days has said I must use third party data
    > recovery tools to try and recover the data. I am looking for
    > suggestions on recovery tools at this point. Does anyone sell a data
    > recovery tool that is specialized for PM8 crashes?

    None that I know.

    > I am a little surprised they don't have a data recovery tool for this
    > case.
    >
    > Here is what has happened:
    >
    > I had an extra ~40Gig of unused space in front of a ~30Gig NTFS XP
    > partition on my disk. I decided to use PM8 to move the partition to the
    > front of the disk. During the data movement phase of the partition
    > move, PM8 hung with about 16% of the data moved (caps and num lock keys
    > had no response on the keyboard, and it had been running for eight hours).

    From the next part of your post seems that you not only moved the higher
    partition to the 40 GB space, but also unified the two and resized the combined
    partition to contain the space of the two. It would be wiser if you first moved
    the higher partition to the lower unallocated space, and on completion of phase
    one, combined and resized the two partitions involved.

    > I rebooted at this point and PM8 found the a new ~70Gig partition of
    > type 3C. I then found the document "Fixing a Recoverable Partition with
    > PTEDIT" and changed the partition type back to 07 for NTFS.
    >
    > Running PM8.01 on the disk shows two partitions:
    >
    > Size Used Unused
    > 69,013.6 9,365.5 20,638.7 Active Prim
    > 121,766.1 117,637.6 4,128.5 None Prim

    What is the total capacity of the drive? What is the configuration of that
    drive? Are there other drives installed as well? Configuration? What's the
    OS? Anything else except XP?

    > Running show info on the first partition returns these errors:
    >
    > Error #1602 - File table backup mismatch
    > Error #1602 - File table backup mismatch (2nd time)
    > Error #1602 - File table backup mismatch (3rd time)
    > Error #1627 - Upcase table incorrect, file 10 (128)

    Expected, since PM crashed in the process.

    > PM then appears to hang, but later crashes and goes back to the dos
    > prompt.
    >
    > I have not tried to boot XP.

    To what *have* you booted then?

    > Any help/suggestions would be appreciated.

    The information provided is insufficient. Yet since the source partition is
    smaller than the destination one, and the "move" process crashed before
    completion, then it would be logical to assume that the original partition, with
    its data and configuration areas, are still intact on the disk. They just don't
    show because the partition table now reflects the PM doing.

    If all you are looking for is to recover the 30 GB partition that is now
    engulfed in the new 70 GB partition, and *on condition* that the rest of the
    drive is unallocated, then here is a plan that may work.

    1. Backup the current MBR (the standard practice I use is backup to sector 63 on
    track 0, with RESQDISK).

    2. Then, rebuild the MBR with RESQDISK /NTFS /REBUILD, after you made sure that
    the extended partition at 40 GB offset does show on an idle run of RESQDISK (no
    writing to the drive!).

    3. Reboot and see if the partition is now visible.

    Warning! DO NOT LET XP'S CHKDSK TO TOUCH ANYTHING ON STARTUP !!! If you do,
    then you'll drop the ball on the finish line because it will try to "resolve"
    the mismatch caused by the presence of a 70 GB partition (in the boot sector)
    with the 40 GB allocated to in the MBR. Also, do NOT try PTEDIT yet because the
    *reported* size of the resurfaced partition will be incorrect. Which should not
    prevent your data from showing properly in the recovered partition.

    That should do for now as first lesson in data recovery. TBC (to be continued).

    Regards, Zvi
    --
    NetZ Computing Ltd. ISRAEL www.invircible.com www.ivi.co.il (Hebrew)
    InVircible Virus Defense Solutions, ResQ and Data Recovery Utilities
  3. Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

    Zvi Netiv <support@replace_with_domain.com> wrote:

    > Chris Fisher <chfisher@att.net> wrote:
    >
    > > I had PM8.01 crash in the data movement phase of a NTFS partition move.
    > > Symantec support after four days has said I must use third party data
    > > recovery tools to try and recover the data. I am looking for
    > > suggestions on recovery tools at this point. Does anyone sell a data
    > > recovery tool that is specialized for PM8 crashes?
    >
    > None that I know.
    >
    > > I am a little surprised they don't have a data recovery tool for this
    > > case.
    > >
    > > Here is what has happened:
    > >
    > > I had an extra ~40Gig of unused space in front of a ~30Gig NTFS XP
    > > partition on my disk. I decided to use PM8 to move the partition to the
    > > front of the disk. During the data movement phase of the partition
    > > move, PM8 hung with about 16% of the data moved (caps and num lock keys
    > > had no response on the keyboard, and it had been running for eight hours).
    >
    > From the next part of your post seems that you not only moved the higher
    > partition to the 40 GB space, but also unified the two and resized the combined
    > partition to contain the space of the two. It would be wiser if you first moved
    > the higher partition to the lower unallocated space, and on completion of phase
    > one, combined and resized the two partitions involved.
    >
    > > I rebooted at this point and PM8 found the a new ~70Gig partition of
    > > type 3C. I then found the document "Fixing a Recoverable Partition with
    > > PTEDIT" and changed the partition type back to 07 for NTFS.
    > >
    > > Running PM8.01 on the disk shows two partitions:
    > >
    > > Size Used Unused
    > > 69,013.6 9,365.5 20,638.7 Active Prim
    > > 121,766.1 117,637.6 4,128.5 None Prim
    >
    > What is the total capacity of the drive? What is the configuration of that
    > drive? Are there other drives installed as well? Configuration? What's the
    > OS? Anything else except XP?
    >
    > > Running show info on the first partition returns these errors:
    > >
    > > Error #1602 - File table backup mismatch
    > > Error #1602 - File table backup mismatch (2nd time)
    > > Error #1602 - File table backup mismatch (3rd time)
    > > Error #1627 - Upcase table incorrect, file 10 (128)
    >
    > Expected, since PM crashed in the process.
    >
    > > PM then appears to hang, but later crashes and goes back to the dos
    > > prompt.
    > >
    > > I have not tried to boot XP.
    >
    > To what *have* you booted then?
    >
    > > Any help/suggestions would be appreciated.
    >
    > The information provided is insufficient. Yet since the source partition is
    > smaller than the destination one, and the "move" process crashed before
    > completion, then it would be logical to assume that the original partition, with
    > its data and configuration areas, are still intact on the disk. They just don't
    > show because the partition table now reflects the PM doing.
    >
    > If all you are looking for is to recover the 30 GB partition that is now
    > engulfed in the new 70 GB partition, and *on condition* that the rest of the
    > drive is unallocated, then here is a plan that may work.
    >
    > 1. Backup the current MBR (the standard practice I use is backup to sector 63 on
    > track 0, with RESQDISK).
    >
    > 2. Then, rebuild the MBR with RESQDISK /NTFS /REBUILD, after you made sure that
    > the extended partition at 40 GB offset does show on an idle run of RESQDISK (no
    > writing to the drive!).

    *** Forgot to add important info here: The problem drive must be connected as
    the ONLY drive when running the above command. ***

    > 3. Reboot and see if the partition is now visible.
    >
    > Warning! DO NOT LET XP'S CHKDSK TO TOUCH ANYTHING ON STARTUP !!! If you do,
    > then you'll drop the ball on the finish line because it will try to "resolve"
    > the mismatch caused by the presence of a 70 GB partition (in the boot sector)
    > with the 40 GB allocated to in the MBR. Also, do NOT try PTEDIT yet because the
    > *reported* size of the resurfaced partition will be incorrect. Which should not
    > prevent your data from showing properly in the recovered partition.
    >
    > That should do for now as first lesson in data recovery. TBC (to be continued).

    Regards
    --
    NetZ Computing Ltd. ISRAEL www.invircible.com www.ivi.co.il (Hebrew)
    InVircible Virus Defense Solutions, ResQ and Data Recovery Utilities
  4. Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

    Zvi Netiv wrote:
    > Zvi Netiv <support@replace_with_domain.com> wrote:
    >
    >
    >>Chris Fisher <chfisher@att.net> wrote:
    >>
    >>
    >>>I had PM8.01 crash in the data movement phase of a NTFS partition move.
    >>> Symantec support after four days has said I must use third party data
    >>>recovery tools to try and recover the data. I am looking for
    >>>suggestions on recovery tools at this point. Does anyone sell a data
    >>>recovery tool that is specialized for PM8 crashes?
    >>
    >>None that I know.
    >>
    >>
    >>>I am a little surprised they don't have a data recovery tool for this
    >>>case.
    >>>
    >>>Here is what has happened:
    >>>
    >>>I had an extra ~40Gig of unused space in front of a ~30Gig NTFS XP
    >>>partition on my disk. I decided to use PM8 to move the partition to the
    >>>front of the disk. During the data movement phase of the partition
    >>>move, PM8 hung with about 16% of the data moved (caps and num lock keys
    >>>had no response on the keyboard, and it had been running for eight hours).
    >>
    >>From the next part of your post seems that you not only moved the higher
    >>partition to the 40 GB space, but also unified the two and resized the combined
    >>partition to contain the space of the two. It would be wiser if you first moved
    >>the higher partition to the lower unallocated space, and on completion of phase
    >>one, combined and resized the two partitions involved.
    >>

    I only asked PM8 to move the partition. I assume after the data move,
    PM8 would update the partition table to show only a new partition with
    the moved data at the lower end of the disk.

    >>
    >>>I rebooted at this point and PM8 found the a new ~70Gig partition of
    >>>type 3C. I then found the document "Fixing a Recoverable Partition with
    >>>PTEDIT" and changed the partition type back to 07 for NTFS.
    >>>
    >>>Running PM8.01 on the disk shows two partitions:
    >>>
    >>>Size Used Unused
    >>>69,013.6 9,365.5 20,638.7 Active Prim
    >>>121,766.1 117,637.6 4,128.5 None Prim
    >>
    >>What is the total capacity of the drive? What is the configuration of that
    >>drive? Are there other drives installed as well? Configuration? What's the
    >>OS? Anything else except XP?
    >>

    It is a 200Gig drive (SATA) with second 120Gig NTFS partition at the end
    of the disk. I have linux installed on a second disk (IDE).


    >>
    >>>Running show info on the first partition returns these errors:
    >>>
    >>>Error #1602 - File table backup mismatch
    >>>Error #1602 - File table backup mismatch (2nd time)
    >>>Error #1602 - File table backup mismatch (3rd time)
    >>>Error #1627 - Upcase table incorrect, file 10 (128)
    >>
    >>Expected, since PM crashed in the process.
    >>
    >>
    >>>PM then appears to hang, but later crashes and goes back to the dos
    >>>prompt.
    >>>
    >>>I have not tried to boot XP.
    >>
    >>To what *have* you booted then?
    >>

    I have booted nothing from this disk. I have seen some posts which
    recommended fixing the partition type back to the original and then
    trying to boot your OS. After seeing PM8's difficulties with the
    filesystem, I assumed this would be a bad idea.

    >>
    >>>Any help/suggestions would be appreciated.
    >>
    >>The information provided is insufficient. Yet since the source partition is
    >>smaller than the destination one, and the "move" process crashed before
    >>completion, then it would be logical to assume that the original partition, with
    >>its data and configuration areas, are still intact on the disk. They just don't
    >>show because the partition table now reflects the PM doing.
    >>
    >>If all you are looking for is to recover the 30 GB partition that is now
    >>engulfed in the new 70 GB partition, and *on condition* that the rest of the
    >>drive is unallocated, then here is a plan that may work.
    >>
    >>1. Backup the current MBR (the standard practice I use is backup to sector 63 on
    >>track 0, with RESQDISK).
    >>
    >>2. Then, rebuild the MBR with RESQDISK /NTFS /REBUILD, after you made sure that
    >>the extended partition at 40 GB offset does show on an idle run of RESQDISK (no
    >>writing to the drive!).
    >
    >
    > *** Forgot to add important info here: The problem drive must be connected as
    > the ONLY drive when running the above command. ***
    >

    The data on the upper 120Gig partition is important at this point, so
    the above procedure is not recommended, I assume.

    >
    >>3. Reboot and see if the partition is now visible.
    >>
    >>Warning! DO NOT LET XP'S CHKDSK TO TOUCH ANYTHING ON STARTUP !!! If you do,
    >>then you'll drop the ball on the finish line because it will try to "resolve"
    >>the mismatch caused by the presence of a 70 GB partition (in the boot sector)
    >>with the 40 GB allocated to in the MBR. Also, do NOT try PTEDIT yet because the
    >>*reported* size of the resurfaced partition will be incorrect. Which should not
    >>prevent your data from showing properly in the recovered partition.
    >>
    >>That should do for now as first lesson in data recovery. TBC (to be continued).
    >
    >
    > Regards
    > --
    > NetZ Computing Ltd. ISRAEL www.invircible.com www.ivi.co.il (Hebrew)
    > InVircible Virus Defense Solutions, ResQ and Data Recovery Utilities

    Thanks for the help.

    Chris
  5. Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

    Chris Fisher <chfisher@att.net> wrote:
    > > Zvi Netiv <support@replace_with_domain.com> wrote:

    > >>>I had PM8.01 crash in the data movement phase of a NTFS partition move.
    [...]
    > >>>Here is what has happened:
    > >>>
    > >>>I had an extra ~40Gig of unused space in front of a ~30Gig NTFS XP
    > >>>partition on my disk. I decided to use PM8 to move the partition to the
    > >>>front of the disk. During the data movement phase of the partition
    > >>>move, PM8 hung with about 16% of the data moved (caps and num lock keys
    > >>>had no response on the keyboard, and it had been running for eight hours).
    > >>
    > >>From the next part of your post seems that you not only moved the higher
    > >>partition to the 40 GB space, but also unified the two and resized the combined
    > >>partition to contain the space of the two. It would be wiser if you first moved
    > >>the higher partition to the lower unallocated space, and on completion of phase
    > >>one, combined and resized the two partitions involved.
    >
    > I only asked PM8 to move the partition. I assume after the data move,
    > PM8 would update the partition table to show only a new partition with
    > the moved data at the lower end of the disk.'

    The 70 GB partition is then a frozen-in-time snapshot of how PM does it. The
    big question is if PM does also preserve the system area of the source partition
    till the end of the process, or kills these areas right on start. This can be
    verified easily with a RESQDISK /ASSESS /NTFS /2 run and posting the report
    here (see these threads for the details of the procedure
    http://tinyurl.com/ccl3k ).

    The above test will provide data for patching the partition table manually and
    resurface the missing partition.

    > >>What is the total capacity of the drive? What is the configuration of that
    > >>drive? Are there other drives installed as well? Configuration? What's the
    > >>OS? Anything else except XP?
    >
    > It is a 200Gig drive (SATA) with second 120Gig NTFS partition at the end
    > of the disk. I have linux installed on a second disk (IDE).

    OK. Pay attention to the "/2" parameter in the assess command, above, it's for
    the drive being second.

    [...]
    > >>To what *have* you booted then?
    >
    > I have booted nothing from this disk. I have seen some posts which
    > recommended fixing the partition type back to the original and then
    > trying to boot your OS. After seeing PM8's difficulties with the
    > filesystem, I assumed this would be a bad idea.

    In the wrong direction ... ;)

    [...]
    > The data on the upper 120Gig partition is important at this point, so
    > the above procedure is not recommended, I assume.

    The general plan is still to resurface the missing partition, but without
    ignoring the upper ones. BTW, forgot to ask if the upper partitions (linux and
    NTFS) are visible from their respective OS?

    > Thanks for the help.

    We aren't through yet! ;)

    Regards, Zvi
    --
    NetZ Computing Ltd. ISRAEL www.invircible.com www.ivi.co.il (Hebrew)
    InVircible Virus Defense Solutions, ResQ and Data Recovery Utilities
Ask a new question

Read More

Data Recovery Partition Crash Storage