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