- May 7, 2013
- 10,400
There isn't much you can do nor say about this bugcheck. It is fairly uncommon and not very well documented by MSDN. I thought I would explain what the bugcheck means since it is actually very simple to understand.
The first parameter contains the address of our corrupted object header. Every object managed by the Object Manager will have an object header, this structure maintains important metadata about the object, such the reference count and number of open handles for the object.
Notice how the pointer doesn't have any value? It does not contain a valid address for the object type structure. So why does the system crash? Let's examine the call stack and we'll see.
The call to ObReferenceObjectByHandleWithTag actually validates the handle passed to it, and ensures that the object type referenced by the handle is same as the object type passed to the function. In order to verify this, let's dump the third parameter for the function call.
Let's dump the pointer for the object type structure and we can see that it belongs to an event object.
Notice how we're referencing an event object in our function call, although, the handle to our object doesn't contain a valid pointer to an event object?
The documentation specifies the following possible error:
Rich (BB code):
BAD_OBJECT_HEADER (189)
The OBJECT_HEADER has been corrupted
Arguments:
Arg1: ffffe00fcb46a730, Pointer to bad OBJECT_HEADER
Arg2: 0000000000000000, Pointer to the resulting OBJECT_TYPE based on the TypeIndex in the OBJECT_HEADER
Arg3: 0000000000000000, The type index is corrupt.
Arg4: 0000000000000000, Reserved.
The first parameter contains the address of our corrupted object header. Every object managed by the Object Manager will have an object header, this structure maintains important metadata about the object, such the reference count and number of open handles for the object.
Rich (BB code):
0: kd> dt _OBJECT_HEADER -y TypeIndex ffffe00fcb46a730
nt!_OBJECT_HEADER
+0x018 TypeIndex : 0 ''
Notice how the pointer doesn't have any value? It does not contain a valid address for the object type structure. So why does the system crash? Let's examine the call stack and we'll see.
Rich (BB code):
0: kd> knL
# Child-SP RetAddr Call Site
00 ffffde02`7c2689a8 fffff804`09fe09b8 nt!KeBugCheckEx
01 ffffde02`7c2689b0 fffff804`09df5bee nt!ObpReferenceObjectByHandleWithTag+0x1eadb8 << Crash here!
02 ffffde02`7c268a40 fffff804`09ee0020 nt!ObReferenceObjectByHandle+0x2e
03 ffffde02`7c268a90 fffff804`09c085b8 nt!NtSetEvent+0x90
04 ffffde02`7c268b00 00007ffa`5602cfe4 nt!KiSystemServiceCopyEnd+0x28
05 000000c5`cc03ece8 00000000`00000000 0x00007ffa`5602cfe4
The call to ObReferenceObjectByHandleWithTag actually validates the handle passed to it, and ensures that the object type referenced by the handle is same as the object type passed to the function. In order to verify this, let's dump the third parameter for the function call.
Rich (BB code):
0: kd> !stack -p
Call Stack : 6 frames
## Stack-Pointer Return-Address Call-Site
00 ffffde027c2689a8 fffff80409fe09b8 nt!KeBugCheckEx+0
Parameter[0] = 0000000000000189
Parameter[1] = ffffe00fcb46a730
Parameter[2] = 0000000000000000
Parameter[3] = 0000000000000000
01 ffffde027c2689b0 fffff80409df5bee nt!ObpReferenceObjectByHandleWithTag+1eadb8 (perf)
Parameter[0] = 00000000000005d0 << Handle value
Parameter[1] = fffff80400000002
Parameter[2] = ffffe00fbf2a1400 << Pointer to _OBJECT_TYPE
Parameter[3] = aaaaaaaaaaaaaa01
02 ffffde027c268a40 fffff80409ee0020 nt!ObReferenceObjectByHandle+2e
Parameter[0] = e00fcb46a730b4cb
Parameter[1] = 0000000000000002
Parameter[2] = (unknown)
Parameter[3] = 0000000000000001
03 ffffde027c268a90 fffff80409c085b8 nt!NtSetEvent+90
Parameter[0] = (unknown)
Parameter[1] = (unknown)
Parameter[2] = (unknown)
Parameter[3] = (unknown)
04 ffffde027c268b00 00007ffa5602cfe4 nt!KiSystemServiceCopyEnd+28
Parameter[0] = 00000000000005d0
Parameter[1] = 0000000000000000
Parameter[2] = 000000c5cc03f148
Parameter[3] = 0000000000000000
Let's dump the pointer for the object type structure and we can see that it belongs to an event object.
Rich (BB code):
0: kd> dt _OBJECT_TYPE ffffe00fbf2a1400
win32k!_OBJECT_TYPE
+0x000 TypeList : _LIST_ENTRY [ 0xffffe00f`bf2a1400 - 0xffffe00f`bf2a1400 ]
+0x010 Name : _UNICODE_STRING "Event"
+0x020 DefaultObject : (null)
+0x028 Index : 0x10 ''
+0x02c TotalNumberOfObjects : 0x5016
+0x030 TotalNumberOfHandles : 0x5639
+0x034 HighWaterNumberOfObjects : 0x559e
+0x038 HighWaterNumberOfHandles : 0x5c1f
+0x040 TypeInfo : _OBJECT_TYPE_INITIALIZER
+0x0b8 TypeLock : _EX_PUSH_LOCK
+0x0c0 Key : 0x6e657645
+0x0c8 CallbackList : _LIST_ENTRY [ 0xffffe00f`bf2a14c8 - 0xffffe00f`bf2a14c8 ]
Notice how we're referencing an event object in our function call, although, the handle to our object doesn't contain a valid pointer to an event object?
The documentation specifies the following possible error:
Return code Description STATUS_OBJECT_TYPE_MISMATCH The ObjectType parameter specifies the wrong object type for the object that is identified by the Handle parameter.