Like any computer operating system, Windows 8 can fall over. Luckily, there is an easy way to diagnose 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.
Blue Screen of Death : (
In Windows 8, the Blue Screen of Death/BSOD has been modified to include a large, simple : ( emoticon and a short message in human (if not very informative) language. Also, Microsoft has made advancements in the dump file creation and management process. While this article focuses on W8, the information applies to both Windows RT and Windows Server 2012.
Crashes are protective measures
In most cases, operating systems crash as a protective measure. When the OS discovers that critical devices are failing or that an internal operating system state has been identified as inconsistent because of possible viruses, bad device drivers or RAM failures, it is generally safer to stop immediately before more damage can occur. Two out of three system crashes are caused by third party drivers taking inappropriate actions in Kernel mode, where they have direct access to the OS kernel and to the hardware.
Thanks for the memory dump
A memory dump is the ugliest best friend you’ll ever have. It is a snapshot of the state of the computer system when the operating system stopped. In Windows 8, the OS creates four different memory dumps; Complete, Kernel, and Minidumps and the new Automatic memory dump. From the W8 Style Menu simply type “control panel, which will take you to the Apps page where you should see a white box surrounding “Control Panel.’’ Hit Enter.
The memory dump path
The path to check Windows 8 Memory Dump Settings, beginning at Control Panel, follows: Control Panel | System and Security | System | Advanced system settings | Startup and Recovery | Settings
Startup and Recovery
Once at the Startup and Recovery dialogue box, ensure that “Automatic memory dump” is checked. You will probably also want to ensure that both “Write an event to the system log” and “Automatically restart” (which should also be on by default) are checked.
Install WinDb
To set your PC up for WinDbg-based crash analysis, you will need the following: • 32-bit or 64-bit W8/R2/Server 2012/Win 7/Server 2008, the Debugging Tools for Windows portion of the Windows SDK for Windows 8, and about 100MB of hard disk space. First download sdksetup.exe. either Standard download or automated download.
Run skdsetup.exe
Install the Software Development Kit (SDK). Accept the License Agreement. Remove the check marks for all but Debugging Tools for Windows. Launch sdksetup.exe. Specify Location: The suggested installation path follows: C:\Program Files (x86)\Windows Kits\8.0\ Before calling up a dump file you have to make sure it has access to the symbol files. Symbol tables, available through the use of SymServe, provide that information.
Running WinDbg
From the W8 UI, right-click on the version of WinDbg you will use (x64 or x86) then select “Run as administrator” from the bar that pops up from the bottom of the screen. You will then see a singularly unexciting application interface; a block of gray. Before filling it in with data you must tell it where to find the symbol files. To be sure you are using the correct symbols, at WinDbg’s menu bar, select the following: File | Symbol file path
Symbol search path
In the Symbol search path window enter the following address: srv*c:\cache*https://msdl.microsoft.com/download/symbols
Note that the address between the asterisks is where you want the symbols stored for future reference. For example, I store the symbols in a folder called symbols at the root of my c: drive, thus: srv*c:\symbols*https://msdl.microsoft.com/download/symbols
Make sure that your firewall allows access to msdl.microsoft.com.
Create a dump file
If you don’t have a memory dump to look at, you can generate one yourself by using NotMyFault. To get NotMyFault, go to the Windows Internals Book page at SysInternals and scroll down to the Book Tools section where you will see a download link. Keep in mind that NotMyFault WILL CREATE A SYSTEM CRASH so save any files that contain information that you might otherwise lose and close all applications. Properly prepared, the machine should go down, reboot and both a minidump and a kernel dump should be created.
Running NotMyFault
Launch NotMyFault and select the High IRQL fault (Kernel-mode) then . . . hit the Crash button. Your Frown-of-Frustration will appear in a second, both a minidump and a kernel dump file will be saved and – if properly configured – your system will restart. Over the W8 UI will be a band of blue with the message that “Your PC ran into a problem . . . ”. If you click the “Send details” button, Microsoft will use WinDbg and the command “!analyze” to identify the cause of the problem. The output is combined with a database of known driver bug fixes to help identify the failure.
Launch WinDbg and (often) see the cause of the crash
Launch WinDbg by right-clicking on it from the W8 UI then select ”Run as administrator.’’ Once the debugger is running, select the menu option File | Open Crash Dump and point it to open the dump file you want to analyze. When offered to Save Workspace Information, say Yes. A command window will open. WinDbg will run an analysis and fill the window with the results.
WinDbg Error Messages
Here are common messages, what they mean and how to resolve them.
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
*** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe
When you see these two messages, it means you will not get the analysis that you need. This is confirmed after the “Bugcheck Analysis” is automatically run, and the message ***** Kernel symbols are WRONG. Please fix symbols to do analysis is displayed.
Likely causes
• • The most likely causes of those messages are No path/wrong path; a path to the symbol files has not been set or is incorrect (look for typos); Failed connection; check your Internet connection; Access blocked; a firewall blocked access to the symbol files or the files were damaged during retrieval. Do not go further until this is corrected. 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
So, what caused the crash?
When you open a dump file with WinDbg, it automatically runs a basic analysis which 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” To get more information about the crash event and the suspect module, all you need is two commands: !analyze –v and lmvm.
A new way to command WinDbg
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. It’s a link. Touch it and the command will be run for you.
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 lmvm
lmvm provides a range of data from the image path, 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. After you find the vendor’s name, go to its Web site and check for updates, knowledge base articles, and other supporting information.
The other third
By following the instructions above, you’ll likely know the cause of two out of three crashes immediately, but that leaves the other third. 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”.
Is Windows the culprit?
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.
Best Microsoft MCTS Certification, Microsoft MCITP Training at certkingdom.com
