DiskPatch - step 2 trouble

[talamo]

Following to my DP experience:
[My HDD has 398297088 sectors. Area between 130000000 and 150000000 is deeply damaged! Some other areas with bad sectors]
[DP loaded from HDD]

1. UDMA trasfer don't add (compared to no UDMA driver) any problem to cloning procedures.

2. When I clone the whole HDD (step 1-2) or I clone a partial too big area, DP report as unreadable a big part of sectors that it can read while starting to clone from that area. For example:
 a. clone 0-end ---> 200000000-end with hundred errors
 b. clone 190000000-end ---> 200000000-end with hundred errors
 c. clone 200000000-end ---> 200000000-end no bad sectors found!

3. DP can't fly over some bad sectors, ie. when I clone whole HDD or partial area DP falls in error. For example DP crash instantly when starting clone from sector 147672000. But many areas are affected by the same problem!
When I start clone 0-end and DP reach these areas during step 2, it abort the clone, it generates a log with 0kb (no data) and it loose the "to do list" (no datasector found).

[Tom]

When DP really crashes the log file is usually damaged. There is a switch that writes every log line after it has been produced but it slows down the process, although doing that when running DP from a hard disk might not make it too bad. If you use that switch while cloning a bad area we should be able to see the error type. Also, it would be nice to know the error that is displayed when DP chrashes.
The switch is "DP.exe /DBG".
Apart from that i don't have much more advice to offer. I'm not sure i understand the table you produced in your previous posting, but it sounds like no errors are found in certain areas, depending on where you start and end the clone process. That would be strange and quite inexplicable. Again, make sure you do not use the UDMA driver when cloning.

And again i ask: it looks like this disk won't ever give you a 100% clone, so why continue onwards? Are the contents that important? Have you tried lifting data from the clone yet?

[Joep]

Hello,

1. UDMA trasfer don't add (compared to no UDMA driver) any problem to cloning procedures.

Well it often does: either it results in extended int13h error 08h, or and this we have observed on a regular basis, it mirrors the error to the destination disk and reports a write error there. So, at the least sign of trouble we want to eliminate the UDMA driver as a cause for errors.

2. When I clone the whole HDD (step 1-2) or I clone a partial too big area, DP report as unreadable a big part of sectors that it can read while starting to clone from that area. For example:

Well it's not really DiskPatch that 'does' this, but what you observe is probably an ill behaving disk. At the point where DiskPatch actually reads a sector, all control lies with the BIOS, while the BIOS in turn waits for the disk to respond. Then when the disk and BIOS are done, control is returned to DiskPatch. First thing DiskPatch does now is check the return code, a value that is written to a specific CPU register by the BIOS and it is this value that determines if DiskPatch reports an error or not.

The log you have posted shows '20h' int13h errors, which means the BIOS tells us/DiskPatch there was a 'controller failure' when we asked the BIOS to read a specific sector. The BIOS gets it's information from communicating with the disk directly.

Can we please see a disk diagnostic report (http://www.diydatarecovery.nl/dp_manual/guide_smartcheck.htm)?