Inside Show - Channel 9

The Windows-X menu provides a rich launch experience into the troubleshooting tools of Windows, including Power Options, Event Viewer, System (also Win-Pause), Device Manager, Network Connections, Disk Management, Computer Management and Command Prompts. Each entry is (quickly) reviewed.

The defaults for WinDbg (font, window layout, etc.) can be set by running WinDbg without a dump file. You configure your preferred look-and-feel and then use File | Save Workspace.We go over our preferences, of note, the colorization of output, and the rendering of tabs as 4 spaces.

The (Windows) Event Viewer shows the event of the system.The "Windows Logs" section contains (of note) the Application, Security and System logs - which have existed since Windows NT 3.1.Event Tracing for Windows (ETW) providers are displayed in the "Applications and Services Log" tree. Logging for individual components can be view, enabled/disabled - and are a great place to start troubleshooting a component.

The (Windows) Task Manager allows a user to view the performance of the system.It contains views that show the overall performance, and the performance per Package/Process. It also shows the currently logged on Users and Services of the computer. These can be controlled by an Administrator.

The (Windows) Device Manager allows a user to view the hardware on the computer.You can use it to installed/update/remove the drivers for the device.The devices can be viewed by Type (e.g. Display adapter, Network adapter, etc.) or Connection (the tree of buses that activates the device).

The !teb extension displays a formatted view of the information in the thread environment block (TEB).The TEB contains information such as the Stack Memory Limits and Last Error/Status Codes.

The !peb extension displays a formatted view of the information in the process environment block (PEB).The PEB contains information such as Process Name, Module List, Environment Variables, Command Line, and many more process level things.

Commands to display Bugcheck Secondary Dump Data.Microsoft Docs:.enumtag (Enumerate Secondary Callback Data)!pde.tagsBugCheckSecondaryDumpDataCallback routine!ext.blackbox*!sysinfo smbios!sysinfo registers

The 32bits in an HRESULT error code have meanings, allowing the reader to gain additional insights into the error.Of note:The 32nd bit (the top bit) indicates if an error occurred or not. This is why errors are 0x8xxxxxxx.The 16-26 bits are the Facility - the originating API (Win32, CLR, XAML, etc.).The 0-15 bits are the (Error) Code.Common NULL Facility Error CodesNameDescriptionValueS_OKOperation successful0x00000000S_FALSEOperation successful but returned no results0x00000001E_ABORTOperation aborted0x80004004E_FAILUnspecified failure0x80004005E_NOINTERFACENo such interface supported0x80004002E_NOTIMPLNot implemented0x80004001E_POINTERPointer that is not valid0x80004003E_UNEXPECTEDUnexpected failure0x8000FFFFCommon Win32 Facility Error CodesThese are built by passing a System Error Code to HRESULT_FROM_WIN32NameDescriptionValueE_ACCESSDENIEDGeneral access denied error0x80070005E_HANDLEHandle that is not valid0x80070006E_INVALIDARGOne or more arguments are not valid0x80070057E_OUTOFMEMORYFailed to allocate necessary memory0x8007000ERelated Links:HRESULTHRESULT Facility – By ValueHRESULT Facility – By Name

An Execute Access Violation occurs when the application attempts to execute code from a memory address that is invalid. To be valid, the memory page must have a valid state, protection and type.The memory must be in the MEM_COMMIT state.The memory can be of any type; MEM_IMAGE, MEM_MAPPED or MEM_PRIVATE. The vast majority is MEM_IMAGE. MEM_PRIVATE is used for Just-in-Time (JIT) code - the main example being JavaScript.The protection of the memory must be PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE or PAGE_EXECUTE_WRITECOPY. The vast majority is PAGE_EXECUTE_READ. PAGE_EXECUTE_READWRITE and PAGE_EXECUTE_WRITECOPY are rare and can be considered dangerous, as code can be modified (injected).To view the state, protection and type of the address, use !address Be sure to reference the current values; not the allocation valuesEach memory page region (minimum 4K) tracks both the initial protection value at allocation, and the current protection value, as set by the VirtualProtect family of functions.The violation is detected by the processor via Data Execution Protection.The memory address may be invalid because of one of these common scenarios:Stack Corruption - the return address of a call is pushed on the stack. Local variables are next to this location. If a local has a buffer overrun, the return address is corrupted.DLL Reference Counting - the address was valid, but is now being accessed after the DLL has been unloadedBit-Flip - RAM (hardware) issue where one or more bits have flipped (rare)Additional Resources:Inside - Access ViolationInside - Access Violation C0000005 - Read or WriteInside - Windows SDKMSDN - Memory Protection ConstantsMSDN - MEMORY_BASIC_INFORMATION structureMSDN - Data Execution Protection

