Debugging with WinDbg
In this blog I’ll show you how you easily can extract some information from a dump file, just that bit information that might help you determine if it was a glitch or a more serious issue.
We’ve all been there, servers that crash and show the infamous Blue Screen Of Death. Debugging this is hard for there is so much data and it’s so hard to understand it.
I’m not claiming I’ve learned how to read it but I’m trying to get a better picture of dumps. At a customer site we had our share of crashes or the past months. The environment is a Citrix environment and we noticed that the majority of the crashes was due to a bug in PICADM.SYS. Citrix provided us with a private fix and BSOD because of this went away. Still every few weeks a server might crash and I went to do a check on the dumps.
There are tools available to read your dump file, I just download WinDbg from Microsoft and did my search with that one.
Microsoft WinDbg is part of the SDK and can be downloaded here.
While you install the SDK you only select WinDbg.
The tool isn’t sexy at all, it’s more a 1995 interface but it does what it needs to do.
When you read dump files just like this you get messages that symbols can’t be found, so you need to set the Symbol location.
If you have a dump file opened already, check the box Reload and click OK.
Reading Dump files
When you open the dump file you can see that the symbols are loaded. At the top of the list you see the address of the symbols locations.
Just below that is the analysis of the dump.
This one was easy, WinDbg tell you that picadm.sys probably caused the crash. As you see there is a command already that you can use, !Analyze -v.
Commands are entered in the command box at the bottom, or when it’s blue you can click it.
So clicking on !analyze -v magic happens.
After you ran !analyze -v you will get a similar result as you see below. You instantly see the STOP code but you see more… sure you’ve seen it already .. there’s a c05 code.
A c05 code is a Access denied error.
Just below that a more readable error message is displayed… a driver fault was the cause of the BSOD, now we need to find out which driver caused it. Of course it was displayed already in the beginning but here we will see if it really was that sys file.
Also a stack list is dislayed, as you can see picadm was loaded at the time of the crash.
Windows will try to grap the process that caused the crash, in this dump the culprit is obvious picadm.sys and with just one command.
With the command lmvm and the process name you get more information about the file that is causing this. For this dump this was enough information. I have more dumps and more commands to share, so this a kind of introduction. Next blog will be about creating a fast debuglog.txt with this information that we just gathered.