PartitionMagic crash in data movement phase

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

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

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

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

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