Diskpatch hangs rebuilding partition table and boot sector

[wire_weaver]

Hi there,

After reading through the Main Guides [1], I need to rebuild the boot sector of a Windows 7 installation on a HDD.  I identified and labelled 2 of the 3 corrupted partition tables OK using the program Testdisk, however when I then use Diskpatch to rebuild the damaged boot sector Diskpatch hangs (with 0% progress) showing a histogram of cluster sizes when trying to determine the NTFS Cluster Size.  I have lots of screen shots showing where it hangs etc, but this forum won't let me attach files.

The DP.LOG file is empty as are the DP.LO1 to DP.LO5 files.  If I opt to manually select the cluster size of 8 sectors per cluster (the one with the highest value in the automatic histogram), it also hangs right after that with 0% progress.

Another unusual symptom is that when I opt to rebuild the partition tables, it then starts to analyse the disk but after only about 5 seconds it freezes at the following entries:

Range : 0 to 976773167
Current Sector - 450560
Read Errors - 0
Items Found - 2
Time Remaining - 133:15

BTW I couldn't use the FreeDOS version of Diskpatch as it hung at a very early point during launch,  so I had to use the Win-98 DOS version as per another reply from a moderator I found on this forum. 

rgds
Peter

[1] http://www.diydatarecovery.nl/dp_manual/guides_main.htm

[Joep]

Hello,

Most likely cause is a read error: apart from lack of available memory there isn't much that can hang DiskPatch as all routines are very sequential and straight forward. You could try running a read/only surface scan against that partition/area to verify that.

[wire_weaver]

Hi Joep,

Thanks for your reply.  I suspect you are correct and that it is a read error.  I will soon confirm this for sure, if it is a read error do I use something like chkdsk to repair this ?

regards
Peter

[Joep]

Hello,

Chkdsk wil not make read errors go away.

Best solution would be to clone the disk, it is the most secure way to deal with disks with read errors. An alternative is to run a read/write surface scan:
http://www.diydatarecovery.nl/dp_manual/surface_scanning.htm

[wire_weaver]

Thanks again Joep. 

What does the following chkdsk flag mean ?

"  /F              Fixes errors on the disk."

regards
Peter

[Joep]

Hello,

/f fixes file system inconsistencies, not files and/or disks themselves. If it has to delete files in order to achieve file system consistency it will do so.

[wire_weaver]

I tried doing a read only surface scan and only when selecting the custom sector range did the scan actually progress albeit for a short 20 seconds until it hung.   I tried setting the number of read retries to 0 and the error threshold to 1, but it still hung.

If I did the entire partition (rather than just a custom selection) it comes up with an error message indicating the MBR is corrupt.   I look at your guide and you suggest to rebuild the partition tables if the MBR is corrupt.  Is that what I should now do ?  Why not just rebuild the MBR ?

rgds
Peter

[Joep]

Is that what I should now do ?  Why not just rebuild the MBR ?

I can't tell. I thought that was tried and didn't work, right?

Basically I can't suggest anything because we do not have a logfile, logfiles are our 'eyes' so to speak.

I tried doing a read only surface scan and only when selecting the custom sector range did the scan actually progress albeit for a short 20 seconds until it hung.   I tried setting the number of read retries to 0 and the error threshold to 1, but it still hung.

How did you determine it's hanging? Since DiskPatch is in a single tasking environment (DOS), at some point when reading a disk sector it passes control to the system BIOS. At this point it will not respond to user input. Normally reading a sector happens so fast that you will not notice, but when reading a disk with read problems this process may take a while. DiskPatch passes control to the BIOS > the BIOS to the hard disk. Modern harddisks when encountering a read error will employ a whole array of tricks to read the problem sector and this may take from a few seconds upto minutes. In the end (if all's well) the disk reports a result to the BIOS, and then the BIOS reports back to DiskPatch.

Is the disk directly on a disk controller or connected through USB? Because USB adds yet another layer in between DiskPatch and the disk, and the USB interface ísn't known for handling read errors very well.

[wire_weaver]

I can't tell. I thought that was tried and didn't work, right

I haven't tried repairing the MBR yet, just the boot sectors with no success. I asked about repairing the MBR because it seems the logical thing to do if the MBR is reported as being corrupted rather than repairing the partition tables which is what your guide suggests.

Is the disk directly on a disk controller or connected through USB? Because USB adds yet another layer in between DiskPatch and the disk, and the USB interface ísn't known for handling read errors very well.

Direct to the laptop's main internal disk controller. I tried earlier via e-SATA but diskpatch couldn't see the drive when connected externally

[wire_weaver]

How did you determine it's hanging?

