Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Sept/Oct 2019 Issue of The NT Insider available


Download PDF here: http://insider.osr.com/2019/ntinsider_2019_01.pdf

It’s a particularly BIG issue, too: 40 pages of technical goodness, ranging from WDF to Minifilters. Check it out.
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

System service exception while EVT_WDF_FILE_CLOSE

srini_k_rsrini_k_r Member Posts: 18
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:
fffff803`efdce300 cc int 3
0: kd> bl
0 e fffff800`9bdea000 0001 (0001) MYUSBDriver!DriverEntry
1 e fffff800`9bde8000 0001 (0001) MYUSBDriver!MYUSB_EvtDeviceFileClose
2 e fffff800`9bde8000 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:
fffff800`9bde8080 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:
fffff800`9bde8093 c7442424010000c0 mov dword ptr [rsp+24h],0C0000001h
2: kd> p
MYUSBDriver!MYUSB_EvtDeviceFileCreate+0x1b:
fffff800`9bde809b 48c744243000000000 mov qword ptr [rsp+30h],0
2: kd> p
MYUSBDriver!MYUSB_EvtDeviceFileCreate+0x24:
fffff800`9bde80a4 e8578fffff call MYUSBDriver!KeGetCurrentIrql (fffff800`9bde1000)
2: kd> p
MYUSBDriver!MYUSB_EvtDeviceFileCreate+0x5e:
fffff800`9bde80de 488b4c2450 mov rcx,qword ptr [rsp+50h]
2: kd> p
MYUSBDriver!MYUSB_EvtDeviceFileCreate+0x6d:
fffff800`9bde80ed 488b4c2460 mov rcx,qword ptr [rsp+60h]
2: kd> p
MYUSBDriver!MYUSB_EvtDeviceFileCreate+0x7c:
fffff800`9bde80fc 488b442438 mov rax,qword ptr [rsp+38h]
2: kd> p
MYUSBDriver!MYUSB_EvtDeviceFileCreate+0x89:
fffff800`9bde8109 c744242400000000 mov dword ptr [rsp+24h],0
2: kd> g
Breakpoint 1 hit
Breakpoint 2 hit
MYUSBDriver!MYUSB_EvtDeviceFileClose:
fffff800`9bde8000 48894c2408 mov qword ptr [rsp+8],rcx
2: kd> p
MYUSBDriver!MYUSB_EvtDeviceFileClose+0x9:
fffff800`9bde8009 48c744243000000000 mov qword ptr [rsp+30h],0
2: kd> p
MYUSBDriver!MYUSB_EvtDeviceFileClose+0x12:
fffff800`9bde8012 e8e98fffff call MYUSBDriver!KeGetCurrentIrql (fffff800`9bde1000)
2: kd> p
MYUSBDriver!MYUSB_EvtDeviceFileClose+0x4c:
fffff800`9bde804c 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 - <Unable to get error code text>

FAULTING_IP:
Wdf01000+1116
fffff800`995a1116 4c8b5010 mov r10,qword ptr [rax+10h]

CONTEXT: ffffd0009069bc50 -- (.cxr 0xffffd0009069bc50)
rax=00001ffe92aafd08 rbx=ffffe0016d070f60 rcx=0000000000000000
rdx=ffffe0016d5502f0 rsi=ffffe0016cada790 rdi=ffffe0016ac9f4e0
rip=fffff800995a1116 rsp=ffffd0009069c670 rbp=ffffd0009069c7e9
r8=fffff8009bde5028 r9=fffff8009965a238 r10=ffffe0016cb01cc0
r11=ffffd0009069c880 r12=ffffe0016cada810 r13=0000000000000000
r14=00001ffe926f1d38 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010246
Wdf01000+0x1116:
fffff800`995a1116 4c8b5010 mov r10,qword ptr [rax+10h] ds:002b:00001ffe`92aafd18=????????????????
Resetting default scope

CPU_COUNT: 4

CPU_MHZ: cdc

CPU_VENDOR: GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 3c

CPU_STEPPING: 3

CURRENT_IRQL: 0

ANALYSIS_VERSION: 10.0.10240.9 amd64fre

LAST_CONTROL_TRANSFER: from fffff8009bde1596 to fffff800995a1116

STACK_TEXT:
ffffd000`9069c670 fffff800`9bde1596 : ffffffff`ffffffd2 fffff800`9bde17a0 00000000`00000010 00000000`00000286 : Wdf01000+0x1116
ffffd000`9069c6c0 fffff800`9bde17aa : ffffe001`6d5502f0 fffff800`9bde5028 00000000`00000010 00000000`00000284 : MYUSBDriver!WdfObjectGetTypedContextWorker+0x36 [c:\program files (x86)\windows kits\10\include\wdf\kmdf\1.15\wdfobject.h @ 564]
ffffd000`9069c6f0 fffff800`9bde8068 : ffffe001`6d5502f0 ffffd000`9069c7e9 00000000`00000000 fffff800`9bde8005 : MYUSBDriver!GetDeviceContext+0x1a [c:\es582-code\MYUSBdriver\MYUSBdriver\MYUSB_private.h @ 291]
ffffd000`9069c720 fffff800`995e564f : 00001ffe`926f1d38 00000000`00000000 ffffe001`6ac9f4e0 ffffe001`6acf2d38 : MYUSBDriver!MYUSB_EvtDeviceFileClose+0x68 [c:\es582-code\MYUSBdriver\MYUSBdriver\control_io.c @ 253]
ffffd000`9069c770 fffff800`995a197e : 00000000`00000009 fffff803`efc9db72 ffffe001`6d31e000 fffff800`9b283235 : Wdf01000+0x4564f
ffffd000`9069c850 fffff800`9b283004 : 00000000`00000012 ffffe001`6d3df980 ffffe001`6d3df980 ffffe001`6ac9f4e0 : Wdf01000+0x197e
ffffd000`9069c8a0 fffff803`f0114bdf : ffffe001`6ad1f920 00000000`00000000 00000000`00000000 00000000`00000000 : USBlyzer+0x3004
ffffd000`9069c8d0 fffff803`f009e802 : 00000000`00000001 00000000`00000000 ffffd000`9069ca49 ffff84f0`00000002 : nt!NtQuerySecurityObject+0xa9f
ffffd000`9069c960 fffff803`f009d05d : ffff84f0`7b12af56 00000000`00000000 000000d4`cbe7f660 00000000`00000000 : nt!NtWaitForSingleObject+0x3e2
ffffd000`9069caa0 fffff803`efdd3263 : ffffe001`6d7a8840 000000d4`cbfb3a80 ffffe001`6d7a8840 ffffd000`9069cb80 : nt!NtClose+0xcd
ffffd000`9069cb00 00007ffc`9df1363a : 00007ffc`9b3922a1 00000000`00000000 00000000`00000000 000078ca`493c0126 : nt!setjmpex+0x37d3
000000d4`cbe7fa78 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!ZwClose+0xa


FOLLOWUP_IP:
MYUSBDriver!WdfObjectGetTypedContextWorker+36 [c:\program files (x86)\windows kits\10\include\wdf\kmdf\1.15\wdfobject.h @ 564]
fffff800`9bde1596 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
---------

Comments

  • Slava_ImameevSlava_Imameev Member Posts: 480
    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.
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,443
    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > 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.
  • srini_k_rsrini_k_r Member Posts: 18
    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?
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,444
    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.com
    Sent: Wednesday, August 17, 2016 7:09 AM
    To: Windows System Software Devs Interest List
    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:

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

    To unsubscribe, visit the List Server section of OSR Online at
    d
  • srini_k_rsrini_k_r Member Posts: 18
    thanks for suggestion.

    What is the "last Ob reference "?
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,444
    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.com
    Sent: Wednesday, August 17, 2016 7:49 AM
    To: Windows System Software Devs Interest List
    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:

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

    To unsubscribe, visit the List Server section of OSR Online at
    d
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,443
    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Ken_JohnsonKen_Johnson Member - All Emails Posts: 1,559
    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.com
    Sent: Wednesday, August 17, 2016 1:39 PM
    To: Windows System Software Devs Interest List
    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:

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

    To unsubscribe, visit the List Server section of OSR Online at
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,443
    <quote>
    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
    </quote>

    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

    Peter Viscarola
    OSR
    @OSRDrivers

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 21 Oct 2019 OSR Seminar Space & ONLINE
Internals & Software Drivers 18 Nov 2019 Dulles, VA
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 27 Apr 2020 OSR Seminar Space & ONLINE