Driver close of registry key results in a INVALID_KERNEL_HANDLE bugcheck

NTDEV
1

Driver opens
L"\REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Perflib\009"

This works and the returned handle is always
0x80000050 (aka HKEY_PERFORMANCE_TEXT).

The driver closes the key which results in a
INVALID_KERNEL_HANDLE bugcheck.

Other registry keys open and close fine.

I have tried with and without OBJ_KERNEL_HANDLE.

This has been tested on XP SP2 and 2K3.

Here is the snippet that blows up:

RtlInitUnicodeString(&us,
L"\REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Perflib\009");
InitializeObjectAttributes(&oa, &us,
OBJ_CASE_INSENSITIVE /*| OBJ_KERNEL_HANDLE*/, NULL,
NULL);
status = ZwOpenKey(&handle, KEY_ALL_ACCESS, &oa);
if (NT_SUCCESS(status))
{
status = ZwClose(handle);
}

Note that Arg2 in the bugcheck is sometimes 0 which
means that a protected handle was closed (don't know
what "protected" means in this context)

Here is a copy of !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: 00000050, The handle that NtClose was called
with.
Arg2: 00000001, means an invalid handle was closed.
Arg3: 00000000
Arg4: 00000000

Debugging Details:

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x93

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 80542289 to 804df1c0

STACK_TEXT:
f336075c 80542289 00000003 00000050 00000000
nt!RtlpBreakWithStatusInstruction
f33607a8 80543108 00000003 824072f8 81d9f9e8
nt!KiBugCheckDebugBreak+0x19
f3360b10 805435b9 00000093 00000050 00000001
nt!KeBugCheck2+0x4a8
f3360b30 805fa4ca 00000093 00000050 00000001
nt!KeBugCheckEx+0x19
f3360b78 80586d17 00000050 00000000 804dfd24
nt!ObpCloseHandle+0x164
f3360b84 804dfd24 80000050 80587fa4 e11e9378
nt!NtClose+0x17
f3360b84 804ea881 80000050 80587fa4 e11e9378
nt!KiSystemService+0xd0
f3360c00 f899fbed 80000050 95000004 80000050
nt!ZwClose+0x11
WARNING: Stack unwind information not available.
Following frames may be wrong.
f3360c3c 804f04f3 826492b0 81e3fce8 823e51f8
SampleDriver+0xbed
f3360c4c 80585208 81e3fd58 823e51f8 81e3fce8
nt!IofCallDriver+0x3f
f3360c60 80585fe6 826492b0 81e3fce8 823e51f8
nt!IopSynchronousServiceTail+0x6f
f3360d00 80586028 000007e8 00000000 00000000
nt!IopXxxControlFile+0x607
f3360d34 804dfd24 000007e8 00000000 00000000
nt!NtDeviceIoControlFile+0x28
f3360d34 7ffe0304 000007e8 00000000 00000000
nt!KiSystemService+0xd0
0006fea4 77f426cb 77e4b2eb 000007e8 00000000
SharedUserData!SystemCallStub+0x4
0006fea8 77e4b2eb 000007e8 00000000 00000000
ntdll!NtDeviceIoControlFile+0xc
0006ff0c 01001304 000007e8 95000004 00000000
kernel32!DeviceIoControl+0x137
0006ff44 01001478 00000002 00263810 002629c0
SampleDriverProgram+0x1304
0006ffc0 77e4f38c 00000000 00000000 7ffdf000
SampleDriverProgram+0x1478
0006fff0 00000000 01001349 00000000 78746341
kernel32!BaseProcessStart+0x23

FOLLOWUP_IP:
SampleDriver+bed
f899fbed 8945f8 mov [ebp-0x8],eax

SYMBOL_STACK_INDEX: 8

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: SampleDriver+bed

MODULE_NAME: SampleDriver

IMAGE_NAME: SampleDriver.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 416ae0c4

STACK_COMMAND: kb

BUCKET_ID: 0x93_SampleDriver+bed

Followup: MachineOwner

Any ideas?

Thanks,

Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo

2

The handle is not valid. I noticed you removed the OBJ_KERNEL_HANDLE
attribute - are you sure you are in the same process context when you
closed it as when you created it?

At any rate, the OS is telling you that you tried to close a handle that
doesn't have a corresponding entry in the object handle table for the
given process. Since you did this in kernel mode, it bug checked.

