Btw, your symbol fileset (either local or remote) must actually match your OS version. Symbols for XP retail are not the same as XP SP1 and XP SP2 due to file versions difference. The same applies for Win2K. Nowadays I think you need not worry about this as the symbol server will take care of this.

Symbols (.pdb files) for third party drivers are virtually non-existant on the net and are only used internally by hardware/software vendors. So let's say your PC crashes due to a abc123.sys driver fault. You will notice that particular driver caused a break on your debugger but you will not be able to examine in depth the stack information.

Also, you can debug a machine on the remote machine instead of using dump files but you'll need another PC/notebook. This is useful when your PC crashes on bootup.

1. Create an alternate boot option in your debugee's (the machine that's being debugged) boot.ini file. E.g.,

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP Debug" /fastdetect /debug /debugport=COM1 /baudrate=115200

2. Connect a null serial cable from your debugger to your debuggee (usually both at COM1).

3. Start windbg from your debugger with the correct com port number and baudrate.

4. When your debuggee boots up, you should be able to see your debugger windbg session spewing text, meaning you're connected