After a BSOD or a blackout many files my be corrupted even if the were not opened

[Frederic Hebert]

As many users report data corruption during the last 18 months, we gather more data that let us identify more precisely what is the problem. Below, two easy way to reproduce the problem.


First use case:

1. Boot your computer.
   
   
2. Log in to your account.
   
   
3. Start Notepad and create a new file.
   
   
4. Add some text to the file and save it.
   
   
5. Close notepad.
   
   
6. Go to your coffee break...
   
   
7. Unplug your computer (simulate a blackout).
   
   
8. Boot your computer.
   
   
9. Log in to your account.
   
   
10. Start Notepad and open the file created in step 3.
    
    
11. THERE IS NOTHING in the file... It looks like all space but if you open the file in a binary editor, you will see that the file contain only zero.
    

Second use case: Do the exact same step but instead of a blackout create a blue screen (BSOD) using the special registry key CrashOnCtrlScroll. You will end with the exact same result...


Note that we reproduce this problem with many computers and many applications. Our application but yours also: Office document, BMP created with paint, C++ file created with visual studio, etc.


A blue screen or a blackout may lead to data lost IF AND ONLY IF the file is currently open. We discover that many files may be corrupted even file edited 3 hours ago...


We tried to reproduce this problem with Windows Vista and XP but it seams they don't have this bug.

This is a very serious issue for professional working with Windows 7.

I submit this problem to microsfot connect in 2012 and it is still open. Any ideas or explaination?

 

[mailpup]

I wouldn't advise people to follow the OP's suggestion to unplug their PC to simulate a blackout. As the OP himself pointed out, more than just Notepad files can be corrupted. What do TechSpot members have to gain by doing such a thing?

 

[DelJo63]

IMO, the empty file occurs due to I/o buffering (sometimes called delay write).
Buffering makes the application appear to be quick, when in reality the data has yet to be flushed to the hd.

Years ago, I had a system with an HD with on-board cache and it made me nervous for exactly this case. I forget at the moment where the option is located but you can disable I/o buffering - - it's associated with the device manager, hd settings OR the BIOS itself.

I agree with @mailpup; don't use your system as a beta-test lab for stupid software testing unless you're ready to face the consequences.

 

[Frederic Hebert]

You are right, don't try this unless you want to investigate the problem. I submit this case because I think it's important to be aware of it.

You give me a hint with the I/o buffering. We tried to disable write cache but the problem persist. Maybe there is more options to disable.

But the problem remains for user with default Windows 7 options. They can lose data even if they close the files cleanly and many hours before a BSOD or a blackout.

When a user report this problem, for sure the first thing is to fix the cause of the BSOD or suggest to use a UPS so computer can close correctly. But, it is often to late...

IMO, the empty file occurs due to I/o buffering (sometimes called delay write).
Buffering makes the application appear to be quick, when in reality the data has yet to be flushed to the hd.

Years ago, I had a system with an HD with on-board cache and it made me nervous for exactly this case. I forget at the moment where the option is located but you can disable I/o buffering - - it's associated with the device manager, hd settings OR the BIOS itself.

I agree with @mailpup; don't use your system as a beta-test lab for stupid software testing unless you're ready to face the consequences.

 

[gbhall]

I don't entirely believe your evidence that a power loss could 'usually' corrupt data already 'written' even if only to cache. I think it probably depends upon the actual hardware driver. As a glance at this image shows, a normal Win 7 setup enables write-caching,



but also enables buffer-flushing on the HDD. I accept that buffers might not be flushed until the application is closed (in most cases), or even until some further writes have occurred, but I cannot accept the figures of 'some hours' you quote. There is a great deal more discussion of the implementation of cache flushing if you follow the link 'more information about write-caching settings' above. In the main, this speaks of 'periodic' flushing, but also makes clear that the hardware manufacturer has an influence. I quote in part

<<
Cache flushing
By default, Windows employs cache flushing. This means that the system will periodically instruct the storage device to transfer all data waiting in the cache to the principal storage media. When you select Enable write caching on this device, you turn off these periodic commands to transfer the data. Not all devices support all of these features.

If high data transfer performance is your paramount concern, you should enable both settings: in the Removal Policy section, select the Better Performance option and in the Write-caching policy section, select Enable write caching on the device (if the system hardware and storage device support these features).
>>

If your hypothesis were true, MS would probably have been given enough hassle already to have changed the system years ago. I conclude that provided you stick with the default settings, your data is, under most conditions, safe. Clearly, not completely safe, and if you live in a part of the world with frequent power-loss, you will be wise to invest in a UPS. But not otherwise.

I repeat, the untouched defaults are reasonably safe, in my opinion, but indeed it is possible to interfere with those settings and definitely imperil your data. I would suggest that companies with slightly inexperienced IT staff might well do this in their 'standard' installation - to their user's detriment.

I also have experience that this default cache-flushing on Microsoft servers was changed some years ago, when the entire file sharing system was revised to SMB2 instead of SMB1. The current implementation (SMB2 since about 2008) is definitely faulty as regards shared files and buffer data reported by shared files. It is necessary to make a registry change on all MS servers after SBS2008 and if you don't, you will get incorrect data recorded on shared files at a rate of about once per week. http://fox.wikis.com/wc.dll?Wiki~VisualFoxProOnWindowsServer2008 This is regardless of instructions to 'flush the cache' sent by applications. Those instructions are just ignored by a MS server unless the option to disable SMB2 is set.