THE OFFICIAL BLOG OF THE SBS "DIVA"

Today I read a post by Susan in which she makes some good recommendations on how to get a dump when a system crashes. I found a few of her points could be expanded upon and slightly modified, and started to comment on her blog. Then I realized it might be useful to others in the community, and decided to post it here. There are a couple of things to consider when dealing with a kernel crash dump. You should read Susan's article first in order to understand her recommendations on setting up kernel dumps on Windows. Turn OFF the "Automatically restart" checkbox. When the system BSODs you will then be able to SEE the crashdump on screen. This is important as you can typically SEE the offending driver that is causing the fault. More importantly is that it allows you to see the TYPE of fault. If you don't do this, the system will automatically restart and you will miss this vital information. Turn OFF the "Overwrite an existing file" checkbox. Otherwise, if you have multiple faults you will never know about them since you would overwrite the previous crash dump. In some cases where "Paged Pool" is corrupted due to an offending driver, you may trigger a secondary fault that is harder to track down if you try to rectify it before it can be pushed to OCA. In a pinch a minidump is fine. 9 times out of 10 having the complete dump of memory is useless unless the debug team require to debug virtual memory issues (like BAD_PAGED_POOL_HEADER faults). A little known fact is that the data Microsoft fires off to OCA is actually a bastardization of the minidump, which is then sent to code on the OCA server which goes through a filtering algorithm to determine the true cause of the failure, and is then placed into the buckets for each vendor. If they need more information (like the full dump) you get routed to a special web page, and are then asked to upload it. If you want to get geeky and LOOK at the fault (in case you skipped point one and the system rebooted), it is possible. To do this you will need to download Microsoft's kernel debugger called WinDbg. Then take the following steps: Start WinDbg Create a directory in the root of C: and call it "symbols" (mkdir c:\symbols) Click on File, Symbol File Path. Here you will enter the symbols path, which is needed to effectively read debug information. Since Microsoft makes its public symbol server available to us, lets use it. The path will be: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols Once you apply the symbol path, select the "Reload" checkbox and then hit Ok. Now go File, Open Crash Dump and load the file you wish to view. The minidump will typically be located in %systemroot%\minidump (in my case C:\windows\minidump). When you hit Ok, the debugger will contact the symbol server, sync the data and load the debug screen with the data that it can read. Now at the cmd prompt type analyze -v You now have a full debug of what has faulted, with all the information you need. At this point you can check information on the stack, look at the last instructions before fault and do all the magic a kernel guy does. Chances are, most of the information will be foreign to you. Don't fret. That's what people like me are for. Just look for something that says: Probably caused by : foodriver.sys ( foodriver+7fc0 ) Chances are, THAT is your offending driver (and the offset is the location, so if you let the vendor know they will know right down to the line number). What do you do now? Well remove it. If the driver loads on demand, not a problem, you can simply remove the offending software. But what if the driver loads at boot time? You will never be able to do that! That is why the "Recovery Console" exists. Stick in your W2K3 or XP CD and boot from it. When asked, hit "R" for Recovery Console. When prompted type in your Adminstrator's password. Once logged into the console type net stop <drivername>. This will set the driver to NOT load on boot. You should then be able to boot up, and remove the offending driver. Susan, tell your friend there is no need to reformat and reinstall. Just use the tools available to you to remove the offending driver!...

Hey Susan,

I started commenting on this, and decided there was enugh information to make a full blog entry out of it. You can check out my response at: http://silverstr.ufies.org/blog/archives/000761.html

Basically you have sound advice. I would just modify it slightly. My entry will explain why.

- Dana

Kaopeh.com