Shortly after starting the creation of a Norton Ghost 10 recovery point of the NTFS operating system partition that is written to a second, internal hard disk drive (Seagate Barracuda 7200.7, Ultra ATA/100, 7200 RPM, 120GB, model ST3120022A), I receive a Windows XP pop-up message stating that "Delayed Write Failed."

These are the tests I have performed so far:

• Neither "CHKDSK /R" nor the Seagate SeaTools Diagnostics report any errors on the ST3120022A disk.
• Reducing the ST3120022A disk's transfer speed from the default UDMA-5 (100 MB/s) to UDMA-2 (33 MB/s) does not improve the situation.
• Disabling the option "Enable write caching on the disk" for the ST3120022A disk does not improve the situation.
• Reducing the performance slider in Ghost 10 from the default, 75% setting to 50% does not improve the situation.
• "Memory Usage" is set to "Programs", as recommended in Microsoft Knowledge Base Article 330174, and this does not improve the situation.
• Increasing the value of the SystemPages registry key (see Microsoft Knowledge Base Article 330174) to 0xFFFFFFFF does not improve the situation.

Except for Ghost 10, all other usage of the ST3120022A disk appears to be operating normally.

All recommendations are welcome.

Thanks, Brian, for the note.  You are correct:  writing a Norton Ghost 10 recovery point onto the 120GB internal disk has always worked well in the past, but now is yielding the "Delayed Write Failed" error.

I have also determined that the problem is unrelated to Norton Ghost 10 proper.  I can reproduce the "Delayed Write Failed" simply by copying a large (e.g., 4GB) file onto the disk (although the error does not occur when copying typical, smaller size files).

I have never heard of an internal Ultra ATA/100 cable becoming defective.  Does this occur?  Wouldn't a cable problem prevent all access to the hard disk drive – and not just selectively impacting large files?  (I have not touched the cable for over a year, since installing the 120GB internal disk.)

I have also run a set of memory diagnostics (in the VCOM FixIt Utilities 7 suite), and the hardware passes all tests.

Appreciate the assistance . . . .

One big factor with ribbon cables as opposed to twisted-pair is crosstalk, as well as reflections (the whole master/slave thing on IDE is as much about applying the correct terminating resistance so that you don't get signal reflection as it is about drive selection). That combines with the fact those conductors in the ribbon are pretty fragile, and internal partial breakages of the cable - so that you get a signal, but it's marginal - are not unknown.

The CRC checking on UltraDMA is pretty crucial, and this is one reason why faults can show up as being data-dependent; if the system is marginal the normal CRC checking applied to the transfer over this cable will mask it, but since the crosstalk between the conductors is affected by the data they are carrying, some particular content can push one of the bits of the message far enough off course to cause a repeatable CRC fault.

Linkage, for those interested:

http://www.winmagic.com/solutions/securedoc.html

Pleo, I thought you were using a different encryption prgm .. altho I can't recall which one.