Regards,

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Randy Cook
Sent: Monday, October 11, 2004 5:16 PM
To: ntdev redirect
Subject: [ntdev] Driver close of registry key results in a
INVALID_KERNEL_HANDLE bugcheck

Driver opens
L"\REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Perflib\009"

This works and the returned handle is always
0x80000050 (aka HKEY_PERFORMANCE_TEXT).

The driver closes the key which results in a
INVALID_KERNEL_HANDLE bugcheck.

Other registry keys open and close fine.

I have tried with and without OBJ_KERNEL_HANDLE.

This has been tested on XP SP2 and 2K3.

Here is the snippet that blows up:

RtlInitUnicodeString(&us,
L"\REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Perflib\009");
InitializeObjectAttributes(&oa, &us,
OBJ_CASE_INSENSITIVE /*| OBJ_KERNEL_HANDLE*/, NULL,
NULL);
status = ZwOpenKey(&handle, KEY_ALL_ACCESS, &oa);
if (NT_SUCCESS(status))
{
status = ZwClose(handle);
}

Note that Arg2 in the bugcheck is sometimes 0 which
means that a protected handle was closed (don't know
what "protected" means in this context)

Here is a copy of !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: 00000050, The handle that NtClose was called
with.
Arg2: 00000001, means an invalid handle was closed.
Arg3: 00000000
Arg4: 00000000

Debugging Details:

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x93

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 80542289 to 804df1c0

STACK_TEXT:
f336075c 80542289 00000003 00000050 00000000
nt!RtlpBreakWithStatusInstruction
f33607a8 80543108 00000003 824072f8 81d9f9e8
nt!KiBugCheckDebugBreak+0x19
f3360b10 805435b9 00000093 00000050 00000001
nt!KeBugCheck2+0x4a8
f3360b30 805fa4ca 00000093 00000050 00000001
nt!KeBugCheckEx+0x19
f3360b78 80586d17 00000050 00000000 804dfd24
nt!ObpCloseHandle+0x164
f3360b84 804dfd24 80000050 80587fa4 e11e9378
nt!NtClose+0x17
f3360b84 804ea881 80000050 80587fa4 e11e9378
nt!KiSystemService+0xd0
f3360c00 f899fbed 80000050 95000004 80000050
nt!ZwClose+0x11
WARNING: Stack unwind information not available.
Following frames may be wrong.
f3360c3c 804f04f3 826492b0 81e3fce8 823e51f8
SampleDriver+0xbed
f3360c4c 80585208 81e3fd58 823e51f8 81e3fce8
nt!IofCallDriver+0x3f
f3360c60 80585fe6 826492b0 81e3fce8 823e51f8
nt!IopSynchronousServiceTail+0x6f
f3360d00 80586028 000007e8 00000000 00000000
nt!IopXxxControlFile+0x607
f3360d34 804dfd24 000007e8 00000000 00000000
nt!NtDeviceIoControlFile+0x28
f3360d34 7ffe0304 000007e8 00000000 00000000
nt!KiSystemService+0xd0
0006fea4 77f426cb 77e4b2eb 000007e8 00000000
SharedUserData!SystemCallStub+0x4
0006fea8 77e4b2eb 000007e8 00000000 00000000
ntdll!NtDeviceIoControlFile+0xc
0006ff0c 01001304 000007e8 95000004 00000000
kernel32!DeviceIoControl+0x137
0006ff44 01001478 00000002 00263810 002629c0
SampleDriverProgram+0x1304
0006ffc0 77e4f38c 00000000 00000000 7ffdf000
SampleDriverProgram+0x1478
0006fff0 00000000 01001349 00000000 78746341
kernel32!BaseProcessStart+0x23

FOLLOWUP_IP:
SampleDriver+bed
f899fbed 8945f8 mov [ebp-0x8],eax

SYMBOL_STACK_INDEX: 8

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: SampleDriver+bed

MODULE_NAME: SampleDriver

IMAGE_NAME: SampleDriver.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 416ae0c4

STACK_COMMAND: kb

BUCKET_ID: 0x93_SampleDriver+bed

Followup: MachineOwner

Any ideas?

Thanks,

Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

I am definitely in the same context. I do the close
right after the open in this sample driver. I also
have tried with OBJ_KERNEL_HANDLE. Also, any other
reg path works fine. It seems that there is something
different about this specific reg path.