Sorry I forgot to answer this q. of yours.  I think it is hanging because during the custom surface scan (read only) the sector (or cluster?) count stops rapidly increasing and grinds to a halt at the same number each time then DiskPatch sits doing nothing for at least 5 minutes after which I reboot the laptop.

IT seems I need to repair bad sectors in the MBR and elsewhere.  Does the MBR get done first ?  I can't find any utility or menu option to repair the MBR in DeskPatch.  I tried previously with TestDisk but that took AGES and might have also hung from memory I can't remember.

rgds
Peter

[Tom]

I asked about repairing the MBR because it seems the logical thing to do if the MBR is reported as being corrupted rather than repairing the partition tables which is what your guide suggests.

It's the same thing: the MBR holds the partition tables, ergo repairing the partition tables means creating a new MBR. I'm just not sure I understand what you mean when you say the MBR is corrupt: does that point to a read error or to the fact that the MBR contains garbage? Please explain this.
As stated, without log files we are working in the dark. Any chance you can create a SMART log?
http://www.diydatarecovery.nl/dp_manual/guide_smartcheck.htm
It seems like a read problem, which points to a faulty disk, but it seems we can't confirm this. Any problems with other parts of the machine? Cables, power supply, other disks work ok, controller issues? Does the laptop have a diagnostic tool, and if so, what does that make of the situation? (if you start the diagnostics make sure you don't run any destructive disk tests!)

Post that SMART log first.

[wire_weaver]

I'm just not sure I understand what you mean when you say the MBR is corrupt: does that point to a read error or to the fact that the MBR contains garbage? Please explain this.

Here are the words (which appear with a white font in a red box) verbatim from DiskPatch when I run a read only surface scan of the OS partition:

The values for Start Location and/or Number of Sectors are invalid.  Make sure the MBR contains valid partition data.

That msg is suggesting that the MBR is corrupt.

Any problems with other parts of the machine? Cables, power supply, other disks work ok, controller issues? Does the laptop have a diagnostic tool, and if so, what does that make of the situation?

Coincidentally before this happened the power supply failed.  I then borrowed one which was from a few models prior, this seemed to work OK to power the laptop so I could run it and charge the battery again, so then I left it charging overnight with the laptop in standby (not off) and the next morning the problem with the HDD happened.   The next day I purchased the correct PS and have had no power problems since, but I can't help but wonder if something about using the older power supply caused the laptop to overheat overnight or something, I'm not sure.

One partition on the faulty HDD works OK, and it is to that I have been saving the Diskpatch log files.  I can't remember any tests in the laptop's BIOS, I will check the supplied CDs to see if there are some diagnostic tests I can run.  

Any chance you can create a SMART log?

I managed to run a S.M.A.R.T. report here are the contents:


Detected Controllers

  Disk Controller 1
    Device Vendor . . . . . . . . . . . . . : 8086
    Device ID . . . . . . . . . . . . . . . : 2929
    Device  . . . . . . . . . . . . . . . . : Intel
    Device Location . . . . . . . . . . . . : Bus 0, Device 31, Function 2
    Device Ports  . . . . . . . . . . . . . : 18F0-18F7, 18E4-18E7, 18E8-18EF, 18E0-18E3, 18C0-18DF