A Read or Write Access Violation occurs when the application attempts to read or write memory from a memory address that is invalid. To be valid, the memory page must have a valid state, protection and type.The memory must be in the MEM_COMMIT state.The memory can be of any type; MEM_IMAGE, MEM_MAPPED or MEM_PRIVATE.For Read operations, the protection of the memory must be PAGE_READONLY, PAGE_READWRITE, PAGE_WRITECOPY, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE or PAGE_EXECUTE_WRITECOPY.For Write operations, the protection of the memory must be PAGE_READWRITE, PAGE_WRITECOPY, PAGE_EXECUTE_READWRITE or PAGE_EXECUTE_WRITECOPY.To view the state, protection and type of the address, use !address Be sure to reference the current values; not the allocation valuesEach memory page region (minimum 4K) tracks both the initial protection value at allocation, and the current protection value, as set by the VirtualProtect family of functions.The memory address may be invalid because of one of these common scenarios:NULL Pointer - addresses between 0x0 and 0x10000 (64K) - e.g. a function that usually returns a pointer returned NULL (0x0), and the pointer was accessed without verificationMemory Corruption - the address was mistakenly or maliciously overwritten - commonly via a buffer overrun (or underrun)Use-After-Free - the address was valid, but is now being accessed after it is freed (data)Bit-Flip - RAM (hardware) issue where one or more bits have flipped (rare)Additional Resources:Inside - Access ViolationInside - Access Violation C0000005 - ExecuteInside - Windows SDKMSDN - Memory Protection ConstantsMSDN - MEMORY_BASIC_INFORMATION structure

An Access Violation is a type of Exception caused when an application Reads, Writes or Executes an invalid Memory Address.The Exception Code is 0xC0000005The first Exception Parameter (0) is the type of the violation; Read (0), Write (1) or Execute (8)The second Exception Parameter (1) is the address of the violation.Follow these steps when debugging these issues with the Debugging Tools for Windows:.exr -1Exception CodeParameter[0] - Read (0), Write (1), Execute (8)Parameter[1] - Address.ecxrRegister values at the Access ViolationAssembler instructionRead - look at the expression on the right of the commaWrite - look at the expression on the left of the commaExecute - look at the address of expressionkView the Call Stack at the Access ViolationThe memory address may be invalid because of one of these common scenarios:NULL Pointer - addresses between 0x0 and 0x10000 (64K) - e.g. a function that usually returns a pointer returned NULL (0x0), and the pointer was accessed without verificationMemory Corruption - the address was mistakenly or maliciously overwritten - commonly via a buffer overrun (or underrun)Use-After-Free - the address was valid, but is now being accessed after it is freed (data) or unloaded (code)Bit-Flip - RAM (hardware) issue where one or more bits have flipped (rare)For Read or Write issues, refer to the Read or Write episode.For Execute issues, refer to the Execute episode.Note that CLR applications with throw a System.NullReferenceException exception instead of an Access Violation exception when the address is between 0x0 and 0x10000 (64K).Additional Resources:Inside - Access Violation C0000005 - Read or WriteInside - Access Violation C0000005 - ExecuteInside - .exrInside - .ecxrInside - Windows SDKMicrosoft Docs - Debugging Tools for WindowsMicrosoft Docs - How Can I Debug a C++ Access Violation?Microsoft Docs - Debugging Native Code FAQs

A CLR Exception is a type of Exception made by .NET applications. The exception is encapsulated in a class derived from the System.Exception class.The Exception Code is 0xE0434352 (a.k.a. Error "CCR" in ASCII).The first Exception Parameter (0) is the HRESULT of the error.Follow these steps when debugging these issues with the Debugging Tools for Windows:.exr -1Exception CodeParameter[0] - HRESULT!sos.peException object - address of class instanceException type - Class name of the exceptionMessage - String description of the exceptionInner Exception - Address of the inner exceptionStack Trace!sos.do Members of the classFor example, the System.IO.FileNotFoundException class has _fileName and _fusionLog members that (sometimes) specify the missing file and/or the CLR Logging of Assembly Load issues (Fusion Logging). Additional Resources:Inside - .exrInside - Windows SDKMicrosoft Docs - Debugging Tools for Windows

