System service exception while EVT_WDF_FILE_CLOSE

I get a System service exception while handling event related to fileclose.
Not able to understand as why the exception is thrown ? Please help me.

VOID MYUSB_EvtDeviceFileClose( … )
{

pFileContext = GetFileContext(FileObject);
pDevExt = GetDeviceContext(pFileContext->pDevExt); <<?? Exception here

}

NTSTATUS UsbMYUSBDriverEvtDeviceAdd(IN WDFDRIVER Driver,
IN PWDFDEVICE_INIT DeviceInit)
{

WDF_FILEOBJECT_CONFIG_INIT(
&fileConfig,
MYUSB_EvtDeviceFileCreate,
MYUSB_EvtDeviceFileClose,
MYUSB_EvtDeviceFileCleanUp );
WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&fileAttributes, FILE_CONTEXT);
fileAttributes.SynchronizationScope = WdfSynchronizationScopeNone;

WdfDeviceInitSetFileObjectConfig(DeviceInit, &fileConfig, &fileAttributes);

WdfDeviceInitSetIoType(DeviceInit, WdfDeviceIoDirect);

}

Below is the log from the windbg.

DbgBreakPointWithStatus:
fffff803efdce300 cc int 3 0: kd\> bl 0 e fffff8009bdea000 0001 (0001) MYUSBDriver!DriverEntry
1 e fffff8009bde8000 0001 (0001) MYUSBDriver!MYUSB_EvtDeviceFileClose 2 e fffff8009bde8000 0001 (0001) MYUSBDriver!MYUSB_EvtDeviceFileClose
3 e fffff800`9bde8080 0001 (0001) MYUSBDriver!MYUSB_EvtDeviceFileCreate

0: kd> g
Breakpoint 3 hit
*** ERROR: Module load completed but symbols could not be loaded for Wdf01000.sys
MYUSBDriver!MYUSB_EvtDeviceFileCreate:
fffff8009bde8080 4c89442418 mov qword ptr [rsp+18h],r8 \*\*\* ERROR: Module load completed but symbols could not be loaded for USBlyzer.sys 2: kd\> p MYUSBDriver!MYUSB_EvtDeviceFileCreate+0x13: fffff8009bde8093 c7442424010000c0 mov dword ptr [rsp+24h],0C0000001h
2: kd> p
MYUSBDriver!MYUSB_EvtDeviceFileCreate+0x1b:
fffff8009bde809b 48c744243000000000 mov qword ptr [rsp+30h],0 2: kd\> p MYUSBDriver!MYUSB_EvtDeviceFileCreate+0x24: fffff8009bde80a4 e8578fffff call MYUSBDriver!KeGetCurrentIrql (fffff8009bde1000) 2: kd\> p MYUSBDriver!MYUSB_EvtDeviceFileCreate+0x5e: fffff8009bde80de 488b4c2450 mov rcx,qword ptr [rsp+50h]
2: kd> p
MYUSBDriver!MYUSB_EvtDeviceFileCreate+0x6d:
fffff8009bde80ed 488b4c2460 mov rcx,qword ptr [rsp+60h] 2: kd\> p MYUSBDriver!MYUSB_EvtDeviceFileCreate+0x7c: fffff8009bde80fc 488b442438 mov rax,qword ptr [rsp+38h]
2: kd> p
MYUSBDriver!MYUSB_EvtDeviceFileCreate+0x89:
fffff8009bde8109 c744242400000000 mov dword ptr [rsp+24h],0 2: kd\> g Breakpoint 1 hit Breakpoint 2 hit MYUSBDriver!MYUSB_EvtDeviceFileClose: fffff8009bde8000 48894c2408 mov qword ptr [rsp+8],rcx
2: kd> p
MYUSBDriver!MYUSB_EvtDeviceFileClose+0x9:
fffff8009bde8009 48c744243000000000 mov qword ptr [rsp+30h],0 2: kd\> p MYUSBDriver!MYUSB_EvtDeviceFileClose+0x12: fffff8009bde8012 e8e98fffff call MYUSBDriver!KeGetCurrentIrql (fffff8009bde1000) 2: kd\> p MYUSBDriver!MYUSB_EvtDeviceFileClose+0x4c: fffff8009bde804c 488b4c2450 mov rcx,qword ptr [rsp+50h]
2: kd> p
MYUSBDriver!MYUSB_EvtDeviceFileClose+0x5b:
fffff800`9bde805b 488b442428 mov rax,qword ptr [rsp+28h]
2: kd> p
KDTARGET: Refreshing KD connection

