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.

The other third

While it's true that, by following the instructions above, you'll likely know the cause of two out of three crashes immediately; that does leave that annoying other third. What do you do then? Well, the list of what could have cause the system failure is not short; it can range from a case fan failing, allowing the system to overheat, to bad memory.

Sometimes it's the hardware

If you have recurring crashes but no clear or consistent reason, it may be a memory problem. Two good ways to check memory are the Windows Memory Diagnostic tool and Memtest86. Go to Control Panel and enter "memory" into its search box then select "Diagnose your computer's memory problems".

This simple diagnostic tool is quick and works great. Many people discount the possibility of a memory problem, because they account for such a small percentage of system crashes. However, they are often the cause that keeps you guessing the longest.

Is Windows the culprit?

In all probability: no. For all the naysayers who are quick to blame Redmond for such events, the fact is that Windows is very seldom the cause of a system failure. But, if ntoskrnl.exe (Windows core) or win32.sys (the driver that is most responsible for the "GUI" layer on Windows) is named as the culprit -- and they often are - don't be too quick to accept it. It is far more likely that some errant third-party device driver called upon a Windows component to perform an operation and passed a bad instruction, such as telling it to write to non-existent memory. So, while the operating system certainly can err, exhaust all other possibilities before you blame Microsoft.

What about my antivirus driver?

Often you may see an antivirus driver named as the culprit but there is a good chance it is not guilty. Here's why: for antivirus code to work it must watch all file openings and closings. To accomplish this, the code sits at a low layer in the OS and is constantly working so that he will often be on the stack of function calls that was active when the crash occurred.

Missing vendor information?

Some driver vendors don't take the time to include sufficient information with their modules. So if lmvm doesn't help, try looking at the subdirectories on the image path (if there is one). Often one of them will be the vendor name or a contraction of it. Another option is to search Google. Type in the driver name and/or folder name. You'll probably find the vendor as well as others who have posted information regarding the driver.


Bear in mind that the time it took you to read this primer and to configure WinDbg on your system is far more effort than you will need to solve two of three crashes. Indeed, most crash analysis efforts will take you less than one minute. And, while the other third can certainly be more challenging, at least you'll have more time to try.


Previous Page  1  2  3  4  5  6  7  8  9 

Sign up for CIO Asia eNewsletters.