A Fail Fast Exception is a type of Exception made by User Mode applications.The Exception Code is 0xC0000409 (a.k.a. STATUS_FAIL_FAST_EXCEPTION).The first Exception Parameter (0) defines the Sub-Code. Some sub-codes use additional Exception Parameters to specify additional detail.Unlike all other exception codes, Fail Fast Exceptions bypass all exception handlers (frame or vector based). Raising this exception terminates the application and invokes Windows Error Reporting, if Windows Error Reporting is enabled.The Exception Code was initially designed to raise a security check failure. Specifically, Guard Segment (/GS) violations. Over time, the desire to have an immediate termination ability was leveraged by applications for non-security reasons. These applications leverage the first parameter to specify the scenario (a sub-code). The original "security check failure" use-case is reserved with a value of 0.The Exception Parameter values are currently not defined due to the per-application nature.The .exr and !analyze commands of the Debugger Tools for Windows provide a description when possible.Additional Resources:Inside - .exrInside - Windows SDKMSDN - RaiseFailFastException functionMicrosoft Docs - Debugging Tools for WindowsMicrosoft Docs - !gs commandMicrosoft Docs - Compiler Option - /GS (Buffer Security Check)Microsoft Docs - Compiler Option - /Gs (Control Stack Checking Calls)

A Point-of-Failure (POF) Exception is a type of Exception made by UWP applications. It was introduced in the Windows 10 Fall Creators Update (Sept. 2017).The Exception Code is 0xC000027C.The first Exception Parameter (0) is an HRESULT. In 64bit dumps, the value needs to be masked down to the bottom 32bits. e.g. 0xFFFFFFFF80070512 => 0x80070512Point-of-Failure Exception replaces/enhances Stowed Exception (0xC000027B). Like Stowed Exceptions, the Exception Code is generated by the WinRT Framework. It does not require applications to be re-compiled for it to be used.A POF Exception is raised when an asynchronous operation fails. When the exception is reported from the worker thread, a Process Shapshot is collected of the process. The PSS handle and HRESULT of the exception is wrapped in an IRestrictedErrorInfo based object and routed through the language projection layers of WinRT. If the exception is not handled by the caller, the Process Snapshot is used to report the issue back at "state" when RoOriginateException or RoOriginateLanguageException was called.Follow these steps when debugging these issues with the Debugging Tools for Windows:.exr -1Determine the HRESULT via the first parameter!error and/or !pde.err Describe the HRESULT.ecxrSet the current debugger context to the Process Snapshot positionkView the call stackAdditional Resources:Inside - Stowed ExceptionInside - .exrInside - .ecxrInside - Windows SDKDefrag Tools - PDE Debugger Extension (via OneDrive link)Microsoft Docs - Debugging Tools for WindowsMSDN - RoOriginateExceptionMSDN - RoOriginateLanguageExceptionMSDN - IRestrictedErrorInfo interface

