Archive for June, 2010
It’s been years since Windows NT first came out, over 14 for just Windows NT 3.5, and it still amazes me how difficult it can be to troubleshoot a user’s BSoD.
At times it is easy, if you were sitting in front of the system when it BSoD’ed and you saw that there was a problem with the agp.sys driver you knew that 1) you were in the 90s and 2) that the graphics driver had a problem. (yes there is always 3) that the disk has a problem and it happens to be were the driver is or 4) RAM where the driver happened to be loaded, etc SHUT UP! the point is it is or was likely the driver). By the same token back then or today a Paged Fault in a Non-paged Area usually means its RAM issue, again not 100%, just most of the time. Now… today I’m working on a ticket and that ticket says that the user’s machine is BSoDing twice a day after some crazed pattern comes on to the screen. My first reaction was to replace the video card, we’ve seen board warping issues with this particular card and it usually resolves the issue… but not this time this time I actually had to do my job (ugggh) and troubleshoot. Enter… the minidump. A minidump file or small memory dump file “records the smallest set of useful information that may help identify why your computer has stopped unexpectedly.” Source: Microsoft Support. Now… here is my bewilderment, in order to read a minidump you need to install the Windows debug tools AND load the debugging Symbols, basically you are doing the job of a QA person or Dev and not a Systems Administrator. Sysadmins you see are a lazy bunch… well.. the good ones are anyway. Where was I? Oh yeah… mindumps. Today reading them is still a hassle, though albeit a smaller hassle than it has been in years past. My question is.. why? If the minidump is something that a Sysadmin might have to look at then why make me load debugging tools and symbols to do it? Why not just flat out tell me what the minidump says next reboot? None the less.. here is how you do it with Windows 7 x64.
Excerpts from: http://support.microsoft.com/kb/315263
First go get the Debugging Tools from the Windows SDK and install them: http://www.microsoft.com/whdc/devtools/debugging/default.mspx
(I was prompted that I didn’t have .NET Framework 4, which is true I don’t so you can ignore that)
Create a folder where you are going to put the Symbols. I put mine on the root of the C drive. Open a Command Prompt with Administrator rights then make the directory.
C:> mkdir c:symbols
Open a Command Prompt and navigate to the location where the debugging tools are.
C:> cd “C:Program FilesDebugging Tools for Windows (x64)”
I like GUI so I run the GUI debugger while loading the symbols from Microsoft’s site and storing them in my c:Symbols directory.
Windows (x64)> windbg -y srv*c:symbols*http://msdl.microsoft.com/download/symbols -z c:windowsminidumpminidump.dmp
The debugger will now download the symbols and start to read the minidump. While it is doing this it is going to display some links such as, !analyze –v, Click on it. The analysis revealed a few things to me this run. Right off the back it told me that there was a problem while loading SystemRootsystem32DRIVERSnvlddmkm.sys. (thats an Nvidia display driver). As the debug continues it seems that a few recovery attempts were made before the system BSoD but the time stamp on the driver couldn’t be verified and thus the system had no choice but to BSoD. You can’t run a Windows system without a display driver, even the generic display driver is a driver.