BSOD: INVALID_KERNEL_HANDLE

NTDEV
1

Hi,
we have a BSOD report happening during uninstall of our driver but without any useful reference to our driver. How could I check if it was caused by our driver, could it be originated in user mode as well?

Thanks,
Hagen

Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/download/symbols;objfre_wnet_amd64\amd64
Executable search path is: objfre_wnet_amd64\amd64
Windows 7 Kernel Version 9200 MP (12 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9200.16581.amd64fre.win8_gdr.130410-1505
Machine Name:
Kernel base = 0xfffff802ce475000 PsLoadedModuleList = 0xfffff802ce741a20
Debug session time: Sun Oct 20 10:47:36.091 2013 (UTC + 1:00)
System Uptime: 0 days 0:07:44.768
Loading Kernel Symbols
…
…
…
Loading User Symbols
Loading unloaded module list
…
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 93, {304, 0, 0, 0}

Probably caused by : Wdf01000.sys ( Wdf01000!FxRegKey::`scalar deleting destructor’+28 )

Followup: MachineOwner

6: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

INVALID_KERNEL_HANDLE (93)
This message occurs if kernel code (server, redirector, other driver, etc.)
attempts to close a handle that is not a valid handle.
Arguments:
Arg1: 0000000000000304, The handle that NtClose was called with.
Arg2: 0000000000000000, means a protected handle was closed.
Arg3: 0000000000000000
Arg4: 0000000000000000

Debugging Details:

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x93

PROCESS_NAME: System

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff802cea728b3 to fffff802ce4cf440

STACK_TEXT:
fffff880031c60f8 fffff802cea728b3 : 0000000000000093 0000000000000304 0000000000000000 0000000000000000 : nt!KeBugCheckEx
fffff880031c6100 fffff802ce4ce453 : 0000000000000000 fffffa8018eaf740 fffff880031c6230 000000000000000a : nt! ?? ::NNGAKEGL::string'+0x3abd0 fffff880031c61b0 fffff802ce4d3630 : fffff8800116db0c fffffa801bb15810 000000000000000a fffffa801bb15850 : nt!KiSystemServiceCopyEnd+0x13 fffff880031c6348 fffff8800116db0c : fffffa801bb15810 000000000000000a fffffa801bb15850 fffff88000647864 : nt!KiServiceLinkage fffff880031c6350 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : Wdf01000!FxRegKey::scalar deleting destructor’+0x28

STACK_COMMAND: kb

FOLLOWUP_IP:
Wdf01000!FxRegKey::scalar deleting destructor'+28 fffff8800116db0c 4883636800 and qword ptr [rbx+68h],0

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: Wdf01000!FxRegKey::`scalar deleting destructor’+28

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Wdf01000

IMAGE_NAME: Wdf01000.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 50eceb04

FAILURE_BUCKET_ID: X64_0x93_Wdf01000!FxRegKey::scalar_deleting_destructor+28

BUCKET_ID: X64_0x93_Wdf01000!FxRegKey::scalar_deleting_destructor+28

Followup: MachineOwner

2

Does it happen without your driver installed? Do you use WDFKEY in your driver? If so, do you extract the wdm handle from them? Make sure you are deleting the WDFKEYs in the scope of use and not leaking them

d

Bent from my phone

From: xxxxx@dynax.atmailto:xxxxx
Sent: ?10/?27/?2013 10:46 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: [ntdev] BSOD: INVALID_KERNEL_HANDLE

Hi,
we have a BSOD report happening during uninstall of our driver but without any useful reference to our driver. How could I check if it was caused by our driver, could it be originated in user mode as well?

Thanks,
Hagen

Symbol search path is: srvc:\symbolshttp://msdl.microsoft.com/download/symbols;objfre_wnet_amd64\amd64
Executable search path is: objfre_wnet_amd64\amd64
Windows 7 Kernel Version 9200 MP (12 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9200.16581.amd64fre.win8_gdr.130410-1505
Machine Name:
Kernel base = 0xfffff802ce475000 PsLoadedModuleList = 0xfffff802ce741a20
Debug session time: Sun Oct 20 10:47:36.091 2013 (UTC + 1:00)
System Uptime: 0 days 0:07:44.768
Loading Kernel Symbols
…
…
…
Loading User Symbols
Loading unloaded module list
…
Bugcheck Analysis



Use !analyze -v to get detailed debugging information.

BugCheck 93, {304, 0, 0, 0}

Probably caused by : Wdf01000.sys ( Wdf01000!FxRegKey::scalar deleting destructor'+28 )<br><br>Followup: MachineOwner<br>---------<br>6: kd&gt; !analyze -v<br> *******************************************************************************<br>* *<br>* Bugcheck Analysis *<br>* *<br>******************************************************************************* <br><br>INVALID_KERNEL_HANDLE (93)<br>This message occurs if kernel code (server, redirector, other driver, etc.)<br>attempts to close a handle that is not a valid handle.<br>Arguments:<br>Arg1: 0000000000000304, The handle that NtClose was called with.<br>Arg2: 0000000000000000, means a protected handle was closed.<br>Arg3: 0000000000000000<br>Arg4: 0000000000000000<br><br>Debugging Details:<br>------------------<br><br>CUSTOMER_CRASH_COUNT: 1<br><br>DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT<br><br>BUGCHECK_STR: 0x93<br><br>PROCESS_NAME: System<br><br>CURRENT_IRQL: 0<br><br>LAST_CONTROL_TRANSFER: from fffff802cea728b3 to fffff802ce4cf440<br><br>STACK_TEXT:<br>fffff880031c60f8 fffff802cea728b3 : 0000000000000093 0000000000000304 0000000000000000 0000000000000000 : nt!KeBugCheckEx<br>fffff880031c6100 fffff802ce4ce453 : 0000000000000000 fffffa8018eaf740 fffff880031c6230 000000000000000a : nt! ?? ::NNGAKEGL::string’+0x3abd0
fffff880031c61b0 fffff802ce4d3630 : fffff8800116db0c fffffa801bb15810 000000000000000a fffffa801bb15850 : nt!KiSystemServiceCopyEnd+0x13
fffff880031c6348 fffff8800116db0c : fffffa801bb15810 000000000000000a fffffa801bb15850 fffff88000647864 : nt!KiServiceLinkage
fffff880031c6350 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : Wdf01000!FxRegKey::scalar deleting destructor'+0x28<br><br>STACK_COMMAND: kb<br><br>FOLLOWUP_IP:<br>Wdf01000!FxRegKey::scalar deleting destructor’+28
fffff8800116db0c 4883636800 and qword ptr [rbx+68h],0<br><br>SYMBOL_STACK_INDEX: 4<br><br>SYMBOL_NAME: Wdf01000!FxRegKey::scalar deleting destructor’+28

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Wdf01000

IMAGE_NAME: Wdf01000.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 50eceb04

FAILURE_BUCKET_ID: X64_0x93_Wdf01000!FxRegKey::scalar_deleting_destructor+28

BUCKET_ID: X64_0x93_Wdf01000!FxRegKey::scalar_deleting_destructor+28

Followup: MachineOwner

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>

3

Here is my best guess at the scenario:

Your driver, in the process of unloading, closes off any handles it has.
But it leaves the now-invalid handle in a data structure. It appears to
be a handle to a Registry key. When the destructor for the key structure
is called, it attempts to close the handle a second time, resulting in
what you see here.

Make sure you have not only closed all your handles, but you have closed
them in a well-behaved fashion. I suspect that if you call the Registry
key close routine, it will set the handle to NULL, thus avoiding this
error.

I have seen the equivalent of this numerous times in app space. It comes
about when a mechanism outside the framework manages to close a handle,
bypassing the proper framework calls, and thus a now-invalid handle is
left. It might be caused, for example, by some kernel-based cleanup
routine.

Another possible cause is the deletion of the actual structure, which may
result in parts of the structure becoming overwritten by storage allocator
bookkeeping bits, which are then misinterpreted as a handle, with the same
consequence. Make sure all your cleanup routines are properly staged.
Calling ExFreePool[WithTag] on a block of memory that is still pointed to
by something that thinks there is a C++ object inside would cause this.

It is most likely a bug in your driver’s shutdown code that results in a
badly-sequenced deletion of objects.
joe

Hi,
we have a BSOD report happening during uninstall of our driver but without
any useful reference to our driver. How could I check if it was caused by
our driver, could it be originated in user mode as well?

Thanks,
Hagen

Symbol search path is:
srv*c:\symbols*http://msdl.microsoft.com/download/symbols;objfre_wnet_amd64\amd64
Executable search path is: objfre_wnet_amd64\amd64
Windows 7 Kernel Version 9200 MP (12 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9200.16581.amd64fre.win8_gdr.130410-1505
Machine Name:
Kernel base = 0xfffff802ce475000 PsLoadedModuleList = 0xfffff802ce741a20
Debug session time: Sun Oct 20 10:47:36.091 2013 (UTC + 1:00)
System Uptime: 0 days 0:07:44.768
Loading Kernel Symbols
…
…
…
Loading User Symbols
Loading unloaded module list
…
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 93, {304, 0, 0, 0}

Probably caused by : Wdf01000.sys ( Wdf01000!FxRegKey::`scalar deleting
destructor’+28 )

Followup: MachineOwner

6: kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

INVALID_KERNEL_HANDLE (93)
This message occurs if kernel code (server, redirector, other driver,
etc.)
attempts to close a handle that is not a valid handle.
Arguments:
Arg1: 0000000000000304, The handle that NtClose was called with.
Arg2: 0000000000000000, means a protected handle was closed.
Arg3: 0000000000000000
Arg4: 0000000000000000

Debugging Details:

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x93

PROCESS_NAME: System

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff802cea728b3 to fffff802ce4cf440

STACK_TEXT:
fffff880031c60f8 fffff802cea728b3 : 0000000000000093 0000000000000304
0000000000000000 0000000000000000 : nt!KeBugCheckEx
fffff880031c6100 fffff802ce4ce453 : 0000000000000000 fffffa8018eaf740
fffff880031c6230 000000000000000a : nt! ?? ::NNGAKEGL::string'+0x3abd0 fffff880031c61b0 fffff802ce4d3630 : fffff8800116db0c fffffa801bb15810 000000000000000a fffffa801bb15850 : nt!KiSystemServiceCopyEnd+0x13 fffff880031c6348 fffff8800116db0c : fffffa801bb15810 000000000000000a fffffa801bb15850 fffff88000647864 : nt!KiServiceLinkage fffff880031c6350 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : Wdf01000!FxRegKey::scalar deleting
destructor’+0x28

STACK_COMMAND: kb

FOLLOWUP_IP:
Wdf01000!FxRegKey::scalar deleting destructor'+28 fffff8800116db0c 4883636800 and qword ptr [rbx+68h],0

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: Wdf01000!FxRegKey::`scalar deleting destructor’+28

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Wdf01000

IMAGE_NAME: Wdf01000.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 50eceb04

FAILURE_BUCKET_ID:
X64_0x93_Wdf01000!FxRegKey::scalar_deleting_destructor+28

BUCKET_ID: X64_0x93_Wdf01000!FxRegKey::scalar_deleting_destructor+28

Followup: MachineOwner

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

>handle from them? Make sure you are deleting the WDFKEYs in the scope of use and not leaking

Won’t they be closed by usual KMDF lifetime rules?

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

5

Yes they will, but this can be a huge leal of the driver never unloads

d

Bent from my phone

From: Maxim S. Shatskihmailto:xxxxx
Sent: ?10/?27/?2013 11:43 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: Re:[ntdev] BSOD: INVALID_KERNEL_HANDLE

>handle from them? Make sure you are deleting the WDFKEYs in the scope of use and not leaking

Won’t they be closed by usual KMDF lifetime rules?

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.commailto:xxxxx
http://www.storagecraft.com

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

6

Are you opening any registry keys in the context of IRP_MJ_DEVICE_IO_CONTROL handler (EvtIoDeviceControl)?

7

Thanks, Doron,

Does it happen without your driver installed? Do you use WDFKEY in your driver?
We only have the user minidump, so I have no idea if the driver was already uninstall or still alive.

If so, do you extract the wdm handle from them? Make sure you are deleting the
WDFKEYs in the scope of use and not leaking them
Yes, we use a WDFKEY and I think you already pointed me to the issue: Only the underlaying WDM key handle is closed by a generic destructor, so the WDF cleanup probably tries to close the key again. This happens every time the driver is unloaded, interestingly its the first BSOD report we have though…

Thanks and cheers,
Hagen.

d

Bent from my phone

8

Thanks everybody, for all the help, guesses and pointers where to look.
This is really appreciated.
Thanks a lot,
Hagen.

9

Once you have dangling values, all bets are off, and the particular error
will appear to happen at random.

Consider a component which properly detects and ignores a request to close
a handle a second time. It does this because it recognizes the handle.

Now, take that block of memory, reallocate it for some other purpose, and
that other purpose overwrites the space that was formerly the handle.

Now, the close-handle logic sees not a valid handle reference, but
complete gibberish. BSOD.

The chance of this happening is based on the storage allocation patterns
that have preceded and followed it. If, by accident, the memory block
remains undisturbed, a valid value is found. If the patterns of
allocation and deallocation have caused it to be reallocated, you get a
BSOD. Note that this might depend on the total sum of allocations and
releases that has occurred since the system has booted. I’ve seen a
system run for five minutes after its internal memory structures were
destroyed, before someone fell into the open manhole.

This is to explain why you may not have seen it before. Bad luck (good
luck means you would have seen it early and fixed it. Extremely bad luck
is where it isn’t found until it is deployed on customer machines).

You might have a better chance of finding it if you run Driver Verifier
with all the memory options (certainly special-pool) enabled. No
guarantees, but it might help.
joe

Thanks, Doron,

> Does it happen without your driver installed? Do you use WDFKEY in your
> driver?
We only have the user minidump, so I have no idea if the driver was
already uninstall or still alive.

> If so, do you extract the wdm handle from them? Make sure you are
> deleting the
> WDFKEYs in the scope of use and not leaking them
Yes, we use a WDFKEY and I think you already pointed me to the issue: Only
the underlaying WDM key handle is closed by a generic destructor, so the
WDF cleanup probably tries to close the key again. This happens every time
the driver is unloaded, interestingly its the first BSOD report we have
though…

Thanks and cheers,
Hagen.

> d

> Bent from my phone

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

10

Thanks Joe,
for the thorough explanation!
The illegal freeing of the WDM handle happens closely to the WDFKEY cleanup during driver unload, which illustrates perfectly what you are saying.

Thanks and cheers,
Hagen.