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.



An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses.

Under Debugging Details the report suggests that the problem was a "WIN_8_DRIVER_FAULT" and that it NotMyFault.exe was active.

Stack dump

An important feature of the debugger's output using !analyze -v is the stack text. Whenever looking at a dump file always look at the far right end of the stack for any third-party drivers. In this case we see myfault. Note that the chronologic sequence of events goes from the bottom to the top; as each new task is performed by the system it shows up at the top. In this rather short stack you can see that myfault was active, then a page fault occurred, and the system declared a BugCheck, which is when the system stopped (Blue Screened).

One way to look at this is that when you see a third-party driver active on the stack when the system crashed, it is like walking into a room and finding a body on the floor and someone standing over it with a smoking gun in his hand; it doesn't mean that he is guilty but makes him suspect No.1.

Output from lmvm (or by selecting myfault)

Knowing the name of a suspect is not enough; you need to know where he lives and what he does. That's where lmvm comes in. It provides a range of data from this image path (not all drivers live in %systemroot%\system32\drivers.), time stamp, image size and file type (in this case a driver) to the company that made it, the product it belongs to, version number and description. Some companies even include contact information for technical support. What the debugger reports, though, is solely dependent upon what the developer included, which, in some cases, is very little.

After you find the vendor's name, go to its Web site and check for updates, knowledge base articles, and other supporting information. If such items do not exist or do not resolve the problem, contact them. They may ask you to send along the debugging information (it is easy to copy the output from the debugger into an e-mail or Word document) or they may ask you to send them the memory dump (zip it up first, both to compress it and protect data integrity).

If you have any questions regarding the use of WinDbg, check out the WinDbg help file. It is excellent. And, when reading about a command be sure to look at the information provided about the many parameters such as "-v" which returns more (verbose) information.


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

Sign up for CIO Asia eNewsletters.