New BSOD codes for Win8

U

usasma

Retired Admin
Joined
Feb 20, 2012
Posts
2,126
From a post I made in the Admin forums:

...With Win7 the bugchecks stopped at 0x136 (from the bugcodes.h file in the Windows 7 SDK v7.0 and 7.1)

They now go up to STOP 0x14A (20 added: 0x137 - 0x13D, 0x140 - 0x14A and the 2 XBox errors in the next line)
Also, there's been 2 XBox errors added: 0x00000360 and 0x00000420
They have also renamed the 0xc000021A error: WINLOGON_FATAL_ERROR It used to be named: STATUS_SYSTEM_PROCESS_TERMINATED

Here's the end of the latest list from the Win8 SDK (v8.0). I'll be uploading it to carrona.org this morning as an addition (so I'll have both the 7.0 and 8.0 versions (I didn't notice any changes in bugcodes.h with v7.1))

...I'll also upload this to the BSOD forums as a sticky "New BSOD codes for Win8"

EDIT: Entire Win8 SDK bugcodes.h file is uploaded here: http://www.carrona.org/bugcodesv8.html

EDIT:Added the new codes to the BSOD Index page located at http://www.carrona.org/bsodindx.html

Will add a few articles shortly.....
//
// MessageId: WIN32K_HANDLE_MANAGER
//
// MessageText:
//
// WIN32K_HANDLE_MANAGER
//
#define WIN32K_HANDLE_MANAGER ((ULONG)0x00000137L)
//
// MessageId: GPIO_CONTROLLER_DRIVER_ERROR
//
// MessageText:
//
// GPIO_CONTROLLER_DRIVER_ERROR
//
#define GPIO_CONTROLLER_DRIVER_ERROR ((ULONG)0x00000138L)
//
// MessageId: KERNEL_SECURITY_CHECK_FAILURE
//
// MessageText:
//
// KERNEL_SECURITY_CHECK_FAILURE
//
#define KERNEL_SECURITY_CHECK_FAILURE ((ULONG)0x00000139L)
//
// MessageId: KERNEL_MODE_HEAP_CORRUPTION
//
// MessageText:
//
// KERNEL_MODE_HEAP_CORRUPTION
//
#define KERNEL_MODE_HEAP_CORRUPTION ((ULONG)0x0000013AL)
//
// MessageId: PASSIVE_INTERRUPT_ERROR
//
// MessageText:
//
// PASSIVE_INTERRUPT_ERROR
//
#define PASSIVE_INTERRUPT_ERROR ((ULONG)0x0000013BL)
//
// MessageId: INVALID_IO_BOOST_STATE
//
// MessageText:
//
// INVALID_IO_BOOST_STATE
//
#define INVALID_IO_BOOST_STATE ((ULONG)0x0000013CL)
//
// MessageId: CRITICAL_INITIALIZATION_FAILURE
//
// MessageText:
//
// CRITICAL_INITIALIZATION_FAILURE
//
#define CRITICAL_INITIALIZATION_FAILURE ((ULONG)0x0000013DL)
//
// MessageId: STORAGE_DEVICE_ABNORMALITY_DETECTED
//
// MessageText:
//
// STORAGE_DEVICE_ABNORMALITY_DETECTED
//
#define STORAGE_DEVICE_ABNORMALITY_DETECTED ((ULONG)0x00000140L)
//
// MessageId: VIDEO_ENGINE_TIMEOUT_DETECTED
//
// MessageText:
//
// VIDEO_ENGINE_TIMEOUT_DETECTED
//
#define VIDEO_ENGINE_TIMEOUT_DETECTED ((ULONG)0x00000141L)
//
// MessageId: VIDEO_TDR_APPLICATION_BLOCKED
//
// MessageText:
//
// VIDEO_TDR_APPLICATION_BLOCKED
//
#define VIDEO_TDR_APPLICATION_BLOCKED ((ULONG)0x00000142L)
//
// MessageId: PROCESSOR_DRIVER_INTERNAL
//
// MessageText:
//
// PROCESSOR_DRIVER_INTERNAL
//
#define PROCESSOR_DRIVER_INTERNAL ((ULONG)0x00000143L)
//
// MessageId: BUGCODE_USB3_DRIVER
//
// MessageText:
//
// BUGCODE_USB3_DRIVER
//
#define BUGCODE_USB3_DRIVER ((ULONG)0x00000144L)
//
// MessageId: SECURE_BOOT_VIOLATION
//
// MessageText:
//
// SECURE_BOOT_VIOLATION
//
#define SECURE_BOOT_VIOLATION ((ULONG)0x00000145L)
//
// MessageId: NDIS_NET_BUFFER_LIST_INFO_ILLEGALLY_TRANSFERRED
//
// MessageText:
//
// NDIS_NET_BUFFER_LIST_INFO_ILLEGALLY_TRANSFERRED
//
#define NDIS_NET_BUFFER_LIST_INFO_ILLEGALLY_TRANSFERRED ((ULONG)0x00000146L)
//
// MessageId: ABNORMAL_RESET_DETECTED
//
// MessageText:
//
// ABNORMAL_RESET_DETECTED
//
#define ABNORMAL_RESET_DETECTED ((ULONG)0x00000147L)
//
// MessageId: IO_OBJECT_INVALID
//
// MessageText:
//
// IO_OBJECT_INVALID
//
#define IO_OBJECT_INVALID ((ULONG)0x00000148L)
//
// MessageId: REFS_FILE_SYSTEM
//
// MessageText:
//
// REFS_FILE_SYSTEM
//
#define REFS_FILE_SYSTEM ((ULONG)0x00000149L)
//
// MessageId: KERNEL_WMI_INTERNAL
//
// MessageText:
//
// KERNEL_WMI_INTERNAL
//
#define KERNEL_WMI_INTERNAL ((ULONG)0x0000014AL)
//
// MessageId: XBOX_360_SYSTEM_CRASH
//
// MessageText:
//
// XBOX_360_SYSTEM_CRASH
//
#define XBOX_360_SYSTEM_CRASH ((ULONG)0x00000360L)
//
// MessageId: XBOX_360_SYSTEM_CRASH_RESERVED
//
// MessageText:
//
// XBOX_360_SYSTEM_CRASH_RESERVED
//
#define XBOX_360_SYSTEM_CRASH_RESERVED ((ULONG)0x00000420L)
//
// MessageId: HYPERVISOR_ERROR
//
// MessageText:
//
// HYPERVISOR_ERROR
//
#define HYPERVISOR_ERROR ((ULONG)0x00020001L)
#define WINLOGON_FATAL_ERROR ((ULONG)0xC000021AL)
#define MANUALLY_INITIATED_CRASH1 ((ULONG)0xDEADDEAD)
#endif // _BUGCODES_
Click to expand...
 