I also have a DP.LOG file FWIW (I'd attach it but this forum doesn't let me ! So instead I'm copying its contents below:)


.../000:27/LOG> ### LOG START ###
.../000:27/LOG> DISKPATCH 3.5.300
.../000:27/LOG> (C) 2000-2009 DIY DataRecovery
.../000:27/LOG> Contact info: http://HTTP://www.DIYDataRecovery.nl
.../000:27/LOG> MemFree: 56Kb
.../000:27/LOG> CommandLineParms: /sup
.../000:27/LOG> LogDate: 12-23-2010
.../000:27/CFG> FilePath="D:DPFILES\"
.../000:27/CFG> ReadRetries="32"
.../000:27/CFG> WriteRetries="32"
.../000:27/CFG> MaxReadErrors="32"
.../000:27/CFG> MaxWriteErrors="1"
.../000:27/CFG> LogEachReadError="1"
.../000:27/CFG> ReadDelay="0"
.../000:27/CFG> VfyFixedBadSect="1"
.../000:27/CFG> CleanAfterDOD="1"
.../000:27/CFG> DiskReset="1"
.../000:27/CFG> SectorSkip="1024"
.../000:27/CFG> AutoSaveState="1"
.../000:27/CFG> DumpFoundSectors="0"
.../000:27/CFG> FixFats="1"
.../000:27/CFG> MaxFatScan="51200"
.../000:27/CFG> MaxDataColEntries="256"
.../000:27/CFG> IgnoreF8FF="0"
.../000:27/CFG> DownSizeExt="1"
.../000:27/CFG> ScanSignature="55AA"
.../000:27/CFG> Rebuild="00"
.../000:27/13H> Ext13H installed test requested
.../000:27/13H> Disk found at 128
.../000:27/13H> Ext13H version: EDD-3.0
.../000:27/13H> Ext13H Support: Extended disk access functions
.../000:27/13H> Ext13H Support: Removable drive controller functions
.../000:27/13H> Ext13H Support: Enhanced disk drive functions
.../000:27/13H> Ext13H Flags: DMA boundary errors handled transparently
.../000:27/13H> Drive Interface Info:
.../000:27/13H> Disk 128 X13H data : 0/0/0 31272544/512
.../000:27/13H> Disk found at 129
.../000:27/13H> Ext13H version: EDD-3.0
.../000:27/13H> Ext13H Support: Extended disk access functions
.../000:27/13H> Ext13H Support: Enhanced disk drive functions
.../000:27/13H> Ext13H Flags: DMA boundary errors handled transparently
.../000:27/13H> Drive Interface Info:
.../000:27/13H> Disk 129 X13H data : 16383/16/63 976773168/512
.../000:27/13H> Ext13H tested ok
.../000:27/FDL> DiskList requested
.../000:27/FDL> Disk found at 128

[Tom]

Both logs are incomplete and tell nothing of interest (with regard to the problem disk), probably because of hanging/resetting. Though it is strange the SMART report is incomplete, that should at least report not being able to touch the disk. Are you sure you did that right and that you copy/pasted all the SMART log contents to the forum? Please verify this, because as is there isn't any advice to give; if accessing the disk isn't possible and there is no discernable cause for this, there's nowhere to go. All we can do is speculate, which leads to generic (previously drawn) conclusions: read problems > faulty disk > either clone or replace.

Just for reference, to give you an idea of what it's supposed to look like, this is a complete SMART log:
http://www.diydatarecovery.nl/forum/index.php/topic,687.0.html

There is something odd about the DP.log file. The first disk that DiskPatch sees has no characteristics:

.../000:27/13H> Drive Interface Info:
.../000:27/13H> Disk 128 X13H data : 0/0/0 31272544/512

The 0/0/0 should be something else (not 0). This could cause problems. What is that disk? It's not the problem disk, that's bigger. Could be the USB key you use to boot DiskPatch?

I'm not sure the power supply thing could cause this. Did you check the power supply output and the laptop's input requirements? It's possible an external PS could fry the loading systems and the battery in a laptop if the amp output is too high, though that would probably manifest itself differently (smoke and fire, I'd say). Though excessive heat would certainly have a negative effect on the whole laptop. In general it's not advisable to use (different) external power supply systems apart from the one delivered with the laptop.

[wire_weaver]

Both logs are incomplete and tell nothing of interest (with regard to the problem disk), probably because of hanging/resetting. Though it is strange the SMART report is incomplete, that should at least report not being able to touch the disk. Are you sure you did that right and that you copy/pasted all the SMART log contents to the forum? Please verify this,

OK I will repeat the test and log file copy.

.../000:27/13H> Drive Interface Info:
.../000:27/13H> Disk 128 X13H data : 0/0/0 31272544/512

The 0/0/0 should be something else (not 0). This could cause problems. What is that disk? It's not the problem disk, that's bigger.

It is the 3rd partition on the faulty HDD which I disabled.  I think it is either the Dell recovery partition or Dell Utilities Partition.

I'm not sure the power supply thing could cause this. Did you check the power supply output and the laptop's input requirements?

Yes I ensured the voltage output was identical and that the power and current rating was no higher than the original PS.  I basically used a lower power Dell supply.  The only reason I was suspicous of it was 1) the HDD failed within 12 hours of using it, and 2) as it was older it might not have had some circuitry in it that perhaps identified when the battery was fully charged and might have overcharged it - jsut speculaiton on my part.

BTW what is the advantage of cloning  a HDD if one is able to mark bad sectors on the original HDD ?

[Tom]

It is the 3rd partition on the faulty HDD which I disabled.  I think it is either the Dell recovery partition or Dell Utilities Partition.

No, this is a device. The piece of log I showed contains identified devices (disks) that are found in the PC, NOT volumes on a disk. That would come way further in the log but unfortunately it proves tricky to get that info.

About cloning:
It all depends on how bad the disk is. If there would be just a few bad sectors, then yes, a read/write surface scan would identify those sectors and life can go on. If however there would be loads of bad sectors, marking them won't work after a certain amount and the disk may very well give up. In such a case cloning would be best, for obvious reasons. So essentially one determines whether cloning is needed based on the amount of bad sectors on the disk; basically on how bad the disk is. A SMART log would give us more insight into the disk's state, that's why that log (for now) is so important.