Re: USB "delayed write failed" Anyone knows why ?

On 4/28/2024 3:06 AM, JJ wrote:
> On Sat, 27 Apr 2024 17:04:57 +0200, R.Wieser wrote:
>> Hello all,
>>
>> On a machine runnung XPsp3 :
>>
>> A while ago  tried to copy a couple of 1...4 GB files to an USB stick, and 
>> it threw the "delayed write failed" error (after a couple of hundred MByte), 
>> after which the machine froze and I had to power-cycle it to get it to 
>> respond again (not even the task-manager wanted to come up).
>>
>> A bit of googeling gave me the answer : unticking "Enable write caching on 
>> the disk" - even though that was in a section that was grayed out because 
>> its parent, "Optimize for performance", wasn't selected ("Optimize for quick 
>> removal" was).
>>
>> No, the question is not why I had to untick something in a grayed-out 
>> section, don't worry. :-)
>>
>> My question is even worse than that :
>>
>> Does anyone know (or have a link to an MS article to) why that the "delayed 
>> writing" (which I assume was still doing its job) causes such a big problem 
>> ?
>>
>> And don't worry, its just curiosity.  There is nothing hanging on the 
>> answer.
>>
>> Regards,
>> Rudy Wieser
> 
> From MSDN:
> 
> ERROR_LOST_WRITEBEHIND_DATA
> 596
> 
> {Delayed Write Failed} Windows was unable to save all the data for the file
> %hs. The data has been lost. This error may be caused by a failure of your
> computer hardware or network connection. Please try to save this file
> elsewhere.
> 
> ...
> 
> My hunch tells me its due to hardware/firmware level I/O handling bug/glitch
> or limitation on the storage device side. If the device was plugged to the
> front panel port, try plugging it directly to the back panel port without
> using any extension cable to avoid any interference.
> 

You can use any mechanism which slows down the ability to write,
to trigger that error. Running WinXP out of Pool Memory, with a
persistent pest, is enough to do it. Other later OSes, the Pool Memory
arch changed, and there are gobs of Pool Memory to go around. This
makes it a lot harder to attack later Windows using Pool as your lever.

It is otherwise, pretty difficult to get fine enough control,
to "engineer" a delay write failure. For example, if a hard drive
is struggling with a bad sector (doing retries for 7-10 seconds and
ignoring input), and a write is pending, between 10-second attempts on
the sector, the OS can slide in the write request and it gets done
before it is too late. With clever choices for timeout constants,
you won't be seeing the error you had hoped for.

It really requires a "path delay", a "velocity problem", to throw
that error. That's why the Pool Pressure method works so well.
The program applying the pressure, increases the pressure over
a 12 hour period, and eventually just the right amount of
tourniquet is applied to trigger a write failure (by the
write taking too long to complete).

*******

If you have the time to wait (heat death of the universe),
try and create 4 billion files in an NTFS folder. I've tried
up to the 4 million mark and noticed that NTFS is slowing
down significantly. How long would it take to get to four billion ?
Would you start seeing "Delay Write Fail" somewhere before you
get to four billion ? This would take a while to test. Since
NTFS files can live in the $MFT (1KB entries), four billion files
should fit into a 4TB hard drive holding nothing but an MFT.

   Paul