Last edited:
Many of these actually relate to some of the brand new checks in Driver Verifier for Windows 8, some of which I can find to be very beneficial should they operate correctly.

Btw, the very last one, 0xDEADDEAD, is pretty old. It's whenever someone sets their registry to allow them to force a BSOD using Ctrl+ScrollLock+ScrollLock. Great for initiating live kernel debugging sessions in necessary situations (like certain hangs).
 
Win8 Driver Verifier checks (from Win8 Consumer Preview):
Windows 8 Consumer Preview Verifier tests:
Predefined settings:
- Standard settings
- Force pending I/O requests
- Low resources simulation
- IRP Logging

Individual settings:
- Special pool
- Pool tracking
- Force IRQL checking
- I/O verification
- Deadlock detection
- DMA checking
- Security checks
- Force pending I/O requests
- Low resources simulation
- IRP Logging
- Miscellaneous checks
- Concurrency Stress Test
- DDI compliance checking

New tests listed here: http://msdn.microsoft.com/en-us/library/windows/hardware/hh698274(v=vs.85).aspx
Click to expand...

From http://www.carrona.org/verifier.html
 
If I'm correct, there should also be a couple more smaller checks done under the already existing settings, like Miscellaneous checks or Security checks. I'll need to verify that, though, I could be confabulating. Regardless, the more the merrier. The two new checks, Concurrency Stress Test and DDI Compliance Checking, are more catered towards various system freezes hangs like deadlocks and race conditions. This is definitely a good thing, since often times it's the freezes and hangs that are more difficult to analyze than the BSODs.
 
Vir Gnarus said:
Btw, the very last one, 0xDEADDEAD, is pretty old. It's whenever someone sets their registry to allow them to force a BSOD using Ctrl+ScrollLock+ScrollLock. Great for initiating live kernel debugging sessions in necessary situations (like certain hangs).
Click to expand...