A Stowed Exception is a type of Exception made by UWP applications. It was introduced in Windows 8.0 as part of WinRT API (now known as UWP).The Exception Code is 0xC000027B.The first Exception Parameter (0) is the starting address of an array of pointers to structures that begin with a STOWED_EXCEPTION_INFORMATION_HEADER structure. Since Windows 8.1, STOWED_EXCEPTION_INFORMATION_V2 has been the version in use.The second Exception Parameter (1) is the number of pointers in the array.Stowed Exception has been replaced/enhanced by the Point-of-Failure Exception (0xC000027C). Like POF Exceptions, the Exception Code is generated by the WinRT Framework. It does not require applications to be re-compiled for it to be used.A Stowed Exception is raised when an asynchronous operation fails. When the exception is reported from the worker thread via a RoOriginateException or RoOriginateLanguageException call, a Stack Backtrace (array of Instruction Pointers) is collected of the current thread via a CaptureStackBackTrace function call. The Stack Backtrace and HRESULT of the exception is wrapped in an IRestrictedErrorInfo object and routed through the language projection layers of WinRT to the caller.If the exception is not handled by the caller, the stowed exception is thrown fatally. Because the throwing is deferred, the current context of the associated dump has little value. The thread of the original issue regularly no longer exists, and if it does, has concluded the operation (meaning the thread's stack memory has been overwritten). This means that function parameters and local variables are not available.Follow these steps when debugging these issues with the Debugging Tools for Windows:.exr -1View the Code, Stowed Exception Array Address and Count via the parameters!pde.dseLists the Stowed ExceptionsEach HRESULT is described (same output as !pde.err)Each Backtrace is displayed as a call stackEach (optionally) nested exception is displayed (e.g. !sos.pe output of a CLR Exception)Additional Resources:Inside - Point-of-Failure ExceptionInside - .exrInside - Windows SDKDefrag Tools - PDE Debugger Extension (via OneDrive link)Defrag Tools - #136 - Debugging User Mode Crash Dumps Part 2Defrag Tools - #167 - Debugging User Mode Crash Dumps ReduxMicrosoft Docs - Debugging Tools for WindowsNTDebugging Blog - Part 1 + Part 2MSDN - RoOriginateExceptionMSDN - RoOriginateLanguageExceptionMSDN - IRestrictedErrorInfo interface

The DRIVER_IRQL_NOT_LESS_OR_EQUAL bug check has a value of 0x000000D1. This indicates that a kernel-mode driver attempted to access pageable memory at a process IRQL that was too high.At the higher IRQL (levels), the kernel blocks attempts to perform the I/O operation, causing the request to fail, and subsequently a failure to access the memory.The Interrupt Request Level (IRQL) is the priority ranking of an interrupt. Each processor has an IRQL setting that threads can raise or lower. Interrupts that occur at or below the processor's IRQL setting are masked and will not interfere with the current operation. Interrupts that occur above the processor's IRQL setting take precedence over the current operation.There are two common forms:1) The address is valid: The driver is incorrectly designed.2) The address is invalid: Memory Corruption has caused the issue. For 1), determine the driver at fault by using "k" or "!analyze -v" in the Debugging Tools for Windows. Once identified, try updating or rolling back the driver. Depending on the vendor, the driver is obtained from Windows Update or the OEM web site. For 2), enable Driver Verifier on the blamed driver (and optionally all 3rd party drivers). The verified drivers will be bounds checked, and the machine will Bugcheck on the cause (rather than the effect). If the issue reproduces, the Driver Verifier based Bugcheck will indicate the driver. If the issue does not reproduce, disable Driver Verifier (to remove the performance overhead). Additional Resources:Inside - Windows SDKMicrosoft Docs - Debugging Tools for WindowsMicrosoft Docs - DRIVER_IRQL_NOT_LESS_OR_EQUALMicrosoft Docs - Driver Verifier

The DRIVER_POWER_STATE_FAILURE bug check has a value of 0x0000009F. This bug check indicates that the driver is in an inconsistent or invalid power state.Parameter 1 indicates the type of violation. Refer to the Microsoft Docs page for details.To determine the device and driver at fault, run "!analyze -v" in the Debugging Tools for Windows. Once identified, try updating or rolling back the driver. Depending on the vendor, the driver is obtained from Windows Update or the OEM web site. If the issue persists with updated drivers, there may be an issue with the device.Additional Resources:Inside - Windows SDKMicrosoft Docs - Debugging Tools for WindowsMicrosoft Docs - DRIVER_POWER_STATE_FAILURE

The MANUALLY_INITIATED_POWER_BUTTON_HOLD bug check has a value of 0x000001C8.The bug check occurs when the power button is held for 7 seconds, but released before the UEFI Reset occurs at 10 seconds.To support Long Power Button Hold, the device needs a General Purpose I/O (GPIO) based Power Button, Firmware to route the power event to the Windows Power Manager, and for the bug check feature to be enabled in the registry.Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlPower] "PowerButtonBugcheck"=dword:00000001 The Long Power Button Hold bug check is similar to the Bugcheck 0xE2 MANUALLY_INITIATED_CRASH, bug check, which is triggered on a keyboard keystroke combination.Since the bug check is at an indeterminate time, there is no explicit issue indicated by the bug check parameters. The entire system needs to be debugged for issues (e.g. Look for Hung IRPs, Processors stuck at a high IRQL, etc.).Additional Resources:Inside - Windows SDKInside - Bugcheck 0xE2 MANUALLY_INITIATED_CRASHMicrosoft Docs - Debugging Tools for Windows

