INVALID_KERNEL_HANDLE (93) Crash on Vista x64

NTFSD
1

All,

I am seeing this random crash on vista. This handle is kernel handle and is being opened using IoCreateFileSpecifyDeviceObjectHint function as follows. The handle value cc8 is correct, as when i dumped the free handle table i see the following

0: kd> !handle cc8 14
processor number 0, process fffffa80099ee710
PROCESS fffffa80099ee710
SessionId: 0 Cid: 1cb4 Peb: 7fffffde000 ParentCid: 0368
DirBase: 9f2b1000 ObjectTable: fffff88013aa3840 HandleCount: 103.
Image: DfrgNtfs.exe

Kernel Handle table at fffff8800196d000 with 664 Entries in use
0cc8: free handle, Entry address fffff88004665320, Next Entry 019aa5d8000003ec

So looks like this handle was closed, before i was trying to close it. There is not code which can close this handle in my driver.

Any idea who is closing this handle and why? Or how can i find out who is closing this handle before i am trying to close it. Well this issue is random, but happens atleast once a week. Any idea how can i track these handle and find out which is the process who closed it?

this is how handle was opened.
Status = IoCreateFileSpecifyDeviceObjectHint(
&fHandle,
GENERIC_READ,
&initializedAttributes,
&ioSB,
NULL,
FILE_ATTRIBUTE_NORMAL,
0,
FILE_OPEN,
FILE_WRITE_THROUGH|FILE_NO_INTERMEDIATE_BUFFERING|FILE_SYNCHRONOUS_IO_NONALERT,
NULL,
0,
CreateFileTypeNone,
NULL,
IO_IGNORE_SHARE_ACCESS_CHECK,
NULL);

if(!NT_SUCCESS(Status) ||
ioSB.Status == STATUS_REPARSE ||
ioSB.Status == STATUS_DIRECTORY_IS_A_REPARSE_POINT ||
ioSB.Status == STATUS_REPARSE_OBJECT)
{
LogEntry(LOG_LEVEL_DEBUG,“CreateFile: FAILED %wZ Status: %08lX”, uniFileName, Status);
return Status;
}

memory dump

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: 0000000000000cc8, The handle that NtClose was called with.
Arg2: 0000000000000001, means an invalid handle was closed.
Arg3: 0000000000000000
Arg4: 0000000000000000

2

Why not create a kernel handle?

Something in user mode could have closed it. Also, are you sure that you’re
in the same process context that you were when you opened the handle?

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntfsd…
> All,
>
> I am seeing this random crash on vista. This handle is kernel handle and
> is being opened using IoCreateFileSpecifyDeviceObjectHint function as
> follows. The handle value cc8 is correct, as when i dumped the free handle
> table i see the following
>
> 0: kd> !handle cc8 14
> processor number 0, process fffffa80099ee710
> PROCESS fffffa80099ee710
> SessionId: 0 Cid: 1cb4 Peb: 7fffffde000 ParentCid: 0368
> DirBase: 9f2b1000 ObjectTable: fffff88013aa3840 HandleCount: 103.
> Image: DfrgNtfs.exe
>
> Kernel Handle table at fffff8800196d000 with 664 Entries in use
> 0cc8: free handle, Entry address fffff88004665320, Next Entry
> 019aa5d8000003ec
>
>
> So looks like this handle was closed, before i was trying to close it.
> There is not code which can close this handle in my driver.
>
> Any idea who is closing this handle and why? Or how can i find out who is
> closing this handle before i am trying to close it. Well this issue is
> random, but happens atleast once a week. Any idea how can i track these
> handle and find out which is the process who closed it?
>
> this is how handle was opened.
> Status = IoCreateFileSpecifyDeviceObjectHint(
> &fHandle,
> GENERIC_READ,
> &initializedAttributes,
> &ioSB,
> NULL,
> FILE_ATTRIBUTE_NORMAL,
> 0,
> FILE_OPEN,
>
> FILE_WRITE_THROUGH|FILE_NO_INTERMEDIATE_BUFFERING|FILE_SYNCHRONOUS_IO_NONALERT,
> NULL,
> 0,
> CreateFileTypeNone,
> NULL,
> IO_IGNORE_SHARE_ACCESS_CHECK,
> NULL);
>
> if(!NT_SUCCESS(Status) ||
> ioSB.Status == STATUS_REPARSE ||
> ioSB.Status == STATUS_DIRECTORY_IS_A_REPARSE_POINT ||
> ioSB.Status == STATUS_REPARSE_OBJECT)
> {
> LogEntry(LOG_LEVEL_DEBUG,“CreateFile: FAILED %wZ Status: %08lX”,
> uniFileName, Status);
> return Status;
> }
>
> memory dump
>
> 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: 0000000000000cc8, The handle that NtClose was called with.
> Arg2: 0000000000000001, means an invalid handle was closed.
> Arg3: 0000000000000000
> Arg4: 0000000000000000
>
>

3

Its a kernel handle. This is how i initialized the object attributes.

//
// Initialize the object attribs
//

InitializeObjectAttributes( &initializedAttributes,
uniFileName,
OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE,
NULL,
NULL);

So i think being the same process context and someone in the user mode closing the handle may not be valid here.

4