*** Fatal System Error: 0x0000003b
(0x00000000C0000005,0xFFFFF800995A1116,0xFFFFD0009069BC50,0x0000000000000000)

WARNING: This break is not a step/trace completion.
The last command has been cleared to prevent
accidental continuation of this unrelated event.
Check the event, location and thread before resuming.
Break instruction exception - code 80000003 (first chance)

A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

nt!DbgBreakPointWithStatus:
fffff803`efdce300 cc int 3
2: kd> !analyze -v
Connected to Windows 10 10240 x64 target at (Wed Aug 10 16:50:05.816 2016 (UTC + 5:30)), ptr64 TRUE
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrnlmp.exe -
Loading Kernel Symbols



Loading User Symbols

*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll -

************* Symbol Loading Error Summary **************
Module name Error
ntkrnlmp The system cannot find the file specified
ntdll No data is available : srv*c:\mysymbolstorelocal*https://msdl.microsoft.com/download/symbols
PDB not found : c:\es582-code\MYUSBdriver\x64\debug\symbols\dll\ntdll.pdb

You can troubleshoot most symbol related issues by turning on symbol loading diagnostics (!sym noisy) and repeating the command that caused symbols to be loaded.
You should also verify that your symbol search path (.sympath) is correct.
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff800995a1116, Address of the instruction which caused the bugcheck
Arg3: ffffd0009069bc50, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.

Debugging Details:

*** ERROR: Module load completed but symbols could not be loaded for Wdf01000.sys
*** ERROR: Module load completed but symbols could not be loaded for USBlyzer.sys
***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*** ERROR: Module load completed but symbols could not be loaded for mssmbios.sys
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn’t have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing “.symopt- 100”. Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn’t have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing “.symopt- 100”. Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn’t have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing “.symopt- 100”. Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn’t have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing “.symopt- 100”. Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn’t have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing “.symopt- 100”. Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPCR ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn’t have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing “.symopt- 100”. Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KTHREAD ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn’t have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing “.symopt- 100”. Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_MMPTE ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn’t have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing “.symopt- 100”. Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_MMPTE ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn’t have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing “.symopt- 100”. Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_MMPTE ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn’t have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing “.symopt- 100”. Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn’t have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing “.symopt- 100”. Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*** ERROR: Symbol file could not be found. Defaulted to export symbols for KERNELBASE.dll -

************* Symbol Loading Error Summary **************
Module name Error
KERNELBASE No data is available : srv*c:\mysymbolstorelocal*https://msdl.microsoft.com/download/symbols
PDB not found : c:\es582-code\MYUSBdriver\x64\debug\symbols\dll\KERNELBASE.pdb

The following location did not respond and were excluded during symbol loading:
c:\es582-code\MYUSBdrier\x64\debug

You can troubleshoot most symbol related issues by turning on symbol loading diagnostics (!sym noisy) and repeating the command that caused symbols to be loaded.
You should also verify that your symbol search path (.sympath) is correct.

ADDITIONAL_DEBUG_TEXT:
You can run ‘.symfix; .reload’ to try to fix the symbol path and load symbols.

WRONG_SYMBOLS_TIMESTAMP: 559f3c1a

WRONG_SYMBOLS_SIZE: 852000

FAULTING_MODULE: fffff803efc7c000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 559f3c1a

BUGCHECK_P1: c0000005

BUGCHECK_P2: fffff800995a1116

BUGCHECK_P3: ffffd0009069bc50

BUGCHECK_P4: 0

EXCEPTION_CODE: (NTSTATUS) 0x559f3c1a -

FAULTING_IP:
Wdf01000+1116
fffff800995a1116 4c8b5010 mov r10,qword ptr [rax+10h]<br><br>CONTEXT: ffffd0009069bc50 -- (.cxr 0xffffd0009069bc50)<br>rax=00001ffe92aafd08 rbx=ffffe0016d070f60 rcx=0000000000000000<br>rdx=ffffe0016d5502f0 rsi=ffffe0016cada790 rdi=ffffe0016ac9f4e0<br>rip=fffff800995a1116 rsp=ffffd0009069c670 rbp=ffffd0009069c7e9<br> r8=fffff8009bde5028 r9=fffff8009965a238 r10=ffffe0016cb01cc0<br>r11=ffffd0009069c880 r12=ffffe0016cada810 r13=0000000000000000<br>r14=00001ffe926f1d38 r15=0000000000000000<br>iopl=0 nv up ei pl zr na po nc<br>cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010246<br>Wdf01000+0x1116:<br>fffff800995a1116 4c8b5010 mov r10,qword ptr [rax+10h] ds:002b:00001ffe92aafd18=????????????????<br>Resetting default scope<br><br>CPU_COUNT: 4<br><br>CPU_MHZ: cdc<br><br>CPU_VENDOR: GenuineIntel<br><br>CPU_FAMILY: 6<br><br>CPU_MODEL: 3c<br><br>CPU_STEPPING: 3<br><br>CURRENT_IRQL: 0<br><br>ANALYSIS_VERSION: 10.0.10240.9 amd64fre<br><br>LAST_CONTROL_TRANSFER: from fffff8009bde1596 to fffff800995a1116<br><br>STACK_TEXT: <br>ffffd0009069c670 fffff8009bde1596 : ffffffffffffffd2 fffff8009bde17a0 0000000000000010 0000000000000286 : Wdf01000+0x1116<br>ffffd0009069c6c0 fffff8009bde17aa : ffffe0016d5502f0 fffff8009bde5028 0000000000000010 0000000000000284 : MYUSBDriver!WdfObjectGetTypedContextWorker+0x36 [c:\program files (x86)\windows kits\10\include\wdf\kmdf\1.15\wdfobject.h @ 564]<br>ffffd0009069c6f0 fffff8009bde8068 : ffffe0016d5502f0 ffffd0009069c7e9 0000000000000000 fffff8009bde8005 : MYUSBDriver!GetDeviceContext+0x1a [c:\es582-code\MYUSBdriver\MYUSBdriver\MYUSB_private.h @ 291]<br>ffffd0009069c720 fffff800995e564f : 00001ffe926f1d38 0000000000000000 ffffe0016ac9f4e0 ffffe0016acf2d38 : MYUSBDriver!MYUSB_EvtDeviceFileClose+0x68 [c:\es582-code\MYUSBdriver\MYUSBdriver\control_io.c @ 253]<br>ffffd0009069c770 fffff800995a197e : 0000000000000009 fffff803efc9db72 ffffe0016d31e000 fffff8009b283235 : Wdf01000+0x4564f<br>ffffd0009069c850 fffff8009b283004 : 0000000000000012 ffffe0016d3df980 ffffe0016d3df980 ffffe0016ac9f4e0 : Wdf01000+0x197e<br>ffffd0009069c8a0 fffff803f0114bdf : ffffe0016ad1f920 0000000000000000 0000000000000000 0000000000000000 : USBlyzer+0x3004<br>ffffd0009069c8d0 fffff803f009e802 : 0000000000000001 0000000000000000 ffffd0009069ca49 ffff84f000000002 : nt!NtQuerySecurityObject+0xa9f<br>ffffd0009069c960 fffff803f009d05d : ffff84f07b12af56 0000000000000000 000000d4cbe7f660 0000000000000000 : nt!NtWaitForSingleObject+0x3e2<br>ffffd0009069caa0 fffff803efdd3263 : ffffe0016d7a8840 000000d4cbfb3a80 ffffe0016d7a8840 ffffd0009069cb80 : nt!NtClose+0xcd<br>ffffd0009069cb00 00007ffc9df1363a : 00007ffc9b3922a1 0000000000000000 0000000000000000 000078ca493c0126 : nt!setjmpex+0x37d3<br>000000d4cbe7fa78 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!ZwClose+0xa<br><br>FOLLOWUP_IP: <br>MYUSBDriver!WdfObjectGetTypedContextWorker+36 [c:\program files (x86)\windows kits\10\include\wdf\kmdf\1.15\wdfobject.h @ 564]<br>fffff8009bde1596 4883c428 add rsp,28h

FAULTING_SOURCE_LINE: c:\program files (x86)\windows kits\10\include\wdf\kmdf\1.15\wdfobject.h

FAULTING_SOURCE_FILE: c:\program files (x86)\windows kits\10\include\wdf\kmdf\1.15\wdfobject.h

FAULTING_SOURCE_LINE_NUMBER: 564

FAULTING_SOURCE_CODE:
560: PCWDF_OBJECT_CONTEXT_TYPE_INFO TypeInfo
561: )
562: {
563: return ((PFN_WDFOBJECTGETTYPEDCONTEXTWORKER) WdfFunctions[WdfObjectGetTypedContextWorkerTableIndex])(WdfDriverGlobals, Handle, TypeInfo);
> 564: }
565:
566: //
567: // WDF Function: WdfObjectAllocateContext
568: //
569: typedef

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt_wrong_symbols!559F3C1A852000

FOLLOWUP_NAME: MachineOwner

STACK_COMMAND: .cxr 0xffffd0009069bc50 ; kb

BUGCHECK_STR: 559F3C1A

FAILURE_EXCEPTION_CODE: 559F3C1A

EXCEPTION_STR: WRONG_SYMBOLS

IMAGE_NAME: ntoskrnl.wrong.symbols.exe

MODULE_NAME: nt_wrong_symbols

BUCKET_ID: WRONG_SYMBOLS_X64_10240.16384.amd64fre.th1.150709-1700_TIMESTAMP_150710-032930

DEFAULT_BUCKET_ID: WRONG_SYMBOLS_X64_10240.16384.amd64fre.th1.150709-1700_TIMESTAMP_150710-032930

PRIMARY_PROBLEM_CLASS: WRONG_SYMBOLS

FAILURE_BUCKET_ID: WRONG_SYMBOLS_X64_10240.16384.amd64fre.th1.150709-1700_TIMESTAMP_150710-032930_559F3C1A_nt_wrong_symbols!559F3C1A852000

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:wrong_symbols_x64_10240.16384.amd64fre.th1.150709-1700_timestamp_150710-032930_559f3c1a_nt_wrong_symbols!559f3c1a852000

FAILURE_ID_HASH: {eb71b7c5-5d3e-8b28-668b-123d807c7ae7}

Followup: MachineOwner
---------

Ok, I will tell you the reason - accessing an invalid user mode virtual address 00001ffe92aafd18 by this command

mov r10,qword ptr [rax+10h]

I will not delve into describing PTE and PTE valid bit, user vs kernel addresses, page fault processing. Because you need to start with fixing WinDBG symbols path.

Is your symbol path supposed to be c:\es582-code\myusbdrier\ ? Note the missing V?

Rule #1 in debugging (taught to me by OSR’s SNoone): Read the WinDbg output.

Having said that, it looks like accessing your device context failed.

Fix your symbols, step through your code, do some debugging, and post another question if you can’t discover the problem on your own. But, please… At least single-step through your code path first and tell us what’s happening.

Peter
OSR
@OSRDrivers

> pDevExt = GetDeviceContext(pFileContext->pDevExt); <<?? Exception here

The GetDeviceContext parameter is a WDFDEVICE handle, no ?

If so, use WdfFileObjectGetDevice to obtain this handle. The MSDN documentation is very pertinent. It is illustrated with a routine of type … EVT_WDF_FILE_CLOSE.

Hope this helps.

Thanks a lot for the hint. I overlooked this API from WDF. Now the issue is solved.

But I need a clarification on the following design.

My driver can be accessed by maximum of 2 client applications in parallel. Both applications can read or write data to device at same time. The data from the USB has to be routed to both clients until these process are alive. current client count is saved in device context.

Inside the driver, I plan to have two ring buffers to buffer the data. Inside the continuousreader callback function, based on the current client count, data is copied to both the ring buffers. If no client are alive, continuousreader ignores the data from device.

File create/close/cleanup is used to track the active user space clients.
Is this design ok or WDF provides any readymade APIs? I AM CONFUSED on choosing between File close and FileCleanup?

Your design is fine. You can store the ring buffer in the context of the wdffileobject as a better way of associating the buffer with the client. File cleanup happens when the application closes the handle, file close happens when the last Ob reference is dropped and the count goes to zero. If all the app for is open and then close the handle, cleanup and close are called consecutively.

Sent from my Windows 10 phone

From: srinivaskumar.r@in.bosch.commailto:srinivaskumar.r
Sent: Wednesday, August 17, 2016 7:09 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] System service exception while EVT_WDF_FILE_CLOSE

Thanks a lot for the hint. I overlooked this API from WDF. Now the issue is solved.

But I need a clarification on the following design.

My driver can be accessed by maximum of 2 client applications in parallel. Both applications can read or write data to device at same time. The data from the USB has to be routed to both clients until these process are alive. current client count is saved in device context.

Inside the driver, I plan to have two ring buffers to buffer the data. Inside the continuousreader callback function, based on the current client count, data is copied to both the ring buffers. If no client are alive, continuousreader ignores the data from device.

File create/close/cleanup is used to track the active user space clients.
Is this design ok or WDF provides any readymade APIs? I AM CONFUSED on choosing between File close and FileCleanup?


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></mailto:xxxxx></mailto:srinivaskumar.r>

thanks for suggestion.

What is the "last Ob reference "?

Other components and apis can bump up the object count independent of the handle count

Sent from my Windows 10 phone

From: srinivaskumar.r@in.bosch.commailto:srinivaskumar.r
Sent: Wednesday, August 17, 2016 7:49 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] System service exception while EVT_WDF_FILE_CLOSE

thanks for suggestion.

What is the "last Ob reference "?


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></mailto:xxxxx></mailto:srinivaskumar.r>

Cleanup and Close are very frequently confused.

As soon as the user calls CloseHandle for a File Object, your File Object related CLEANUP callback is called. This is called in the context of the requesting process and at IRQL PASSIVE_LEVEL.

When the reference count on the File Object goes to zero, your File Object related CLOSE callback is called. This is called in an arbitrary process and thread context.

Consider what happens when a user opens your device, and sends 100 ASYNCHRONOUS reads to your device, and then (before those reads all complete) calls CloseHandle on the file handle:

  • Your CLEANUP callback is called as soon as the user calls CloseHandle.

  • Only when the I/Os are completed (from cancellation or otherwise), will your CLOSE callback be called.

So… except for rare instances where you have process-specific state that needs torn down, you almost always want to handle CLOSE not CLEANUP.

About 95% of the time when I see a CLEANUP routine in a 3rd party driver, it’s indicative of an error – usually a serious misunderstanding by the driver’s author. Not always, but this is ALMOST always the case.

Hope that helps,

Peter
OSR
@OSRDrivers

Furthermore, IRP_MJ_CLEANUP is sent when the last handle system-wide is closed. This could occur in a completely different process, one which never called CreateFile on your device to begin with (consider handle inheritance, or handle duplication).

It?s relatively unusual to do much work in IRP_MJ_CLEANUP. If the work done in IRP_MJ_CLEANUP is specific to a given process, it is almost certainly wrong (& often a security bug if the driver assumes that there is a correspondence to processes that send IRP_MJ_CREATE and processes that send IRP_MJ_CLEANUP). Legitimate use cases for IRP_MJ_CLEANUP tend to be fairly narrow and typically are of the variety where you need to release a reference to some resource on last handle close to avoid creating circular references of some sort.

  • S (Msft)

From: xxxxx@osr.commailto:xxxxx
Sent: Wednesday, August 17, 2016 1:39 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] System service exception while EVT_WDF_FILE_CLOSE

Cleanup and Close are very frequently confused.

As soon as the user calls CloseHandle for a File Object, your File Object related CLEANUP callback is called. This is called in the context of the requesting process and at IRQL PASSIVE_LEVEL.

When the reference count on the File Object goes to zero, your File Object related CLOSE callback is called. This is called in an arbitrary process and thread context.

Consider what happens when a user opens your device, and sends 100 ASYNCHRONOUS reads to your device, and then (before those reads all complete) calls CloseHandle on the file handle:

- Your CLEANUP callback is called as soon as the user calls CloseHandle.

- Only when the I/Os are completed (from cancellation or otherwise), will your CLOSE callback be called.

So… except for rare instances where you have process-specific state that needs torn down, you almost always want to handle CLOSE not CLEANUP.

About 95% of the time when I see a CLEANUP routine in a 3rd party driver, it’s indicative of an error – usually a serious misunderstanding by the driver’s author. Not always, but this is ALMOST always the case.

Hope that helps,

Peter
OSR
@OSRDrivers


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></mailto:xxxxx></mailto:xxxxx>

Wisdom! Let us be attentive!

And let me tell you… this is a PITA to handle properly. You see this bug all the time in “I mapped a shared buffer back to user-mode” scenarios.

I, personally, have tended to dismiss this (the whole handle inheritance/duplication problem) as a relatively narrow problem in a pretty rare use case. And I still think it is.

HOWEVER… in the past couple of years I’ve seen *several* badly implemented “shared buffer” schemes, and as part of updating these drivers (to make them work on newer Windows versions) I’ve had the pleasure of closing these loopholes in the interest of due diligence and best practice and whatever.

This is but one reason that I shudder every time I see somebody post “you can share a buffer between your driver and your app” outside of the “send a Direct I/O and keep it in progress” design pattern.

Peter
OSR
@OSRDrivers