Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

On-Access, Transparent, Per-File Data Encryption:

OSR's File Encryption Solution Framework (FESF) provides all the infrastructure you need to build a transparent file encryption product REALLY FAST.

Super flexible policy determination and customization, all done in user-mode. Extensive starter/sample code provided.

Proven, robust, flexible. In use in multiple commercial products.

Currently available on Windows. FESF for Linux will ship in 2018.

For more info: https://www.osr.com/fesf

Go Back   OSR Online Lists > ntfsd
Welcome, Guest
You must login to post to this list
  Message 1 of 4  
09 Jan 17 09:17
sachin shinde
xxxxxx@gmail.com
Join Date: 23 Oct 2015
Posts To This List: 14
Invalid HANDLE close, CRASH

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: fffff880`06692528 fffff800`03781307 : 00000000`00000093 00000000`000018c4 00000000`00000001 00000000`00000000 : nt!KeBugCheckEx fffff880`06692530 fffff800`034c6153 : fffffa80`020f4b60 fffff880`06692600 fffff880`06692770 00000000`00000000 : nt! ?? ::NNGAKEGL::`string'+0x34fdb fffff880`06692580 fffff800`034c26f0 : fffff880`0117366c 00000000`00000001 fffffa80`02ea0070 fffff880`06692770 : nt!KiSystemServiceCopyEnd+0x13 fffff880`06692718 fffff880`0117366c : 00000000`00000001 fffffa80`02ea0070 fffff880`06692770 00000000`000000a8 : nt!KiServiceLinkage fffff880`06692720 fffff800`03836ce5 : fffffa80`06144a30 00000000`00000004 00000000`00000000 ffffffff`8000187c : fileinfo!FIPfInterfaceClose+0x48 fffff880`06692750 fffff800`038c56e1 : fffff880`06692800 00000000`c000009a fffff8a0`07000000 00000000`00000004 : nt!PfpOpenHandleClose+0x55 fffff880`066927a0 fffff800`0392bc3c : 00000000`00000000 00000000`c0000017 00000000`c000009a fffff8a0`00000001 : nt!PfpPrefetchVolumesCleanup+0x71 fffff880`066927d0 fffff800`0392c7b7 : 00000000`00000000 fffff880`06692c60 fffff880`066929c8 fffff8a0`027bc060 : nt!PfpPrefetchRequestPerform+0x32c fffff880`06692920 fffff800`03938d8e : fffff880`066929c8 fffff880`06692a01 fffffa80`04666540 00000000`00000000 : nt!PfpPrefetchRequest+0x176 fffff880`06692990 fffff800`0393d4be : 00000000`00000000 00000000`0382f930 00000000`0000004f 00000000`06164001 : nt!PfSetSuperfetchInformation+0x1ad fffff880`06692a70 fffff800`034c6153 : fffffa80`020f4b60 00000000`00000000 00000000`00000001 00000000`00000001 : nt!NtSetSystemInformation+0xb91 fffff880`06692be0 00000000`770c15aa : 000007fe`f7bf89cc 00000000`0382f9e0 00000000`0382f988 00000000`0000289f : nt!KiSystemServiceCopyEnd+0x13 00000000`0382f908 000007fe`f7bf89cc : 00000000`0382f9e0 00000000`0382f988 00000000`0000289f 00000000`00000000 : ntdll!NtSetSystemInformation+0xa 00000000`0382f910 000007fe`f7bf8799 : 00000000`0382fbe0 00000000`06415c50 00000000`061b2510 00000000`00000000 : sysmain!PfListPrefetch+0xfa 00000000`0382f980 000007fe`f7bf8688 : 00000000`022c8c01 00000000`022c8f18 00000000`0382fbe0 00000000`06153960 : sysmain!PfDbDatabasePrefetchPerform+0xdb1 00000000`0382fb20 000007fe`f7bf9fc8 : 00000000`022c8c90 00000000`022c8f18 00000000`00000001 000007fe`00000000 : sysmain!PfDbDatabasePrefetchExWithInterface+0x1a8 00000000`0382fbc0 000007fe`f7bf7b92 : 00000000`022c8c58 00000000`022c8c58 00000000`00000000 00000000`00000564 : sysmain!PfRbPrefetchCore+0x10d 00000000`0382fc70 00000000`76e6f56d : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : sysmain!PfRbPrefetchWorker+0xdb 00000000`0382fca0 00000000`770a3281 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd 00000000`0382fcd0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 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
  Message 2 of 4  
