PartitionMagic crash in data movement phase

  • Thread starter Thread starter Chris Fisher
  • Start date Start date
C

Chris Fisher

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
 
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
 
Chris Fisher said:
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?
Click to expand...

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).
Click to expand...

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
Click to expand...

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)
Click to expand...

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.
Click to expand...

To what *have* you booted then?
Any help/suggestions would be appreciated.
Click to expand...

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
 
Zvi Netiv said:
None that I know.


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.


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?


Expected, since PM crashed in the process.


To what *have* you booted then?


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!).
Click to expand...

*** 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).
Click to expand...

Regards
 
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.

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).


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.
*** Forgot to add important info here: The problem drive must be connected as
the ONLY drive when running the above command. ***
Click to expand...

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

Thanks for the help.

Chris
 
Chris Fisher said:
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.
Click to expand...
Click to expand...

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.'
Click to expand...

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.
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).
Click to expand...

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

[...]
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.
Click to expand...

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.
Click to expand...

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.
Click to expand...

We aren't through yet! ;)

Regards, Zvi
 
Back
Top