Yes, I did learn that bugcheck is old.

I found it funny when an OP swore he didn't do it, yet every bugcheck was 0xDEADDEAD. OP finally confessed claiming he really did have BSODs, but no dumps were produced. The page file base allocation size was < physical RAM because of RAM upgrade. All was fine in the end.


Vir Gnarus said:
If I'm correct, there should also be a couple more smaller checks done under the already existing settings, like Miscellaneous checks or Security checks. I'll need to verify that, though, I could be confabulating. Regardless, the more the merrier. The two new checks, Concurrency Stress Test and DDI Compliance Checking, are more catered towards various system freezes hangs like deadlocks and race conditions. This is definitely a good thing, since often times it's the freezes and hangs that are more difficult to analyze than the BSODs.
Click to expand...

These 2 are new -
​
(Starting with Windows 8 Consumer Preview) When this option is active, Driver Verifier randomizes thread schedules to help flush out concurrency errors in the driver.


(Starting with Windows 8)
When this option is active, Driver Verifier applies a set of device driver interface (DDI) rules that check for the proper interaction between a driver and the kernel interface of the operating system.​


​
Click to expand...

​
http://msdn.microsoft.com/en-us/library/windows/hardware/ff545470(v=vs.85).aspx
 
Last edited:
That's right, it's because 0xDEADDEAD is what you'd get from older Windows (Windows 98 for example). They replaced it with the 0xE2. I've still had instances (albeit rare) where people have had 0xDEADDEAD BSODs that ended coming from a piece of software that delivered its own crash report.
 
Vir Gnarus said:
That's right, it's because 0xDEADDEAD is what you'd get from older Windows (Windows 98 for example). They replaced it with the 0xE2. I've still had instances (albeit rare) where people have had 0xDEADDEAD BSODs that ended coming from a piece of software that delivered its own crash report.
Click to expand...
I thought bugcheck was a Windows NT concept and that the 9x BSODs were a different thing (the error codes were based on the CPU exception codes, like 0x0e = page fault).
 
Vir Gnarus said:
That's right, it's because 0xDEADDEAD is what you'd get from older Windows (Windows 98 for example). They replaced it with the 0xE2. I've still had instances (albeit rare) where people have had 0xDEADDEAD BSODs that ended coming from a piece of software that delivered its own crash report.
Click to expand...

Did not know that - THANKS!!

Same here -- I've seen them in Windows 7.
 
muhahaa said:
Vir Gnarus said:
That's right, it's because 0xDEADDEAD is what you'd get from older Windows (Windows 98 for example). They replaced it with the 0xE2. I've still had instances (albeit rare) where people have had 0xDEADDEAD BSODs that ended coming from a piece of software that delivered its own crash report.
Click to expand...
I thought bugcheck was a Windows NT concept and that the 9x BSODs were a different thing (the error codes were based on the CPU exception codes, like 0x0e = page fault).
Click to expand...

Yes, you're right, which is why I made sure to specify that it was a 0xDEADDEAD BSOD, not a bugcheck. Win9x kernel did allow you to continue operation - if possible - from a BSOD because they weren't actually STOP errors. They still gave you the BSOD, though. Thanks for pointing out that bit of history, however!
 
Vir Gnarus said:
muhahaa said:
Vir Gnarus said:
That's right, it's because 0xDEADDEAD is what you'd get from older Windows (Windows 98 for example). They replaced it with the 0xE2. I've still had instances (albeit rare) where people have had 0xDEADDEAD BSODs that ended coming from a piece of software that delivered its own crash report.
Click to expand...
I thought bugcheck was a Windows NT concept and that the 9x BSODs were a different thing (the error codes were based on the CPU exception codes, like 0x0e = page fault).
Click to expand...

Yes, you're right, which is why I made sure to specify that it was a 0xDEADDEAD BSOD, not a bugcheck. Win9x kernel did allow you to continue operation - if possible - from a BSOD because they weren't actually STOP errors. They still gave you the BSOD, though. Thanks for pointing out that bit of history, however!
Click to expand...
How is a BSOD triggered in Win9x (what's the function name)?
 
Gosh I really don't remember. That's old hat stuff, and honestly I only started getting into debugging a couple years ago, so it's before my time. I only researched it once out of curiosity.
 
Back
Top