Invalid HANDLE close, CRASH

sachin_shinde · January 9, 2017, 9:17am

Query regarding BSOD?
Hi,

I have query regarding system crash observed with bugcheck “INVALID_KERNEL_HANDLE (93)”
I suspect this crash is observed due to invalid handle close. Checked loaded modules, my driver is exited.

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

This is the stack for crash,

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x93

PROCESS_NAME: svchost.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80003781307 to fffff800034c6f00

STACK_TEXT:
fffff88006692528 fffff80003781307 : 0000000000000093 00000000000018c4 0000000000000001 0000000000000000 : nt!KeBugCheckEx
fffff88006692530 fffff800034c6153 : fffffa80020f4b60 fffff88006692600 fffff88006692770 0000000000000000 : nt! ?? ::NNGAKEGL::string'+0x34fdb fffff88006692580 fffff800034c26f0 : fffff8800117366c 0000000000000001 fffffa8002ea0070 fffff88006692770 : nt!KiSystemServiceCopyEnd+0x13 fffff88006692718 fffff8800117366c : 0000000000000001 fffffa8002ea0070 fffff88006692770 00000000000000a8 : nt!KiServiceLinkage fffff88006692720 fffff80003836ce5 : fffffa8006144a30 0000000000000004 0000000000000000 ffffffff8000187c : fileinfo!FIPfInterfaceClose+0x48 fffff88006692750 fffff800038c56e1 : fffff88006692800 00000000c000009a fffff8a007000000 0000000000000004 : nt!PfpOpenHandleClose+0x55 fffff880066927a0 fffff8000392bc3c : 0000000000000000 00000000c0000017 00000000c000009a fffff8a000000001 : nt!PfpPrefetchVolumesCleanup+0x71 fffff880066927d0 fffff8000392c7b7 : 0000000000000000 fffff88006692c60 fffff880066929c8 fffff8a0027bc060 : nt!PfpPrefetchRequestPerform+0x32c fffff88006692920 fffff80003938d8e : fffff880066929c8 fffff88006692a01 fffffa8004666540 0000000000000000 : nt!PfpPrefetchRequest+0x176 fffff88006692990 fffff8000393d4be : 0000000000000000 000000000382f930 000000000000004f 0000000006164001 : nt!PfSetSuperfetchInformation+0x1ad fffff88006692a70 fffff800034c6153 : fffffa80020f4b60 0000000000000000 0000000000000001 0000000000000001 : nt!NtSetSystemInformation+0xb91 fffff88006692be0 00000000770c15aa : 000007fef7bf89cc 000000000382f9e0 000000000382f988 000000000000289f : nt!KiSystemServiceCopyEnd+0x13 000000000382f908 000007fef7bf89cc : 000000000382f9e0 000000000382f988 000000000000289f 0000000000000000 : ntdll!NtSetSystemInformation+0xa 000000000382f910 000007fef7bf8799 : 000000000382fbe0 0000000006415c50 00000000061b2510 0000000000000000 : sysmain!PfListPrefetch+0xfa 000000000382f980 000007fef7bf8688 : 00000000022c8c01 00000000022c8f18 000000000382fbe0 0000000006153960 : sysmain!PfDbDatabasePrefetchPerform+0xdb1 000000000382fb20 000007fef7bf9fc8 : 00000000022c8c90 00000000022c8f18 0000000000000001 000007fe00000000 : sysmain!PfDbDatabasePrefetchExWithInterface+0x1a8 000000000382fbc0 000007fef7bf7b92 : 00000000022c8c58 00000000022c8c58 0000000000000000 0000000000000564 : sysmain!PfRbPrefetchCore+0x10d 000000000382fc70 0000000076e6f56d : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : sysmain!PfRbPrefetchWorker+0xdb 000000000382fca0 00000000770a3281 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : kernel32!BaseThreadInitThunk+0xd 000000000382fcd0 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d

I think handle “00000000000018c4” might be closed by my driver that has not been opened/owned by my driver.
Same bugchek has been observed on different systems for NtClose.

Is there any way to check narrow down illegal handle close by my driver before unload?

Thanks,
Sachin

Scott_Noone_OSR · January 9, 2017, 9:45am

Handle tracing is enabled for kernel handles when Verifier is enabled. So,
first thing to do I enable Verifier on your driver and then use !htrace when
the system crashes. This might give you a call stack that shows the handle
being closed the first time.

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntfsd…

Query regarding BSOD?
Hi,

I have query regarding system crash observed with bugcheck
“INVALID_KERNEL_HANDLE (93)”
I suspect this crash is observed due to invalid handle close. Checked loaded
modules, my driver is exited.

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

This is the stack for crash,

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x93

PROCESS_NAME: svchost.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80003781307 to fffff800034c6f00

