In the past couple of months, I ‘ve been grappling with graphics stability issues. Mostly, this has meant driver restarts where you get a message that reads something like “Display driver stopped responding and has recovered.” Occasionally, this has involved a BSOD that mentions the Nvidia driver files nvlddmkm.dll or nvlddmkm.sys. When it happens, it seldom occurs more than twice a week. I keep checking the Nvidia driver download page, grabbing new drivers as they become available (including occasional betas), and hoping for the best.

This morning I got another stop and recover message, and  yesterday I got a “the display driver failed to respond in timely fashion” BSOD, so I figured it was time to check for another Nvidia driver. I installed my most recent one (the 177.92 beta) on 9/3/08 and thus wasn’t too hopeful.  But I discovered a whole new crop of drivers waiting for me to try out, labeled 178.13 with WHQL status, no less, dated 9/25/08 on the download, and 9/17/08 on the Driver tab from Device Manager. I’ve installed the 8xxx version for my 8600 GTS graphics card. Now, I’ve got my fingers crossed, and am hoping for the best! I’ll keep you posted…

 

 When Vista attempts to reset the graphics driver and it doesn’t respond quickly enough, you get a BSOD.

New Shadow Copy Puzzle Poses Itself

If you’ve been following my blogs lately, you already know I’ve been chasing some interesting shadow copy issues lately. I now know that every time Vista captures a Restore Point it also creates a hidden “Generic volume shadow copy” device for each one in Device Manager. Yesterday, I noticed some error messages in the System log in Event Viewer from source “ntfs” reporting issues with various specific shadow copies reported as corrupt or damaged.

Some research taught me that you can’t repair or delete individual shadow copies. All you can do it disable automatic restore capture to clean out the shadow copy collection, thereby also removing evidence of the damaged or corrupt copies as well as all the good copies–which explains why I performed an image backup that captures shadow copies as well as the file system and system state before taking this otherwise irreversible step.

When I logged in this morning, I checked the System log in Event Viewer, expecting to see the complaints about “corrupt and unusable” VolumeShadowCopyXX entries at least diminished, if not altogether absent. Wrong!

NTFS corrupt file system structure error message for VolumeShadowCopy98
(click image for fullsize version).

Yesterday before I disabled, then reenabled, daily automatic volume shadow copies for my C: and D: drives, I saw complaints about XX entries: 88,90-92, 95-99, and 101. This morning, I’m still getting complaints about “old” XX entries: 88, 92, 95, 96, and 98, along with some “new” XX entries: 85, 87, 89, 93, and 94.

Here are my puzzlers:
Why would shadow copies persist past the disable/reenable trick (“old” numbers as listed above)?
What is causing the “new” entries to report the same error?
This definitely gives me some new and interesting anomalies to research and pursue in the days to come. Stay tuned as I try to get to the bottom of this. If all else fails, I can always go back to Mark Russinovich, who helped me understand what was going on with the hidden device entries in Device Manager when all else failed.

As they used to say on the old movie serials: See you soon, for the next thrilling installment! I’ll keep you posted about this, too. In the meantime, I’m going back to nightly complete backups, just in case something truly ominous is causing my volume shadow copy/Restore Point operations to fail. If I can’t rely on a Restore Point, at least I can get back to a valid backup…