Well, if it’s a kernel handle then someone in kernel mode must have closed
it. There’s not much special you can do to track this down. If it’s a clean
system and there aren’t any funky third party drivers out there it’s
probably pretty likely that it’s your driver’s fault. You might want to
instrument any place that you close handles so that when you get your crash
you can verify if it was indeed you.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntfsd…
> Its a kernel handle. This is how i initialized the object attributes.
>
> //
> // Initialize the object attribs
> //
>
> InitializeObjectAttributes( &initializedAttributes,
> uniFileName,
> OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE,
> NULL,
> NULL);
>
> So i think being the same process context and someone in the user mode
> closing the handle may not be valid here.
>

5

This issue happened on multiple systems, so mostly its something in my driver who closed it.
Is it possible to dump any handle information from the dump, which can lead to who/when closed the handle?

Initially i though IoCreateFileSpecifyDeviceObjectHint function failed and it still returned some garbage handle value. But looks like thats not the case, as this handle was closed.

6

You should start by double-checking that the handle value passed as parameter to ZwClose was indeed a Kernel Handle, i.e. it was one of 0xFFFFFFFF80000cc8 or 0x80000cc8.

If it was indeed a kernel handle, you should use “!handle 0x80000cc8” instead of “!handle 0xcc8”, instructing !handle to look for handle 0xcc8 in the System process, not in the current process.

If you get a repro with Driver Verifier enabled (verifier.exe /standard /driver mydriver.sys), Handle Tracing will be enabled for the System process. You might be able to find who closed the handle this way:

  1. Find the address of the System process:

0: kd> !process 4 0
Searching for Process with Cid == 4
Cid Handle table at 948ef000 with 620 Entries in use
PROCESS 843edd40 SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000 DirBase: 00185000 ObjectTable: 89201df0 HandleCount: 480.
Image: System

843edd40 is the System process’ address on my machine.

  1. Check if someone closed that handle recently:

0: kd> !htrace 0xcc8 843edd40

Dan

7

“You should start by double-checking that the handle value passed as parameter to ZwClose was indeed a Kernel Handle, i.e. it was one of 0xFFFFFFFF80000cc8 or 0x80000cc8.”

Here is my confusion.

This is indeed the kernel handle, i dumped this information and confirmed it see below. The my handle parameter holds value of “0xFFFFFFFF80000cc8” and the bugcheck complains about handle value “Arg1: 0000000000000cc8, The handle that NtClose was called with”.

why is this happening? Isn’t dump should show Arg1: 0xFFFFFFFF80000cc8 or 0x80000cc8. because its a kernel handle.

I will enable the verifier and try to reproduce it and hopefully can trace it.

0: kd> !handle 0xcc8 14

processor number 0, process fffffa80099ee710
PROCESS fffffa80099ee710
SessionId: 0 Cid: 1cb4 Peb: 7fffffde000 ParentCid: 0368
DirBase: 9f2b1000 ObjectTable: fffff88013aa3840 HandleCount: 103.
Image: DfrgNtfs.exe

Kernel Handle table at fffff8800196d000 with 664 Entries in use
0cc8: free handle, Entry address fffff88004665320, Next Entry 00b2f0c0000003ec

0: kd> !handle 0x80000cc8
processor number 0, process fffffa80099ee710
PROCESS fffffa80099ee710
SessionId: 0 Cid: 1cb4 Peb: 7fffffde000 ParentCid: 0368
DirBase: 9f2b1000 ObjectTable: fffff88013aa3840 HandleCount: 103.
Image: DfrgNtfs.exe

Kernel Handle table at fffff8800196d000 with 664 Entries in use
80000cc8: free handle, Entry address fffff88004665320, Next Entry 00b2ef70000003ec

thanks for all the information

8

I agree the description of that bugcheck can be confusing. In the current implementation of ZwClose, the original handle value specified by the driver is not preserved by the time of the bugcheck. Of course we could preserve it, to be able to provide a more clear bugcheck parameter, but it is a bit of a shame to add overhead to ZwClose just to improve the blue screen case. I will forward this information to folks working on Ob and we’ll see if they decide to make changes in this area.

I am surprised that !handle 0x80000cc8 was not smart enough to look at the System process, and looked again at DfrgNtfs.exe. How old is your debugger? (what is the output of “version” from the debugger?) Here’s how my debugger behaves:

0: kd> !handle 0x80000cc8
processor number 0, process fffffa80018469e0
PROCESS fffffa80018469e0
SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000
DirBase: 00187000 ObjectTable: fffff8a000001a70 HandleCount: 477.
Image: System <<<<<<<<<<<<<- looking at the System process, as expected

Kernel Handle table at fffff8a001c65000 with 820 Entries in use
80000cc8: free handle, Entry address fffff8a006eee320, Next Entry 00fc312800000cc4

However, you should be able to workaround that !handle problem by using:

!handle 0xcc8 f fffffa80018469e0

where fffffa80018469e0 was the address of the System process from my machine.

Dan

9

I was using Version 6.10 just upgraded the windbg to 6.11.
!handle 0x80000cc8 is still not looking into the system process, so i used the workaround mentioned by you.

Well i got the same information as by dumping the kernel handle table !handle 0x80000cc8.

processor number 0, process fffffa80036766d0
PROCESS fffffa80036766d0
SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000
DirBase: 00124000 ObjectTable: fffff88000001ea0 HandleCount: 664.
Image: System

Handle table at fffff8800196d000 with 664 Entries in use
0cc8: free handle, Entry address fffff88004665320, Next Entry 01972880000003ec