STACK_TEXT:
fffff88006692528 fffff80003781307 : 0000000000000093 00000000000018c4
0000000000000001 0000000000000000 : nt!KeBugCheckEx
fffff88006692530 fffff800034c6153 : fffffa80020f4b60 fffff88006692600
fffff88006692770 0000000000000000 : nt! ?? ::NNGAKEGL::string'+0x34fdb fffff88006692580 fffff800034c26f0 : fffff8800117366c 0000000000000001 fffffa8002ea0070 fffff88006692770 : nt!KiSystemServiceCopyEnd+0x13 fffff88006692718 fffff8800117366c : 0000000000000001 fffffa8002ea0070 fffff88006692770 00000000000000a8 : nt!KiServiceLinkage fffff88006692720 fffff80003836ce5 : fffffa8006144a30 0000000000000004 0000000000000000 ffffffff8000187c : fileinfo!FIPfInterfaceClose+0x48 fffff88006692750 fffff800038c56e1 : fffff88006692800 00000000c000009a fffff8a007000000 0000000000000004 : nt!PfpOpenHandleClose+0x55 fffff880066927a0 fffff8000392bc3c : 0000000000000000 00000000c0000017 00000000c000009a fffff8a000000001 : nt!PfpPrefetchVolumesCleanup+0x71 fffff880066927d0 fffff8000392c7b7 : 0000000000000000 fffff88006692c60 fffff880066929c8 fffff8a0027bc060 : nt!PfpPrefetchRequestPerform+0x32c fffff88006692920 fffff80003938d8e : fffff880066929c8 fffff88006692a01 fffffa8004666540 0000000000000000 : nt!PfpPrefetchRequest+0x176 fffff88006692990 fffff8000393d4be : 0000000000000000 000000000382f930 000000000000004f 0000000006164001 : nt!PfSetSuperfetchInformation+0x1ad fffff88006692a70 fffff800034c6153 : fffffa80020f4b60 0000000000000000 0000000000000001 0000000000000001 : nt!NtSetSystemInformation+0xb91 fffff88006692be0 00000000770c15aa : 000007fef7bf89cc 000000000382f9e0 000000000382f988 000000000000289f : nt!KiSystemServiceCopyEnd+0x13 000000000382f908 000007fef7bf89cc : 000000000382f9e0 000000000382f988 000000000000289f 0000000000000000 : ntdll!NtSetSystemInformation+0xa 000000000382f910 000007fef7bf8799 : 000000000382fbe0 0000000006415c50 00000000061b2510 0000000000000000 : sysmain!PfListPrefetch+0xfa 000000000382f980 000007fef7bf8688 : 00000000022c8c01 00000000022c8f18 000000000382fbe0 0000000006153960 : sysmain!PfDbDatabasePrefetchPerform+0xdb1 000000000382fb20 000007fef7bf9fc8 : 00000000022c8c90 00000000022c8f18 0000000000000001 000007fe00000000 : sysmain!PfDbDatabasePrefetchExWithInterface+0x1a8 000000000382fbc0 000007fef7bf7b92 : 00000000022c8c58 00000000022c8c58 0000000000000000 0000000000000564 : sysmain!PfRbPrefetchCore+0x10d 000000000382fc70 0000000076e6f56d : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : sysmain!PfRbPrefetchWorker+0xdb 000000000382fca0 00000000770a3281 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : kernel32!BaseThreadInitThunk+0xd 000000000382fcd0 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d

I think handle “00000000000018c4” might be closed by my driver that has not
been opened/owned by my driver.
Same bugchek has been observed on different systems for NtClose.

Is there any way to check narrow down illegal handle close by my driver
before unload?

Thanks,
Sachin

sachin_shinde · January 11, 2017, 2:53am

Thanks Scott.

checked with enabled verifier

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

INVALID_KERNEL_HANDLE (93)
This message occurs if kernel code attempts to close or reference a handle
that is not a valid handle. Only invalid or protected handles passed to NtClose
will cause this bugcheck, unless bad handle detection is enabled.
Arguments:
Arg1: 00001834, The handle that NtClose was called with
Arg2: 00000000, A protected handle was closed.
Arg3: 00000000
Arg4: 00000000, The error occurred closing an invalid kernel handle.

Debugging Details:

DUMP_CLASS: 1

DUMP_QUALIFIER: 402

BUILD_VERSION_STRING: 6001.18000.x86fre.longhorn_rtm.080118-1840

kd> kP

ChildEBP RetAddr

00 8072aa34 82df0e2c nt!KeBugCheckEx+0x1e
01 8072aa8c 82df0bbd nt!ObpCloseHandleTableEntry+0x1b7
02 8072aabc 82df1440 nt!ObpCloseHandle+0x73
03 8072aad0 82c579aa nt!NtClose+0x20
04 8072aad0 82c553a9 nt!KiFastCallEntry+0x12a
05 8072ab4c a80064b5 nt!ZwClose+0x11
06 8072ab58 a8004bbd myflt!CloseCommunicationPort(
struct _FLT_PORT * pServerPort = 0x80001834)+0x2b
07 8072ab6c 84f948f1 myflt!DrvUnload(
unsigned long Flags = 0x48a35fe)+0x1f
08 8072ad08 84f94b19 fltmgr!FltpDoUnloadFilter+0xf3
09 8072ad1c 84f9cc64 fltmgr!FltpUnloadFilterWorker+0x11
0a 8072ad44 82c5b6be fltmgr!FltpSyncOpWorker+0x2c
0b 8072ad7c 82da86ad nt!ExpWorkerThread+0xfd
0c 8072adc0 82c8f686 nt!PspSystemThreadStartup+0x9d
0d 00000000 00000000 nt!KiThreadStartup+0x16
kd> !handle 0x80001834

