See if you can reproduce this ‘live’ so that all physical memory is
available for inspection and the trapframe can be analyzed.
I’m not sure what kind of crash-dump you enabled but it seems like the dump
has not captured enough for !analyze to give you the register values from
the trap frame.
When you do get to the point of a live (or better dumpfile - make sure you
are configured for full memory dumps) the first thing I would do is to
determine what the invalid access is all about.
We can guess that ws2ifsl!DispatchDeviceControl is a ‘dispatch’ routine in
that driver and that like all Dispach Routines it takes two arguments, the
PDEVICE_OBJECT and PIRP.
You should start with extracting (from the stack) those arguments and
feeding the values into the debugger extensions that crack Device Objects
and IRPs respectively to find out if total rubbish has been propagated to
the dispatch routine.
!devobj
!irp
The second thing that comes to mind is that this call stack shows pretty
clearly that the call originates with some module calling
IoQueryFileDosDeviceName() and that the call is not in a ‘known’ module.
Is that your hook? You ought to have full (private) symbols for your
driver loaded.
The third thing that comes to mind is to ask the question: Is calling
IoQueryFileDosDeviceName() on the ‘socket’ device stack a good idea (does it
make sense). This must be NT6 right? Because the target is ws2ifsl and
not AFD? This speaks to the core of your problem I guess. After you
find out why the underlying driver is blowing up on the call, perhaps you
can figure out if the higher level operation is even sensible for this
FILE_OBJECT. I have trouble believing that NT would just blow up if you
called the IoQuery…() routine but I don?t rule it out.
You need the I/O & FSD knowledgeable folks to ponder those questions. The
‘network guy’ is running out of ideas.
Good Luck,
Dave Cattley
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Thursday, October 14, 2010 12:25 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] IoQueryFileDosDeviceName Causing BSOD
The following is the result of !analyze -v:
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx”
referenced memory at “0x%08lx”. The memory could not be “%s”.
FAULTING_IP:
ws2ifsl!DispatchDeviceControl+b
f71d2f9d 8b4a0c mov ecx,dword ptr [edx+0Ch]
TRAP_FRAME: ee888b5c – (.trap 0xffffffffee888b5c)
Unable to read trap frame at ee888b5c
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x8E
LAST_CONTROL_TRANSFER: from 804ee129 to f71d2f9d
STACK_TEXT:
ee888bd0 804ee129 866a9408 8664e908 00000200
ws2ifsl!DispatchDeviceControl+0xb
ee888be0 804f2f55 000000c8 862f3eb0 e26abae8 nt!IopfCallDriver+0x31
ee888e30 80577900 866a9408 e26abae8 6e446f49 nt!IoVolumeDeviceToDosName+0x89
ee888e94 8056a534 862f3eb0 00000001 00000001 nt!IopQueryNameInternal+0x92
ee888ec4 ee990022 862f3eb0 ee888eec 00adfa10
nt!IoQueryFileDosDeviceName+0x2e
WARNING: Frame IP not in any known module. Following frames may be wrong.
ee888fc0 804fa043 86722ae8 8664e10c ffdff9c0 0xee990022
ee889d30 8053d648 00adfa48 001f01ff 00adf9f8 nt!KeInsertQueueDpc+0xd9
ee889d30 7c90e4f4 00adfa48 001f01ff 00adf9f8 nt!KiFastCallEntry+0xf8
00adfa28 00000000 00000000 00000000 00000000 0x7c90e4f4
STACK_COMMAND: kb
FOLLOWUP_IP:
ws2ifsl!DispatchDeviceControl+b
f71d2f9d 8b4a0c mov ecx,dword ptr [edx+0Ch]
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: ws2ifsl!DispatchDeviceControl+b
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: ws2ifsl
IMAGE_NAME: ws2ifsl.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 3b7d84de
FAILURE_BUCKET_ID: 0x8E_ws2ifsl!DispatchDeviceControl+b
BUCKET_ID: 0x8E_ws2ifsl!DispatchDeviceControl+b
Followup: MachineOwner
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
