Android Corner

In W8, 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. (Watch a slideshow version that walks you through any crash.]
Also, Microsoft has made advancements in the dump file creation and management process. While this article focuses on W8, the information applies to both RT and Server 2012. For earlier operating systems, see Solve Windows 7 crashes in minutes or, for XP and 2000, see How to solve Windows crashes in minutes.

About Windows crashes

Operating system crashes are quite different from applications crashes, system hangs or other problems. 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 even RAM failures, it is generally safer to stop immediately. Otherwise, continuing operations would allow far more serious damage, such as application data corruption or loss.

[HELP IS ON THE WAY: 
Two out of three system crashes are caused by third party drivers taking inappropriate actions (such as writing to non-existent memory) in Kernel mode where they have direct access to the OS kernel and to the hardware.
In contrast, drivers operating in User Mode, with only indirect access to the OS kernel, cannot directly cause a crash. A small percentage of crashes are caused by hardware issues such as bad memory, even less by faults in the OS itself. And some causes are simply unknown.
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 at the point in time that the operating system stopped. And, of the vast amount of not-very-friendly looking data that a dump file contains, you will usually only need a few items that are easy to grasp and use. With the introduction of Windows 8, the OS now creates four different memory dumps; Complete, Kernel, and Minidumps and the new Automatic memory dump.
1. Automatic memory dump
Location: %SystemRoot%\Memory.dmp
Size: ≈size of OS kernel
The Automatic memory dump is the default option selected when you install Windows 8. It was created to support the "System Managed" page file configuration which has been updated to reduce the page file size on disk. The Automatic memory dump option produces a Kernel memory dump, the difference is when you select Automatic, it allows the SMSS process to reduce the page file smaller than the size of RAM.
2. Complete memory dump
Location: %SystemRoot%\Memory.dmp
Size: ≈size of installed RAM plus 1MB
A complete (or full) memory dump is about equal to the amount of installed RAM. With many systems having multiple GBs, this can quickly become a storage issue, especially if you are having more than the occasional crash. Normally I do not advise saving a full memory dump because they take so much space and are generally unneeded. However, there are cases when working with Microsoft (or another vendor) to find the cause of a very complex problem that the full memory dump would be very helpful. Therefore, stick to the automatic dump, but be prepared to switch the setting to generate a full dump on rare occasions.
3. Kernel memory dump
Location: %SystemRoot%\Memory.dmp
Size: ≈size of physical memory "owned" by kernel-mode components
Kernel dumps are roughly equal in size to the RAM occupied by the Windows 8 kernel. On my test system with 4GB RAM running Windows 8 on a 64-bit processor the kernel dump was about 336MB. Since, on occasion, dump files have to be transported, I compressed it, which brought it down to 80MB. One advantage to a kernel dump is that it contains the binaries which are needed for analysis. The Automatic dump setting creates a kernel dump file by default, saving only the most recent, as well as a minidump for each event.



4. Small or minidump

Location: %SystemRoot%\Minidump
Size: At least 64K on x86 and 128k on x64 (279K on my W8 test PC)
Minidumps include memory pages pointed to them by registers given their values at the point of the fault, as well as the stack of the faulting thread. What makes them small is that they do not contain any of the binary or executable files that were in memory at the time of the failure.
However, those files are critically important for subsequent analysis by the debugger. As long as you are debugging on the machine that created the dump file, WinDbg can find them in the System Root folders (unless the binaries were changed by a system update after the dump file was created). Alternatively the debugger should be able to locate them automatically through SymServ, Microsoft's online store of symbol files. Windows 8 creates and saves a minidump for every crash event, essentially providing a historical record of all events for the life of the system.

Configure W8 to get the right memory dumps

While the default configuration for W8 sets the OS to generate the memory dump format you will most likely need, take a quick look to be sure. From the W8 Style Menu simply type "control panel" (or only the first few letters in many cases) which will auto-magically take you to the Apps page where you should see a white box surrounding "Control Panel"; hitting Enter will take you to that familiar interface.
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
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 WinDbg
System Requirements
To set your PC up for WinDbg-based crash analysis, you will need the following:
• 32-bit or 64-bit Windows 8/R2/Server 2012/Windows 7/Server 2008
Depending on the processor you are running the debugger on, you can use either the 32-bit or the 64-bit debugging tools. Note that it is not important whether the dump file was made on an x86-based or an x64-based platform.
• The Debugging Tools for Windows portion of the Windows SDK for Windows 8, which you can download for free from Microsoft.
• Approximately 103MB of hard disk space (not including storage space for dump files or for symbol files)
• Live Internet connection
Download WinDbg
First download sdksetup.exe, a small file (969KB) that launches the Web setup, from which you select what components to install.
• Standard download.
• Automated download (the download will start on its own):
Space required
Ignore the disk space required of 1.2GB; you will only be installing a small portion of the kit. On my test machine the installation process predicted 256.2MB but only needed 103MB according to File Explorer following installation.
Run skdsetup.exe
Install the Software Development Kit (SDK) to the machine that you will use to view memory dump files.
A. Launch sdksetup.exe.
B. Specify location:
The suggested installation path follows:
C:\Program Files (x86)\Windows Kits\8.0\
If you are downloading to install on a separate computer, choose the second option and set the appropriate path.
C. Accept the License Agreement
D. Remove the check marks for all but Debugging Tools for Windows

What are symbols and why do I need them?

Now that the debugger is installed and before calling up a dump file you have to make sure it has access to the symbol files. Symbol tables are a byproduct of compilation. When a program is compiled, the source code is translated from a high-level language into machine code. At the same time, the compiler creates a symbol file with a list of identifiers, their locations in the program, and their attributes. Since programs don't need this information to execute, it can be taken out and stored in another file. This reduces the size of the final executable so it takes up less disk space and loads faster into memory. But, when a program causes a problem, the OS only knows the hex address at which the problem occurred, not who was there and what the person was doing. Symbol tables, available through the use of SymServe, provide that information.
SymServ (SymSrv)
SymServ (also spelled SymSrv) is a critically important utility provided by Microsoft that manages the identification of the correct symbol tables to be retrieved for use by WinDbg. There is no charge for its use and it functions automatically in the background as long as the debugger is properly configured, and has unfettered access to the symbol store at Microsoft.