Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Yesterday while hibernating my Windows 7 computer, I got BSOD which complained about Creative sound card driver (ctoss2k.sys). I have been using this system for two years already and I haven't had any issues before. After a full hard drive scan with Windows built-in utility. I saw many corrupted files.

The multi-sector header signature for VCN 0x5 of index $I30 in file 0x36c28 is incorrect.
Correcting error in index $I30 for file 224296.
The index bitmap $I30 in file 0x36c28 is incorrect.
The down pointer of current index entry with length 0x18 is invalid.
Recovering orphaned file .... (many of those)
The USN Journal entry at offset 0x44fa40000 and length 0x80000004 crosses
the page boundary. 
The USN Journal entry length 0x1 at offset 0x44fa51000 in file
0xe0fc is not aligned  (many of those).
The remaining of an USN page at offset 0x44fa5d000 in file 0xe0fc
should be filled with zeros.

Why did the audio driver BSOD corrupt the files which were not in use at the moment of the BSOD?

I'm sure Windows was not rewriting system files (I have turned automatic updates off, I'm updating manually), and also I see many orphaned files from some other software which was not running at the moment of the BSOD. The lines "Recovering orphaned file [filename here)" contained file names of programs which were not open at the moment of BSOD (some Visual Studio files, some Corel Video Studio files ...).

How can NTFS allow for such major corruption to happen for files which are completely unrelated to the BSOD? I have read that NTFS has a backup copy of metadata. Why NTFS does not detect that the main metadata table is corrupted and it should recover from the backup metadata (which should store the state right before the BSOD)? Isn't NTFS transactional at all?

share|improve this question
NTFS does not hold a backup of all metadata, but a limited duplicate of the master file table, 4 KB in size. – Marcks Thomas Apr 6 '13 at 19:53
Martin, as a clarification, was the driver just added or new to the system? meaning did some new driver, or first time trying to hibernate with it, cause a BSOD. Or is it possible that general disk corruption came first, and a driver was also corrupted ? – Psycogeek Apr 6 '13 at 20:17
The system has been in use for two years without any hardware changes, powered through UPS. I was using the Hibernate feature countless times, and only yesterday it failed with that ctoss2k.sys BSOD. Hard drive is physically healthy (tested with HDTune). Even now after the crash it hibernates without issues. But it's clear that I need to reinstall because many programs are failing to launch, and even sfc /scannow reported that it's unable to fix some corrupted system files. – JustAMartin Apr 6 '13 at 21:31
Ahh, that clears things up. Trust your backup :-) not that drive until you know for sure. in the S.M.A.R.T. test, what is the "Data" ammount shown in the reallocated sector count? – Psycogeek Apr 6 '13 at 22:54
After a BSOD, some files are not really written to disk. Microsoft is aware of the problem but it seems no fix is available yet...… – user323189 May 15 '14 at 21:44

The files could have been "in-use" by Windows, or other processes at the time of the BSoD.

Also the unrelated files could be physically next to the files "in-use" on the hard drive. You should probably do a chkdsk /R c: to check for bad sectors.

share|improve this answer
"next to the files" - this makes sense, I didn't think about that. Yes, I did a full scan, and also scanned with HDTune - no bad sectors. Still I'm so disappointed about NTFS - I thougt it is transactional in some way and will not allow such a file corruption just because of an audio driver glitch... – JustAMartin Apr 6 '13 at 19:23
If you have ever used FAT16 or FAT32 then NTFS will be much less disappointing. – cybernard Apr 6 '13 at 19:30
in the end, theres no kind of jfs that could deal with a power loss or kenel panic completely. journaling helps, but its not a panacea. – Frank Thomas Apr 6 '13 at 21:03

NTFS is actually famous for losing massive amounts of data due to the file corruption. It is also famous for using unreasonable amount of CPU cycles in order to performs its routines. It is shuffling things in the background almost constantly, so that whenever BSOD occurs, a lot of files will get corrupt. FAT32 is much more stable and reliable, though it suffers from other disadvantages.

So answering your question: blame NTFS. Use better file system next time.

share|improve this answer
Your answer explains experience my friend had when he just migrated to Windows XP. He had an older system drive - FAT32 formatted and a new data drive - NTFS formatted. One day power went off for a moment. Later when the PC booted, FAT32 system was intact, no errors on scandisk. NTFS was corrupted. We were shocked that the new NTFS system could not survive the power outage. – JustAMartin May 28 '14 at 14:54

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.