tags:

views:

74

answers:

2

Well, fortunately I haven't written many applications that cause a BSOD but I just wonder about the usefullness of the information on this screen. Does it contain any useful information that could help me to find the error in my code? If so, what do I need, exactly?

And then, the system restarts and probably has written some error log or other information to the system somewhere. Where is it, what does it contain and how do I use it to improve my code?

I did get a BSOD regularly in the past when I was interacting with a PBX system where the amount of documentation of it's drivers were just absent, so I had to do some trial-and-error coding. Fortunately, I now work for a different company and don't see any BSOD's as a result of my code.

+2  A: 

Generally speaking, you cannot cause a OS crash or bug check from within your application code. That said, if you are looking for general tips and stuff, I recommend the NTDebugging blog. Most of the stuff is way over my head.

What happens when the OS crashes is it will write a kernel dump file, depending on the current flags and so on, you get more or less info in it. You can load up the dump file in windbg or some other debugger. Windbg has the useful !analyze command, which will examine the dump file and give you hints on the bucket the crash fell into, and the possible culprits. Also check the windbg documentation on the general cause of the bug check, and what you can do to resolve it.

1800 INFORMATION
You can cause a BSOD from code by simply calling the related Windows API method. This is what most device drivers are actually doing. Instead of resolving the error, they just put the system in Panic mode. Fortunately, most modern device drivers nowadays try to avoid panic mode and will try to resolve the error instead.
Workshop Alex
+2  A: 

If you want a fairly easy way to find out what caused an OS crash that will work ~90% of the time - assuming you have a crash dump available - then try the following:

  • Download WinDbg as part of the Debugging tools for Windows package
  • Run WinDbg
  • Select "Open Crash Dump" form the file menu
  • When the dump file has loaded type "analyze -v" and press enter
  • WinDbg will do an automated analysis of the crash and will provide a huge amount of information on the system state at the time of the crash. It will usually be able to tell you which module was at fault and what type of error caused the crash. You should also get a stack trace that may or may not be helpful to you.

Note that you will have to configure symbols in WinDbg if you want the stack trace to give you function names.

If the automated analyis is not sufficient then there are a variety of commands that WinDbg provides to enable you to work out exactly what was happening at the time of the crash. The help file is a good place to start in this scenario.

Stu Mackellar