MANUALLY_INITIATED_CRASH bug check has a value of 0x000000E2.The bug check occurs when a keystroke combination is entered on a PS/2 and/or USB Keyboard. To support the Ctrl-Ctrl-Scroll Lock keystroke on USB keyboards, add the kbdhid setting; for PS/2 keyboards, add the i8042prt setting. It is recommended to set both. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceskbdhidParameters] "CrashOnCtrlScroll"=dword:00000001 [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesi8042prtParameters] "CrashOnCtrlScroll"=dword:00000001 The Manually Initiated Crash bug check is similar to the Bugcheck 0x1C8 MANUALLY_INITIATED_LONG_BUTTON_HOLD, bug check, which is triggered on the prolonged hold of the Power Button.Since the bug check is at an indeterminate time, there is no explicit issue indicated by the bug check parameters. The entire system needs to be debugged for issues (e.g. Look for Hung IRPs, Processors stuck at a high IRQL, etc.).Additional Resources:Inside - Windows SDKInside - Bugcheck 0x1C8 MANUALLY_INITIATED_LONG_BUTTON_HOLDInside - Crash On Control Scroll (Lock)Inside - Crash On Custom KeysMicrosoft Docs - Debugging Tools for WindowsMicrosoft Docs - 0xE2: MANUALLY_INITIATED_CRASH

The .trap command change to, and displays the trap frame register state of the context at the specified address. Trap Frames only exist in Kernel Mode. Trap Frames are used to store the registers of the current thread when an interrupt occurs, or when there is a system service call (the transfer from user mode to kernel mode). Note, each trap frame scenario stores only a subset of the registers.To view the trap frames on the current thread, use the kv command. The address of each trap frame is listed as a postfix on each frame that was trapped.Additional Resources:Inside - .ecxr (Change to and Display the Exception Context Record)Inside - .cxr (Change to and Display a Context structure)Inside - Windows SDKMicrosoft Docs - Debugging Tools for WindowsMicrosoft Docs - .cxr (Change to and Display Context Record)Microsoft Docs - .ecxr (Change to and Display Exception Context Record)Microsoft Docs - trap (Display Trap Frame)

The .cxr command changes the debugger context.Using .cxr (without an address) resets the context to the default context.Using .cxr sets the debugger context to the CONTEXT structure values at the specified address.Additional Resources:Inside - .exr (Display Exception Record)Inside - .ecxr (Change to and Display the Exception Context Record)Inside - Windows SDKMicrosoft Docs - Debugging Tools for WindowsMicrosoft Docs - .cxr (Change to and Display Context Record)Microsoft Docs - .ecxr (Change to and Display Exception Context Record)MSDN - CONTEXT structure

The .exr command displays the contents of an exception record (a EXCEPTION_RECORD structure).The EXCEPTION_RECORD structure contains the Instruction Address (the function raising the exception), the Exception Code, and (max 15) Exception Parameters.The structure may be in the addess space of the process (that is, raised by the code itself), or stored in the metadata of the dump file (as past to MiniDumpWriteDump).To view a structure in the address space of the process, use .exr To view the structure saved to the dump, use .exr -1In general, start the debugging of a dump file by executing .exr -1, .ecxr and k. And then use !analyze -v.Additional Resources:Inside - .ecxr (Display, and change to, the Exception Context Record)Inside - Windows SDKMicrosoft Docs - Debugging Tools for WindowsMicrosoft Docs - .exr (Display Exception Record)

The .ecxr command changes to the context that is associated with the dump's exception. It displays the registers at that context.Use .cxr to reset the context to the default context.In general, start the debugging of a dump file by executing .exr -1, .ecxr and k. And then use !analyze -v.Additional Resources:Inside - .exr (Display Exception Record)Inside - .cxr (Change to and Display a Context structure)Inside - Windows SDKMicrosoft Docs - Debugging Tools for WindowsMicrosoft Docs - .ecxr (Display Exception Context Record)MSDN - MiniDumpWriteDump functionMSDN - MINIDUMP_EXCEPTION_INFORMATION structureMSDN - EXCEPTION_POINTERS structureNote: Also supported as ".excr" due to the high occurrence of typos.

The .lastevent command displays the most recent exception or event that occurred.The default debugger context is automatically set to the TID specified.To change the context manually, use the TID as an index: ~~[TID]sMicrosoft Docs:.lastevent (Display Last Event)MiniDumpWriteDump functionMINIDUMP_EXCEPTION_INFORMATION structure The following are displayed:The Process Identifier (PID) in hex (e.g. 5704)The Thread Identifier (TID) in hex (e.g. 4f7c)The Exception Code's descriptionThe Exception Code in hex (e.g. c0000409)The Time of the event 0:000> .lastevent Last event: 5704.4f7c: Security check failure or stack buffer overrun - code c0000409 (first/second chance not available) debugger time: Thu Jul 13 17:46:27.824 2017 (UTC - 7:00)