09 Jan 17 09:45
Scott Noone
xxxxxx@osr.com
Join Date: 10 Jul 2002
Posts To This List: 920
List Moderator
Invalid HANDLE close, CRASH

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:102072@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: fffff880`06692528 fffff800`03781307 : 00000000`00000093 00000000`000018c4 00000000`00000001 00000000`00000000 : nt!KeBugCheckEx fffff880`06692530 fffff800`034c6153 : fffffa80`020f4b60 fffff880`06692600 fffff880`06692770 00000000`00000000 : nt! ?? ::NNGAKEGL::`string'+0x34fdb fffff880`06692580 fffff800`034c26f0 : fffff880`0117366c 00000000`00000001 fffffa80`02ea0070 fffff880`06692770 : nt!KiSystemServiceCopyEnd+0x13 fffff880`06692718 fffff880`0117366c : 00000000`00000001 fffffa80`02ea0070 fffff880`06692770 00000000`000000a8 : nt!KiServiceLinkage fffff880`06692720 fffff800`03836ce5 : fffffa80`06144a30 00000000`00000004 00000000`00000000 ffffffff`8000187c : fileinfo!FIPfInterfaceClose+0x48 fffff880`06692750 fffff800`038c56e1 : fffff880`06692800 00000000`c000009a fffff8a0`07000000 00000000`00000004 : nt!PfpOpenHandleClose+0x55 fffff880`066927a0 fffff800`0392bc3c : 00000000`00000000 00000000`c0000017 00000000`c000009a fffff8a0`00000001 : nt!PfpPrefetchVolumesCleanup+0x71 fffff880`066927d0 fffff800`0392c7b7 : 00000000`00000000 fffff880`06692c60 fffff880`066929c8 fffff8a0`027bc060 : nt!PfpPrefetchRequestPerform+0x32c fffff880`06692920 fffff800`03938d8e : fffff880`066929c8 fffff880`06692a01 fffffa80`04666540 00000000`00000000 : nt!PfpPrefetchRequest+0x176 fffff880`06692990 fffff800`0393d4be : 00000000`00000000 00000000`0382f930 00000000`0000004f 00000000`06164001 : nt!PfSetSuperfetchInformation+0x1ad fffff880`06692a70 fffff800`034c6153 : fffffa80`020f4b60 00000000`00000000 00000000`00000001 00000000`00000001 : nt!NtSetSystemInformation+0xb91 fffff880`06692be0 00000000`770c15aa : 000007fe`f7bf89cc 00000000`0382f9e0 00000000`0382f988 00000000`0000289f : nt!KiSystemServiceCopyEnd+0x13 00000000`0382f908 000007fe`f7bf89cc : 00000000`0382f9e0 00000000`0382f988 00000000`0000289f 00000000`00000000 : ntdll!NtSetSystemInformation+0xa 00000000`0382f910 000007fe`f7bf8799 : 00000000`0382fbe0 00000000`06415c50 00000000`061b2510 00000000`00000000 : sysmain!PfListPrefetch+0xfa 00000000`0382f980 000007fe`f7bf8688 : 00000000`022c8c01 00000000`022c8f18 00000000`0382fbe0 00000000`06153960 : sysmain!PfDbDatabasePrefetchPerform+0xdb1 00000000`0382fb20 000007fe`f7bf9fc8 : 00000000`022c8c90 00000000`022c8f18 00000000`00000001 000007fe`00000000 : sysmain!PfDbDatabasePrefetchExWithInterface+0x1a8 00000000`0382fbc0 000007fe`f7bf7b92 : 00000000`022c8c58 00000000`022c8c58 00000000`00000000 00000000`00000564 : sysmain!PfRbPrefetchCore+0x10d 00000000`0382fc70 00000000`76e6f56d : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : sysmain!PfRbPrefetchWorker+0xdb 00000000`0382fca0 00000000`770a3281 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd 00000000`0382fcd0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 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
  Message 3 of 4  
11 Jan 17 02:53
sachin shinde
xxxxxx@gmail.com
Join Date: 23 Oct 2015
Posts To This List: 14
Invalid HANDLE close, CRASH

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
  Message 4 of 4  
11 Jan 17 11:40
Scott Noone
xxxxxx@osr.com
Join Date: 10 Jul 2002
Posts To This List: 920
List Moderator
Invalid HANDLE close, CRASH

Try stripping the kernel handle bit: !htrace 1834 -scott OSR @OSRDrivers wrote in message news:102081@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
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntfsd list to be able to post.

All times are GMT -5. The time now is 02:39.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license