1. 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. NOTE: If this is a headless server hosted somewhere, you may not wish to do this... your system will not reboot until told to.. which means it will hang forever.

2. 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. If you overwrite the file, you will be out of luck in comparing the dumps.

3. 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:

1. Start WinDbg

2. Create a directory in the root of C: and call it "symbols" (mkdir c:\symbols)

3. 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 

4. Once you apply the symbol path, select the "Reload" checkbox and then hit Ok.

5. 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).

6. 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.

7. 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+4f20 )

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, since the system will constantly crash on startup!

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 . This will set the driver to NOT load on boot. You should then be able to boot up, and remove the offending driver.