What causes a nul character written to file just before a pc crash?

We have an application running on several thousand identical machines. Same OS, same hardware, same application installation. On very rare occasions, the machine locks up. Alt tab, ctrl-alt-del, application are all unresponsive. After inspecting our applications log file, a series of null characters are written to the end, as the last data before the crash.

I'm hoping to use this fact as a means to debug the lockup. My guess is that the number of nu开发者_StackOverflowll characters written is equivalent to the space I need to allocate for my log statement, but the content is never actually written to disk. I'm also guessing a disk IO problem occurred, prevent the write, and of course, the OS lockup. I can't confirm of this. So I guess my question is - have you ever seen a condition like this, how did it occur, and how might you go about troubleshooting it?

NTFS does not journal data (only metadata), so things like that can happen. The reason why is just that at the time of the crash/hang, the metadata (file size, data block allocation) was committed, but not the data (data block contents). Unfortunately this is normal behavior with NTFS and will not give you any insight into the problem causing the hang.

So the answer is: a crash at the "right" time can cause this.

BTW: The same thing can of course happen with FAT/FAT32.

I've seen this type of thing happen, I think you're looking in the right general direction.

When this happens I assume you're able to pinpoint the exact hardware? after failure I'd recommend running a memtest (http://www.memtest.org/).

I've seen this sort of thing with power supplies, bad disk controllers, etc. You can go insane trying to track them down.

Seems like you're going about this the right way - see if you can find a way to force the problem to happen more quickly, when it happens run the memtest, run chkdsk /R (check the eventlog for controller errors during this)

any chance you could get a kernel debugger attached?

any chance %SystemRoot%\memory.dmp was produced?