Inside Show - Channel 9

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 0xC0000005 The 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 => 0x80070512 Point-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

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_MACHINE\SYSTEM\CurrentControlSet\Control\Power]

"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_MACHINE\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters]

"CrashOnCtrlScroll"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters]

"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