PROCESS 848a8a90 SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000
DirBase: 00122000 ObjectTable: 864000b0 HandleCount: 1605.
Image: System

Kernel handle table at 864000b0 with 1605 entries in use

80001834: Object: 88cde468 GrantedAccess: 001f0003 (Locked) (Protected) Entry: 9a2e1068
Object: 88cde468 Type: (848d2b90) Event
ObjectHeader: 88cde450 (old version)
HandleCount: 1 PointerCount: 2

kd> !htrace 0x80001834
Process 0x848a8a90
ObjectTable 0x864000b0

Parsed 0x1000 stack traces.
Dumped 0x0 stack traces.

Checked Handle 0x80001834 it shows locked/protected, why this handle being turned to protected/Locked.
One more query regarding stack “myflt!CloseCommunicationPort” missing call to FltCloseCommunicationPort();

I was bit doubtful regarding my driver might closing same port twice, so performed test to close port twice checked if crash occurs or converts handle to protected handle after close but handle was not protected.

Any pointers will be really helpful.

Thanks,
Sachin

Scott_Noone_OSR · January 11, 2017, 11:40am

Try stripping the kernel handle bit:

!htrace 1834

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntfsd…

Thanks Scott.

checked with enabled verifier

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

INVALID_KERNEL_HANDLE (93)
This message occurs if kernel code attempts to close or reference a handle
that is not a valid handle. Only invalid or protected handles passed to
NtClose
will cause this bugcheck, unless bad handle detection is enabled.
Arguments:
Arg1: 00001834, The handle that NtClose was called with
Arg2: 00000000, A protected handle was closed.
Arg3: 00000000
Arg4: 00000000, The error occurred closing an invalid kernel handle.

Debugging Details:

DUMP_CLASS: 1

DUMP_QUALIFIER: 402

BUILD_VERSION_STRING: 6001.18000.x86fre.longhorn_rtm.080118-1840

kd> kP

ChildEBP RetAddr

00 8072aa34 82df0e2c nt!KeBugCheckEx+0x1e
01 8072aa8c 82df0bbd nt!ObpCloseHandleTableEntry+0x1b7
02 8072aabc 82df1440 nt!ObpCloseHandle+0x73
03 8072aad0 82c579aa nt!NtClose+0x20
04 8072aad0 82c553a9 nt!KiFastCallEntry+0x12a
05 8072ab4c a80064b5 nt!ZwClose+0x11
06 8072ab58 a8004bbd myflt!CloseCommunicationPort(
struct _FLT_PORT * pServerPort = 0x80001834)+0x2b
07 8072ab6c 84f948f1 myflt!DrvUnload(
unsigned long Flags = 0x48a35fe)+0x1f
08 8072ad08 84f94b19 fltmgr!FltpDoUnloadFilter+0xf3
09 8072ad1c 84f9cc64 fltmgr!FltpUnloadFilterWorker+0x11
0a 8072ad44 82c5b6be fltmgr!FltpSyncOpWorker+0x2c
0b 8072ad7c 82da86ad nt!ExpWorkerThread+0xfd
0c 8072adc0 82c8f686 nt!PspSystemThreadStartup+0x9d
0d 00000000 00000000 nt!KiThreadStartup+0x16
kd> !handle 0x80001834

PROCESS 848a8a90 SessionId: none Cid: 0004 Peb: 00000000 ParentCid:
0000
DirBase: 00122000 ObjectTable: 864000b0 HandleCount: 1605.
Image: System

Kernel handle table at 864000b0 with 1605 entries in use

80001834: Object: 88cde468 GrantedAccess: 001f0003 (Locked) (Protected)
Entry: 9a2e1068
Object: 88cde468 Type: (848d2b90) Event
ObjectHeader: 88cde450 (old version)
HandleCount: 1 PointerCount: 2

kd> !htrace 0x80001834
Process 0x848a8a90
ObjectTable 0x864000b0

Parsed 0x1000 stack traces.
Dumped 0x0 stack traces.

Checked Handle 0x80001834 it shows locked/protected, why this handle being
turned to protected/Locked.
One more query regarding stack “myflt!CloseCommunicationPort” missing call
to FltCloseCommunicationPort();

I was bit doubtful regarding my driver might closing same port twice, so
performed test to close port twice checked if crash occurs or converts
handle to protected handle after close but handle was not protected.

Any pointers will be really helpful.

Thanks,
Sachin