Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

How to solve Windows 8 crashes in less than a minute

Dirk A. D. Smith | April 16, 2013
Windows 8 has been out for a while, featuring an interface that's as cool as it is annoying . . . until you get the hang of it. But, like any computer operating system, it can fall over. Luckily, there is an easy way to solve the cause of most crashes; just call up WinDbg, the Windows debugger; a free tool to diagnose the most common causes of Windows crashes -- misbehaved third party drivers.

If you see the following error, no worries:

*** WARNING: Unable to verify timestamp for myfault.sys

*** ERROR: Module load completed but symbols could not be loaded for myfault.sys

This means that the debugger was looking for information on myfault.sys. However, since it is a third-party driver, there are no symbols for it, since Microsoft does not store all of the third-party drivers. The point is that you can ignore this error message. Vendors do not typically ship drivers with symbol files and they aren't necessary to your work; you can pinpoint the problem driver without them.

So, what caused the crash?

As mentioned above, when you open a dump file with WinDbg it automatically runs a basic analysis that will often nail the culprit without even giving the debugger any direct commands as shown in the screen where it says "Probably caused by : myfault.sys"

More information

Getting a little more information about the crash event and the suspect module is easy. Often, all you need is two commands among the hundreds that the rather powerful debugger offers:

!analyze -v

and

lmvm.

A new way to command WinDbg

Normally, you would type in the commands and parameters you need. Things have changed, however, and Windows too. If you take a good look at the WinDbg interface, just below the "Bugcheck Analysis" box, it says "Use !analyze -v to get detailed debugging information" and that the command is underlined and in blue. Yes, it's a link. Just touch it and the command will be run for you. But, in case you don't have a touch screen, a mouse will work fine or resort to the traditional method of typing the command into the window at the bottom of the interface where you see the prompt "kd>" (which stands for "kernel debugger"). Be sure to do it precisely; this is a case where syntax is key. For instance, note the space between the command and the "-v". The "v" or verbose switch tells WinDbg that you want all the details. You can do the same where you see the link for myfault which will display metadata for the suspect driver.

Output from !analyze -v

The analysis provided by !analyze -v is a combination of English and programmer-speak, but it is nonetheless a great start. In fact, in many cases you will not need to go any further. If you recognize the cause of the crash, you're probably done.

Output from !analyze -v

The !analyze -v provides more detail about the system crash. In this case it accurately describes what the test driver (myfault.sys) was instructed to do; to access an address at an interrupt level that was too high.~~

 

Previous Page  1  2  3  4  5  6  7  8  9  Next Page 

Sign up for CIO Asia eNewsletters.