x BlueRobot Administrator Staff member Joined May 7, 2013 Posts 10,194 Location %systemroot% Jun 21, 2021 #1 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. 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 codeDescriptionSTATUS_OBJECT_TYPE_MISMATCHThe ObjectType parameter specifies the wrong object type for the object that is identified by the Handle parameter. Click to expand...
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. 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 codeDescriptionSTATUS_OBJECT_TYPE_MISMATCHThe ObjectType parameter specifies the wrong object type for the object that is identified by the Handle parameter. Click to expand...