PartitionMagic crash in data movement phase
in [Storage]
|
From: Chris Fisher on 15 Jun 2005 17:27 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
From: wemaole on 16 Jun 2005 02:31 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
From: Zvi Netiv on 16 Jun 2005 06:09 Chris Fisher <chfisher(a)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
From: Zvi Netiv on 16 Jun 2005 07:36 Zvi Netiv <support(a)replace_with_domain.com> wrote: > Chris Fisher <chfisher(a)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
From: Chris Fisher on 16 Jun 2005 10:09 Zvi Netiv wrote: > Zvi Netiv <support(a)replace_with_domain.com> wrote: > > >>Chris Fisher <chfisher(a)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
|
Pages: 1 Prev: Win SP2 conflict with Pen Drive Next: Real-world comparisons between SATA 150 and SATA 300 |