Thanks,

— Tony Mason wrote:

> The handle is not valid. I noticed you removed the
> OBJ_KERNEL_HANDLE
> attribute - are you sure you are in the same process
> context when you
> closed it as when you created it?
>
> At any rate, the OS is telling you that you tried to
> close a handle that
> doesn’t have a corresponding entry in the object
> handle table for the
> given process. Since you did this in kernel mode,
> it bug checked.
>
> Regards,
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> Randy Cook
> Sent: Monday, October 11, 2004 5:16 PM
> To: ntdev redirect
> Subject: [ntdev] Driver close of registry key
> results in a
> INVALID_KERNEL_HANDLE bugcheck
>
> Driver opens
> L"\REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows
> NT\CurrentVersion\Perflib\009"
>
> This works and the returned handle is always
> 0x80000050 (aka HKEY_PERFORMANCE_TEXT).
>
> The driver closes the key which results in a
> INVALID_KERNEL_HANDLE bugcheck.
>
> Other registry keys open and close fine.
>
> I have tried with and without OBJ_KERNEL_HANDLE.
>
> This has been tested on XP SP2 and 2K3.
>
> Here is the snippet that blows up:
>
> RtlInitUnicodeString(&us,
> L"\REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows
> NT\CurrentVersion\Perflib\009");
> InitializeObjectAttributes(&oa, &us,
> OBJ_CASE_INSENSITIVE /| OBJ_KERNEL_HANDLE/, NULL,
> NULL);
> status = ZwOpenKey(&handle, KEY_ALL_ACCESS, &oa);
> if (NT_SUCCESS(status))
> {
> status = ZwClose(handle);
> }
>
> Note that Arg2 in the bugcheck is sometimes 0 which
> means that a protected handle was closed (don’t know
> what “protected” means in this context)
>
> Here is a copy of !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: 00000050, The handle that NtClose was called
> with.
> Arg2: 00000001, means an invalid handle was closed.
> Arg3: 00000000
> Arg4: 00000000
>
> Debugging Details:
> ------------------
>
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0x93
>
> CURRENT_IRQL: 0
>
> LAST_CONTROL_TRANSFER: from 80542289 to 804df1c0
>
> STACK_TEXT:
> f336075c 80542289 00000003 00000050 00000000
> nt!RtlpBreakWithStatusInstruction
> f33607a8 80543108 00000003 824072f8 81d9f9e8
> nt!KiBugCheckDebugBreak+0x19
> f3360b10 805435b9 00000093 00000050 00000001
> nt!KeBugCheck2+0x4a8
> f3360b30 805fa4ca 00000093 00000050 00000001
> nt!KeBugCheckEx+0x19
> f3360b78 80586d17 00000050 00000000 804dfd24
> nt!ObpCloseHandle+0x164
> f3360b84 804dfd24 80000050 80587fa4 e11e9378
> nt!NtClose+0x17
> f3360b84 804ea881 80000050 80587fa4 e11e9378
> nt!KiSystemService+0xd0
> f3360c00 f899fbed 80000050 95000004 80000050
> nt!ZwClose+0x11
> WARNING: Stack unwind information not available.
> Following frames may be wrong.
> f3360c3c 804f04f3 826492b0 81e3fce8 823e51f8
> SampleDriver+0xbed
> f3360c4c 80585208 81e3fd58 823e51f8 81e3fce8
> nt!IofCallDriver+0x3f
> f3360c60 80585fe6 826492b0 81e3fce8 823e51f8
> nt!IopSynchronousServiceTail+0x6f
> f3360d00 80586028 000007e8 00000000 00000000
> nt!IopXxxControlFile+0x607
> f3360d34 804dfd24 000007e8 00000000 00000000
> nt!NtDeviceIoControlFile+0x28
> f3360d34 7ffe0304 000007e8 00000000 00000000
> nt!KiSystemService+0xd0
> 0006fea4 77f426cb 77e4b2eb 000007e8 00000000
> SharedUserData!SystemCallStub+0x4
> 0006fea8 77e4b2eb 000007e8 00000000 00000000
> ntdll!NtDeviceIoControlFile+0xc
> 0006ff0c 01001304 000007e8 95000004 00000000
> kernel32!DeviceIoControl+0x137
> 0006ff44 01001478 00000002 00263810 002629c0
> SampleDriverProgram+0x1304
> 0006ffc0 77e4f38c 00000000 00000000 7ffdf000
> SampleDriverProgram+0x1478
> 0006fff0 00000000 01001349 00000000 78746341
> kernel32!BaseProcessStart+0x23
>
>
> FOLLOWUP_IP:
> SampleDriver+bed
> f899fbed 8945f8 mov [ebp-0x8],eax
>
> SYMBOL_STACK_INDEX: 8
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: SampleDriver+bed
>
> MODULE_NAME: SampleDriver
>
> IMAGE_NAME: SampleDriver.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 416ae0c4
>
> STACK_COMMAND: kb
>
> BUCKET_ID: 0x93_SampleDriver+bed
>
> Followup: MachineOwner
>
>
>
> Any ideas?
>
> Thanks,
>
>
>
> ___
> Do you Yahoo!?
> Take Yahoo! Mail with you! Get it on your mobile
> phone.
> http://mobile.yahoo.com/maildemo
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@osr.com
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown
> lmsubst tag argument: ‘’
>
=== message truncated ===
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

4

Randy,

I don’t know WHY the handle is invalid, but the only reason this bug
check occurs is because the OS tried to find the handle in the object
handle table and it wasn’t there.

Are you sure you have not already closed this handle? Is this the same
value you first obtained for the handle? I’ve seen crashes where the
memory containing the handle was overwritten cause this type of problem
as well, although the fact you have 0x50 suggests that’s not the case.

Did you try “!handle” to look at the handle table? Did you confirm that
you aren’t attached in this call?

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Randy Cook
Sent: Monday, October 11, 2004 5:47 PM
To: ntdev redirect
Subject: RE: [ntdev] Driver close of registry key results in a
INVALID_KERNEL_HANDLE bugcheck

I am definitely in the same context. I do the close
right after the open in this sample driver. I also
have tried with OBJ_KERNEL_HANDLE. Also, any other
reg path works fine. It seems that there is something
different about this specific reg path.

Thanks,

— Tony Mason wrote:

> The handle is not valid. I noticed you removed the
> OBJ_KERNEL_HANDLE
> attribute - are you sure you are in the same process
> context when you
> closed it as when you created it?
>
> At any rate, the OS is telling you that you tried to
> close a handle that
> doesn’t have a corresponding entry in the object
> handle table for the
> given process. Since you did this in kernel mode,
> it bug checked.
>
> Regards,
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> Randy Cook
> Sent: Monday, October 11, 2004 5:16 PM
> To: ntdev redirect
> Subject: [ntdev] Driver close of registry key
> results in a
> INVALID_KERNEL_HANDLE bugcheck
>
> Driver opens
> L"\REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows
> NT\CurrentVersion\Perflib\009"
>
> This works and the returned handle is always
> 0x80000050 (aka HKEY_PERFORMANCE_TEXT).
>
> The driver closes the key which results in a
> INVALID_KERNEL_HANDLE bugcheck.
>
> Other registry keys open and close fine.
>
> I have tried with and without OBJ_KERNEL_HANDLE.
>
> This has been tested on XP SP2 and 2K3.
>
> Here is the snippet that blows up:
>
> RtlInitUnicodeString(&us,
> L"\REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows
> NT\CurrentVersion\Perflib\009");
> InitializeObjectAttributes(&oa, &us,
> OBJ_CASE_INSENSITIVE /| OBJ_KERNEL_HANDLE/, NULL,
> NULL);
> status = ZwOpenKey(&handle, KEY_ALL_ACCESS, &oa);
> if (NT_SUCCESS(status))
> {
> status = ZwClose(handle);
> }
>
> Note that Arg2 in the bugcheck is sometimes 0 which
> means that a protected handle was closed (don’t know
> what “protected” means in this context)
>
> Here is a copy of !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: 00000050, The handle that NtClose was called
> with.
> Arg2: 00000001, means an invalid handle was closed.
> Arg3: 00000000
> Arg4: 00000000
>
> Debugging Details:
> ------------------
>
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0x93
>
> CURRENT_IRQL: 0
>
> LAST_CONTROL_TRANSFER: from 80542289 to 804df1c0
>
> STACK_TEXT:
> f336075c 80542289 00000003 00000050 00000000
> nt!RtlpBreakWithStatusInstruction
> f33607a8 80543108 00000003 824072f8 81d9f9e8
> nt!KiBugCheckDebugBreak+0x19
> f3360b10 805435b9 00000093 00000050 00000001
> nt!KeBugCheck2+0x4a8
> f3360b30 805fa4ca 00000093 00000050 00000001
> nt!KeBugCheckEx+0x19
> f3360b78 80586d17 00000050 00000000 804dfd24
> nt!ObpCloseHandle+0x164
> f3360b84 804dfd24 80000050 80587fa4 e11e9378
> nt!NtClose+0x17
> f3360b84 804ea881 80000050 80587fa4 e11e9378
> nt!KiSystemService+0xd0
> f3360c00 f899fbed 80000050 95000004 80000050
> nt!ZwClose+0x11
> WARNING: Stack unwind information not available.
> Following frames may be wrong.
> f3360c3c 804f04f3 826492b0 81e3fce8 823e51f8
> SampleDriver+0xbed
> f3360c4c 80585208 81e3fd58 823e51f8 81e3fce8
> nt!IofCallDriver+0x3f
> f3360c60 80585fe6 826492b0 81e3fce8 823e51f8
> nt!IopSynchronousServiceTail+0x6f
> f3360d00 80586028 000007e8 00000000 00000000
> nt!IopXxxControlFile+0x607
> f3360d34 804dfd24 000007e8 00000000 00000000
> nt!NtDeviceIoControlFile+0x28
> f3360d34 7ffe0304 000007e8 00000000 00000000
> nt!KiSystemService+0xd0
> 0006fea4 77f426cb 77e4b2eb 000007e8 00000000
> SharedUserData!SystemCallStub+0x4
> 0006fea8 77e4b2eb 000007e8 00000000 00000000
> ntdll!NtDeviceIoControlFile+0xc
> 0006ff0c 01001304 000007e8 95000004 00000000
> kernel32!DeviceIoControl+0x137
> 0006ff44 01001478 00000002 00263810 002629c0
> SampleDriverProgram+0x1304
> 0006ffc0 77e4f38c 00000000 00000000 7ffdf000
> SampleDriverProgram+0x1478
> 0006fff0 00000000 01001349 00000000 78746341
> kernel32!BaseProcessStart+0x23
>
>
> FOLLOWUP_IP:
> SampleDriver+bed
> f899fbed 8945f8 mov [ebp-0x8],eax
>
> SYMBOL_STACK_INDEX: 8
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: SampleDriver+bed
>
> MODULE_NAME: SampleDriver
>
> IMAGE_NAME: SampleDriver.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 416ae0c4
>
> STACK_COMMAND: kb
>
> BUCKET_ID: 0x93_SampleDriver+bed
>
> Followup: MachineOwner
>
>
>
> Any ideas?
>
> Thanks,
>
>
>
> ___
> Do you Yahoo!?
> Take Yahoo! Mail with you! Get it on your mobile
> phone.
> http://mobile.yahoo.com/maildemo
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@osr.com
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown
> lmsubst tag argument: ‘’
>
=== message truncated ===
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

Tony,

Thanks for looking at this.

I noticed this first in my driver. So, to make sure
it wasn’t anything weird (like memory overwrites),
another developer here created a driver that just does
this when a ioctl comes in … and that is all this
driver does.

Are you sure you have not already closed this
handle?
Yes.

Is this the same
value you first obtained for the handle?
Yes.

Did you try “!handle” to look at the handle table?
I stepped over the ZwOpenKey. The status was 0 and
the returned handle is 0x80000050. I dump the handle
table and this is what I see:

0: kd> !handle
processor number 0
PROCESS 822d1b08 SessionId: 0 Cid: 0e90 Peb:
7ffdf000 ParentCid: 0dbc
DirBase: 16fb8000 ObjectTable: e11b5b88
HandleCount: 8.
Image: SampleDriverPro

New version of handle table at e1412000 with 8 Entries
in use
07e0: Object: 82580298 GrantedAccess: 000f037f
Object: 82580298 Type: (826a9730) WindowStation
ObjectHeader: 82580280
HandleCount: 23 PointerCount: 38
Directory Object: e18b31a0 Name: WinSta0

07e4: Object: 823070a0 GrantedAccess: 001f0003
Object: 823070a0 Type: (826aa6f0) Event
ObjectHeader: 82307088
HandleCount: 3 PointerCount: 3

07e8: Object: 82643360 GrantedAccess: 0012019f
Object: 82643360 Type: (826d1e70) File
ObjectHeader: 82643348
HandleCount: 1 PointerCount: 3

07ec: Object: e2065ed8 GrantedAccess: 001f0001
Object: e2065ed8 Type: (826d2910) Port
ObjectHeader: e2065ec0
HandleCount: 1 PointerCount: 2

07f0: Object: 82645c28 GrantedAccess: 00100020
(Inherit)
Object: 82645c28 Type: (826d1e70) File
ObjectHeader: 82645c10
HandleCount: 1 PointerCount: 1
Directory Object: 00000000 Name: \fslx
{HarddiskVolume1}

07f4: Object: e198df60 GrantedAccess: 00000003
Object: e198df60 Type: (826d4110) Directory
ObjectHeader: e198df48
HandleCount: 29 PointerCount: 61
Directory Object: e1001b48 Name: KnownDlls

07f8: Object: 82420510 GrantedAccess: 001f0003
Object: 82420510 Type: (826aa6f0) Event
ObjectHeader: 824204f8
HandleCount: 1 PointerCount: 1

07fc: Object: e1001738 GrantedAccess: 00000003
Object: e1001738 Type: (826a9900) KeyedEvent
ObjectHeader: e1001720
HandleCount: 30 PointerCount: 31
Directory Object: e1003ae8 Name:
CritSecOutOfMemoryEvent

Did you confirm that
you aren’t attached in this call?
I don’t know what this means.

Thanks again.

Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

6

Randy,

The handle you indicated is a system handle, which means it is stored in
the system process handle table. This won’t show up in the process
handle table for the process you are showing, because the high bit is
set - indicating that this is a handle in the system process. You’d
need to look at the system process to find that handle (see the
documentation for “!handle” for information on dumping the handle table
for a different process).

Attachment has to do with the calls KeAttachProcess or
KeStackAttachProcess. In this case, the thread becomes temporarily
associated with a different process - including its handle table.

I don’t know why your handle is not valid, but there’s no magic code in
the object manager that singles out this path. If you aren’t closing
this handle, some OTHER component is closing this handle.

My suggestion would be to try building a totally separate driver - one
with just a DriverEntry function. In that entry point, open and then
close that registry key, and then return a failure code. I do this when
I’m probing the OS level functionality generally.

Also, try changing your handle from a local (automatic) variable to a
global (or static) variable. Then, if this is some sort of memory
overwrite condition you’ll be able to tell as well.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Randy Cook
Sent: Monday, October 11, 2004 6:47 PM
To: ntdev redirect
Subject: RE: [ntdev] Driver close of registry key results in a
INVALID_KERNEL_HANDLE bugcheck

Tony,

Thanks for looking at this.

I noticed this first in my driver. So, to make sure
it wasn’t anything weird (like memory overwrites),
another developer here created a driver that just does
this when a ioctl comes in … and that is all this
driver does.

Are you sure you have not already closed this
handle?
Yes.

Is this the same
value you first obtained for the handle?
Yes.

Did you try “!handle” to look at the handle table?
I stepped over the ZwOpenKey. The status was 0 and
the returned handle is 0x80000050. I dump the handle
table and this is what I see:

0: kd> !handle
processor number 0
PROCESS 822d1b08 SessionId: 0 Cid: 0e90 Peb:
7ffdf000 ParentCid: 0dbc
DirBase: 16fb8000 ObjectTable: e11b5b88
HandleCount: 8.
Image: SampleDriverPro

New version of handle table at e1412000 with 8 Entries
in use
07e0: Object: 82580298 GrantedAccess: 000f037f
Object: 82580298 Type: (826a9730) WindowStation
ObjectHeader: 82580280
HandleCount: 23 PointerCount: 38
Directory Object: e18b31a0 Name: WinSta0

07e4: Object: 823070a0 GrantedAccess: 001f0003
Object: 823070a0 Type: (826aa6f0) Event
ObjectHeader: 82307088
HandleCount: 3 PointerCount: 3

07e8: Object: 82643360 GrantedAccess: 0012019f
Object: 82643360 Type: (826d1e70) File
ObjectHeader: 82643348
HandleCount: 1 PointerCount: 3

07ec: Object: e2065ed8 GrantedAccess: 001f0001
Object: e2065ed8 Type: (826d2910) Port
ObjectHeader: e2065ec0
HandleCount: 1 PointerCount: 2

07f0: Object: 82645c28 GrantedAccess: 00100020
(Inherit)
Object: 82645c28 Type: (826d1e70) File
ObjectHeader: 82645c10
HandleCount: 1 PointerCount: 1
Directory Object: 00000000 Name: \fslx
{HarddiskVolume1}

07f4: Object: e198df60 GrantedAccess: 00000003
Object: e198df60 Type: (826d4110) Directory
ObjectHeader: e198df48
HandleCount: 29 PointerCount: 61
Directory Object: e1001b48 Name: KnownDlls

07f8: Object: 82420510 GrantedAccess: 001f0003
Object: 82420510 Type: (826aa6f0) Event
ObjectHeader: 824204f8
HandleCount: 1 PointerCount: 1

07fc: Object: e1001738 GrantedAccess: 00000003
Object: e1001738 Type: (826a9900) KeyedEvent
ObjectHeader: e1001720
HandleCount: 30 PointerCount: 31
Directory Object: e1003ae8 Name:
CritSecOutOfMemoryEvent

Did you confirm that
you aren’t attached in this call?
I don’t know what this means.

Thanks again.

Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

7

I’ve found out a little more on this since following
your suggestions.

If I attempt the open and close in DriverEntry, the
close simply fails with a STATUS_INVALID_HANDLE.
Still unexpected, but no blue screen.

If I attempt the open and close via an IOCTL, then the
blue screen happens.

I’m guessing that this is because of context
differences (Service Control Manager vs. my program
that sends the ioctl).

Here is the output:

SampleDriver.sys : DriverEntry
SampleDriver.sys : Open succeeded: 800007F0
\REGISTRY\MACHINE
SampleDriver.sys : ZwClose: 0
SampleDriver.sys : Open succeeded: 80000050
\REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Perflib\009
SampleDriver.sys : ZwClose: C0000008
SampleDriver.sys : Loaded successfully
SampleDriver.sys : DriverIoControl
SampleDriver.sys : IOCTL_SAMPLE received
SampleDriver.sys : Open succeeded: 800007EC
\REGISTRY\MACHINE
SampleDriver.sys : ZwClose: 0
SampleDriver.sys : Open succeeded: 80000050
\REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Perflib\009

*** Fatal System Error: 0x00000093

(0x00000050,0x00000001,0x00000000,0x00000000)

Here is the code:
#include <ntddk.h>
#include “…\Shared\ioctl.h”

LPCWSTR g_deviceName = L"\Device\SampleDriver";
LPCWSTR g_linkName = L"\DosDevices\SampleDriver";
HANDLE g_hRegKey;

NTSTATUS DriverEntry(IN PDRIVER_OBJECT DriverObject,
IN PUNICODE_STRING RegistryPath);
VOID DriverUnload(IN PDRIVER_OBJECT DriverObject);
NTSTATUS IrpDispatch_Create(IN PDEVICE_OBJECT
DeviceObject, IN PIRP Irp);
NTSTATUS IrpDispatch_Control(IN PDEVICE_OBJECT
DeviceObject, IN PIRP Irp);

#ifdef ALLOC_PRAGMA
#pragma alloc_text(INIT, DriverEntry)
#pragma alloc_text(PAGE, DriverUnload)
#pragma alloc_text(PAGE, IrpDispatch_Create)
#pragma alloc_text(PAGE, IrpDispatch_Control)
#endif

NTSTATUS myTestReg(LPCWSTR regPath)
{
NTSTATUS status;
OBJECT_ATTRIBUTES oa;
UNICODE_STRING us;

RtlInitUnicodeString(&us, regPath);
InitializeObjectAttributes(&oa, &us,
OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE, NULL, NULL);

status = ZwOpenKey(&g_hRegKey, KEY_ALL_ACCESS, &oa);
if (NT_SUCCESS(status))
{
KdPrint((“SampleDriver.sys : Open succeeded: %X
%ws\n”, g_hRegKey, regPath));

status = ZwClose(g_hRegKey);

KdPrint((“SampleDriver.sys : ZwClose: %X\n”,
status));
}
else
{
KdPrint((“SampleDriver.sys : Failed to open registry
key, Error = %X\n”, status));
}

return status;
}

NTSTATUS DriverEntry(IN PDRIVER_OBJECT DriverObject,
IN PUNICODE_STRING RegistryPath)
{
NTSTATUS status;
PDEVICE_OBJECT deviceObject;
UNICODE_STRING deviceName;
UNICODE_STRING linkName;

KdPrint((“\n\nSampleDriver.sys : DriverEntry\n”));

RtlInitUnicodeString(&deviceName, g_deviceName);
status = IoCreateDevice(DriverObject, sizeof(65533),
&deviceName, 0, 0, FALSE, &deviceObject);
if (!NT_SUCCESS(status))
{
return status;
}
deviceObject->Flags |= DO_DIRECT_IO;
deviceObject->Flags &= ~DO_DEVICE_INITIALIZING;

RtlInitUnicodeString(&linkName, g_linkName);
status = IoCreateSymbolicLink(&linkName,
&deviceName);
if (!NT_SUCCESS(status))
{
IoDeleteDevice (DriverObject->DeviceObject);
return status;
}

DriverObject->DriverUnload = DriverUnload;
DriverObject->MajorFunction[IRP_MJ_CREATE] =
IrpDispatch_Create;
DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] =
IrpDispatch_Control;

myTestReg(L"\REGISTRY\MACHINE");

myTestReg(L"\REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Perflib\009");

KdPrint((“SampleDriver.sys : Loaded
successfully\n”));

return STATUS_SUCCESS;
}

VOID DriverUnload(IN PDRIVER_OBJECT DriverObject)
{
UNICODE_STRING linkName;

RtlInitUnicodeString(&linkName, g_linkName);
IoDeleteSymbolicLink(&linkName);
IoDeleteDevice(DriverObject->DeviceObject);

KdPrint((“SampleDriver.sys : UnLoaded
successfully\n\n\n”));
}

NTSTATUS IrpDispatch_Create(IN PDEVICE_OBJECT
DeviceObject, IN PIRP Irp)
{
IoCompleteRequest(Irp, IO_NO_INCREMENT);
return STATUS_SUCCESS;
}

NTSTATUS IrpDispatch_Control(IN PDEVICE_OBJECT
DeviceObject, IN PIRP Irp)
{
PIO_STACK_LOCATION irpStack;

KdPrint((“SampleDriver.sys : DriverIoControl\n”));

// Mark the Irp as successful
Irp->IoStatus.Status = STATUS_SUCCESS;
Irp->IoStatus.Information = 0;

// Get the current place in the Irp stack, where our
information is located
irpStack = IoGetCurrentIrpStackLocation (Irp);

switch
(irpStack->Parameters.DeviceIoControl.IoControlCode)
{
case IOCTL_SAMPLE:
KdPrint((“SampleDriver.sys : IOCTL_SAMPLE
received\n”));

myTestReg(L"\REGISTRY\MACHINE");

myTestReg(L"\REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Perflib\009");

break;
}

IoCompleteRequest(Irp, IO_NO_INCREMENT);
return STATUS_SUCCESS;
}

— Tony Mason wrote:
> My suggestion would be to try building a totally
> separate driver - one
> with just a DriverEntry function. In that entry
> point, open and then
> close that registry key, and then return a failure
> code. I do this when
> I’m probing the OS level functionality generally.
>
> Also, try changing your handle from a local
> (automatic) variable to a
> global (or static) variable. Then, if this is some
> sort of memory
> overwrite condition you’ll be able to tell as well.

__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail</ntddk.h>

8

Just for posterity or in case anyone is interested…

We added a little code to the sfCreate function in the
sfilter sample that would open and close this reg key
when a particular file was opened. Sure enough, it
blows up.

Again, it is as simple as this:

RtlInitUnicodeString(&us,
L"\REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Perflib\009");

InitializeObjectAttributes(&oa, &us,
OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE, NULL, NULL);

status = ZwOpenKey(&handle, KEY_ALL_ACCESS, &oa);

if (NT_SUCCESS(status))
{
status = ZwClose(handle); // <== Boom
}

We are now in the process of opening a ticket with MS
on this. If some kind MS soul here could help
expedite, it would be much appreciated.

I would love for this to be something that I am doing
wrong, but I don’t see how it can be. Just looking
for a proper workaround at this point…

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com