or: Digging Around in the Windows Sewer System
Usually when you get unceremoniously dumped to a BSOD Windows is kind enough to give you the filename of the module (driver) most likely responsible for the failure. Usually this filename is enough to let you know just what the problem is and go about getting rid of the troublesome bit of your PC that's giving you hell. Other times, however, you get stuck with a nice blank blue screen or even a black one. Despite the lack of information, Windows usually has the information and just failed to display it (it failed to fail properly?). This data, along with a chunk of memory in the area of interest, is stored in the Windows minidump file and is usually located in C:\WINDOWS\MINIDUMP. If you can't find it there, look around, there's a minidump directory somewhere in the windows folder. The only trick is extracting this data into a form that you, as a non-machine, can read.
Enter the Windows Debugging Tools. Generally used by programmers to pinpoint where their code has gone awry, it decodes the crash dump files that Windows generates (works for other software too). You can get them here: Install 32-bit version 6.8.4.0 [16.7 MB] (The usual download page and instructions seem to have gone missing, at least for tonight). Once you install this, you'll want to get the Windows Symbol Package for your particular version. (This page has also gone AWOL, perhaps they've been moved? In the meantime here's the links in the wiki.) Once you have them both installed, it's fairly simple to get up and running.
There's two different utilities provided to read the dump files, Dumpchk.exe and windbg (the GUI). If you want to use the command line version (dumpchk), check out the MS page on it. I find it rather annoying to type out the convoluted path and prefer the windbg program. When you run it, the first thing you'll want to do it tell windbg where the windows debugging symbols are located but choosing FIle->Symbol File Path (go figure). They're usually in C:\WINDOWS\symbols\ or something similar. Then it's just a matter of File->Open Crash Dump and select the most recent file in c:\windows\minidump. (If prompted to save the workspace, just click OK. If you need to use it again it'll remember where the symbols are next time.)
If all goes well (relatively speaking), you should be greeted with something like the following:

Microsoft (R) Windows Debugger Version 6.8.0004.0 X86 Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\WINDOWS\Minidump\Mini030608-02.dmp] Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: C:\WINDOWS\symbols Executable search path is: Unable to load image ntoskrnl.exe, Win32 error 0n2 *** WARNING: Unable to verify timestamp for ntoskrnl.exe Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible Product: WinNt, suite: TerminalServer SingleUserTS Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055c700 Debug session time: Thu Mar 6 23:19:31.859 2008 (GMT-5) System Uptime: 0 days 5:29:07.610 Unable to load image ntoskrnl.exe, Win32 error 0n2 *** WARNING: Unable to verify timestamp for ntoskrnl.exe Loading Kernel Symbols ............................................................................................................................................. Loading User Symbols Loading unloaded module list ........................................ *** WARNING: Unable to verify timestamp for nv4_disp.dll ******************************************************************************* * * * Bugcheck Analysis * * * *******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 100000EA, {88fef020, 8a08b948, f78c2cbc, 1}
Unable to load image watchdog.sys, Win32 error 0n2 *** WARNING: Unable to verify timestamp for watchdog.sys ERROR - could not read driver name for bugcheck parameter 3
Probably caused by : nv4_disp.dll ( nv4_disp!nvOldKelvinSpad+1729 )
Followup: MachineOwner ---------

This particular dump is from XP and the error seems to have been caused by nv4_disp.dll, an NVidia driver. (Actually caused by a massively buggy video game, which can be found out by clicking the !analyze -v link in the actual windbg output). Once you have this, you know which driver failed and if you click !analyze -v, in blue, you'll get even more information:

<SNIP>
IMAGE_NAME: nv4_disp.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 47567aa4
MODULE_NAME: nv4_disp
FAULTING_MODULE: bf012000 nv4_disp
DEFAULT_BUCKET_ID: GRAPHICS_DRIVER_FAULT
CUSTOMER_CRASH_COUNT: 2
BUGCHECK_STR: 0xEA
PROCESS_NAME: Gothic3.exe
LAST_CONTROL_TRANSFER: from 89fe2960 to bf186099
<SNIP>

So Gothic3 crashed the video driver (very common occurrence, that game will screw up anything). It's a good idea to research these results further on the net, since it can be difficult to tell if the software caused the error with a nasty bug or the driver caused it with it's own bug.

That's all there is to it. Good luck.