What causes a nul character to be written to a file immediately before a PC crash?

We have an application running on several thousand identical machines. The same OS, the same hardware, the same installation of applications. In very rare cases, the machine locks up. Alt, ctrl-alt-del, the application does not respond. After checking our application log file, a series of null characters is written to the end, as the last data before the failure.

I hope to use this fact as a means to debug the lock. I assume that the number of null characters written is equivalent to the space I need to allocate for my log statement, but the content is never written to disk. I also assume that there was a problem with the IO of the disk, prevent writing and, of course, locking the OS. I can’t confirm this. Therefore, I think, my question is: have you ever seen such a condition, how it happened, and how can you eliminate it?

+4
source share
2 answers

NTFS does not contain log data (metadata only), so such things can happen. The reason is that during the crash / hang, metadata (file size, distribution of data blocks) was recorded, but not data (contents of the data block). Unfortunately, this is normal behavior with NTFS and will not give you any understanding of the problem causing the freeze.

So, the answer is this: it can lead to a failure at the β€œright” time.

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

+2
source

I saw how this happens, I think that you are looking in the right general direction.

When this happens, I assume that you can accurately determine the exact equipment? after failure, I recommend running memtest (http://www.memtest.org/).

I have seen such things with power supplies, bad disk controllers, etc. You can go crazy trying to track them.

It seems you are going the right way about it - if you can find a way to make the problem happen more quickly when it happens, run MEMTEST, run CHKDSK / R (check EventLog for controller errors during this)

any chance that you can hook up a kernel debugger?

Is there any chance of% SystemRoot% \ memory.dmp?

+2
source

All Articles