Cool thanks I thought it was fairly common knowledge lol Here's a little guide I put together for the other guys at work a while ago, just in case its of any use to you guys:

A lot of the time, if you actually see the blue screen error message then it can be fairly easy to work out what caused it, for example it may mention a specific file or give an obvious error message. Sometimes though, especially with servers, you do not get chance to see the blue screen message as it may appear at night or just randomly every few days/weeks.

In these cases (along with cases where the error message you do see on the BSOD does not give you enough information) it is usually helpful to debug the crash dump file that windows creates when it creates the blue screen of death.

For this reason, it is often a good idea to set the system's crash options to "Complete Memory Dump" or "Kernal Memory Dump" instead of "Small Memory Dump" - you can change this option by clicking the Settings button under Startup & Recovery in the Advanced tab of System Properties. Kernel Memory Dump is probably the best option as it contains all kernal mode memory at the time of the crash, where as a full dump will contain ALL objects in memory (user mode and kernel mode) so your page file must be at least the size of the amount of RAM you have, plus a couple of hundred MB. If the system has more than 2 GB of RAM then the Full dump option is disabled anyway. Also, as its only kernel mode code that can actually cause a BSOD directly then there isnt much point having user mode objects in the dump file as well in most cases.

Although you can still debug mini dumps, there will be more useful info in a kernel dump so its worth changing. Even with the Kernel dump you need to make sure the page file on your system drive is a decent size so that it can hold all of the kernal mode data that was currently in memory at the time of the crash. Provided you have the free hard drive space then just setting the page file to something like 2 GB should be more than adequate.

Anyway - no matter what kind of dump file you have, you need to download Windbg.exe from here (if its a 32 bit system anyway): http://www.microsoft.com/whdc/devtoo...nstallx86.Mspx
It comes as part of a debugging kit, so once youve installed it just look in Program Files\Debugging Tools x86 (or whatever its called) and then in there you should see lots of files - one being windbg.exe.

Once you've opened windbg, go to File -> Symbol File Path and then in the new box that appears copy and paste this:
SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
This will create a folder called C:\websymbols and download any necessary symbols from the microsoft symbol server into there. (usually only about 5 or 10 MB).

Once you've done this, go to File -> Open Crash Dump and then select your crash dump. By default a full or kernal memory dump will be here: C:\Windows\MEMORY.dmp and a mini dump will be here: C:\Windows\Minidump\DATEminidump.dmp where DATE will be the date that the crash occured.

Now just sit and wait... there's no real indication that anything is happening other than occasionally seeing "BUSY" in the bottom left corner but be patient and eventually a diagnosis will appear. If you're lucky then windbg will suggest which file seems to of caused the BSOD but if not then you can type !analyze -v into the command box at the very bottom of the program to see a detailed report.
From the information on the screen you should be able to see which driver file it is that was in use just before the crash and therefore is likely to of been what caused it. You will also see the BSOD error message at the top of the output, for example: IRQ_NOT_LESS_OR_EQUAL

Hope that helps someone