For a while, I was getting random BSODs and some searching led me to decide to enable a feature called the driver verifier. [More info about Driver Verifier here] My understanding of the driver verifier is that, when a driver acts out of line, even a little bit, even if to an extent that otherwise would be tolerated, Windows throws up a BSOD and lists the offending driver.
In my case, I was getting the Special Pool Detected Memory Corruption BSOD with no specific driver being listed. The number of solutions I found online were almost unbelievable: everything from bad memory to corrupt MBR to corrupt CMOS settings. In fact, none of these would have solved my issue. But a few sites seemed to indicate that this meant that some driver was failing the verifier, but to determine which specific one, I had to examine the dump file that is generated once a BSOD is displayed.
So I loaded into a recovery session, and examined the dump file (C:\Windows\MEMORY.DMP — actually, it was D:\, but thats another story). After analyzing it, WinDbg guessed that my mouse driver was causing the issue (RzSynapse.sys, presumably for the Razer mouse I had connected).
So I disconnect the mouse and restart hoping all would be well, but of course nothing is that easy and I immediately got another blue screen. This time, however, it identified a driverm and a different one. The problem here, however, is that the driver was for a remote management application I use, and not something I could easily disconnect to prevent it from being loaded.
So I know I need to update this driver, but I can’t do so easily because windows BSODs out before it even lets me log in.
So I decide to disable the verifier first, and then update the drivers.
In a command prompt in the recovery session I type
but it says something to the effect of “no drivers are being verified”. But that was simply not true, since the newest BSOD clearly says a driver failed verification.
I guess that the
command doesn’t work properly inside a recovery session, so I go to check the registry. From pages like this I find the registry path, so I fire up regedit, navigate to the where the keys should be and… they’re not there.
Well this complicates the matter. On one hand, the BSOD indicates that driver verification is enabled, but neither the command line “verify” command nor the registry seems to think so.
After thinking about it for a few minutes, I recalled that another page I had read previously discussed loading a registry hive into regedit. I didn’t think much of it at the time, but now it got me thinking that, maybe what regedit was displaying was a registry specific to the recovery session, and the registry that was used to boot windows was somewhere else.
I followed the steps outlined in this second article to load my system registry hive and voila, the driver verifier keys were, of course, present. I promptly delete them, unload the registry hive, and restart the computer. Hoping for the best, but fearing for the worst I walked out of the room to do some other things and when I came back, I was greeted by the glorious login screen — something a little bit earlier I hadn’t thought I’d see again without reformatting.
So, recap — lessons learned:
- In a recovery session, the registry regedit displays isn’t the registry you might expect. You need to load external hives to edit them. See the link above for how.
- Driver Verifier is a decent trick to pin down random, unexplained BSODs, but the hassle it caused me makes me wish I simply made an effort to save more often and never even worried about curing them. Simply throwing users to a BSOD seems harsh, especially when they may not cause BSODs had the verifier not been running. I mean, it would be nice if I could “ignore” it, so I could then continue to boot windows and update the offending drivers.
- There must be some recovery session information stored on non-primary disks, because when I disconnected my non-primary disks in an attempt to rule out hardware issues, the recovery session option was gone and in its place was a message asking me to boot from an install or recovery disk. When I replaced the disk, the recovery session option returned. Also interesting was the fact that, when I rearranged by drives in my BIOS correctly (primary on SATA order 1, secondary on SATA order 2) the recovery session again disappeared. I’m sure this would be easy to look up and verify, but I’ve wasted enough time on this issue — maybe later.