Crash in WdfRequestRetrieveInputBuffer

NTDEV
1

Hi All,
While Experimenting with WDF I came across Different Scenario . My driver created a WDF Request object . And I Formatted the request with preallcoated Buffer using the macro WdfIoTargetFormatRequestForInternalIoctl. When i try to retrieve the buffer using WdfRequestRetrieveInputBuffer ,the system crashing with Bugcheck of 0xD1.

I analyzed the Bug , the buffer pointer was correct in IRP_MJ_INTERNAL_DEVICE_CONTROL location in IRP. Here am sending the !analyze -v report along with Wdfkd outputs.

My question is ,why WdfRequestRetrieveInputBuffer giving bugcheck while Creation of WDF Request and retrieval of Buffer in same driver ? I tried this experiment in MSDN sample NetVmini.

*** Fatal System Error: 0x000000d1
(0x000000000000000A,0x0000000000000002,0x0000000000000000,0xFFFFF88000E87807)

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.

Connected to Windows 7 7601 x64 target at (Thu Nov 14 17:14:54.550 2013 (UTC + 5:30)), ptr64 TRUE
Loading Kernel Symbols
…
…
…
Loading User Symbols

Loading unloaded module list
…
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck D1, {a, 2, 0, fffff88000e87807}

Probably caused by : netvmini620.sys ( netvmini620!WdfRequestRetrieveInputBuffer+3e )

Followup: MachineOwner

nt!RtlpBreakWithStatusInstruction:
fffff800`02880490 cc int 3
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 000000000000000a, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff88000e87807, address which referenced memory

Debugging Details:

READ_ADDRESS: 000000000000000a

CURRENT_IRQL: 2

FAULTING_IP:
Wdf01000!FxRequest::GetMemoryObject+41b
fffff880`00e87807 664439490a cmp word ptr [rcx+0Ah],r9w

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xD1

PROCESS_NAME: System

TRAP_FRAME: fffff88002f9cd30 – (.trap 0xfffff88002f9cd30)
.trap 0xfffff88002f9cd30
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000
rdx=0000057ffe7792e8 rsi=0000000000000000 rdi=0000000000000000
rip=fffff88000e87807 rsp=fffff88002f9cec0 rbp=0000057ffe779200
r8=fffff88002f9cf77 r9=0000000000000000 r10=fffffa8001886d10
r11=fffff88002f9cc40 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
Wdf01000!FxRequest::GetMemoryObject+0x41b:
fffff88000e87807 664439490a cmp word ptr [rcx+0Ah],r9w ds:000000000000000a=???
.trap
Resetting default scope

LOCK_ADDRESS: fffff80002a84440 – (!locks fffff80002a84440)
!locks fffff80002a84440

Resource @ nt!PiEngineLock (0xfffff80002a84440) Exclusively owned
Contention Count = 5
Threads: fffffa80009c3b60-01<*>
1 total locks, 1 locks currently held

PNP_TRIAGE:
Lock address : 0xfffff80002a84440
Thread Count : 1
Thread address: 0xfffffa80009c3b60
Thread wait : 0x18a0d

LAST_CONTROL_TRANSFER: from fffff8000296fd92 to fffff80002880490

STACK_TEXT:
fffff88002f9c478 fffff8000296fd92 : 000000000000000a fffffa80009c3b60 0000000000000065 fffff800028c4178 : nt!RtlpBreakWithStatusInstruction
fffff88002f9c480 fffff80002970b7e : 0000000000000003 0000000000000000 fffff800028c49d0 00000000000000d1 : nt!KiBugCheckDebugBreak+0x12
fffff88002f9c4e0 fffff80002888744 : 0000000000000000 00001f80018b0635 0000000000000000 fffff80002832790 : nt!KeBugCheck2+0x71e
fffff88002f9cbb0 fffff80002887be9 : 000000000000000a 000000000000000a 0000000000000002 0000000000000000 : nt!KeBugCheckEx+0x104
fffff88002f9cbf0 fffff80002886860 : 0000000000000000 0000000000000000 0000000000000000 fffffa8001886d10 : nt!KiBugCheckDispatch+0x69
fffff88002f9cd30 fffff88000e87807 : fffffa8001905ed8 000000000000000f 0000000000000000 fffffa8001886d10 : nt!KiPageFault+0x260
fffff88002f9cec0 fffff88000e7779e : 0000000000000000 fffff88002f9cfe8 fffff88002f9d088 fffff88000e5ffe0 : Wdf01000!FxRequest::GetMemoryObject+0x41b
fffff88002f9cf50 fffff88003873d4e : fffffa8001886d10 0000000000000000 0000000000000014 fffff88003888f19 : Wdf01000!imp_WdfRequestRetrieveInputBuffer+0x142
fffff88002f9cfe0 fffff88003888f3e : 0000057ffe7792e8 0000000000000018 fffff88002f9d098 fffff88002f9d088 : netvmini620!WdfRequestRetrieveInputBuffer+0x3e [c:\winddk\7600.16385.1\inc\wdf\kmdf\1.9\wdfrequest.h @ 1168]
fffff88002f9d020 fffff880014aede5 : fffffa8000e331a0 fffff88003886100 fffff88002f9d330 fffffa8000b9c5d0 : netvmini620!MPInitializeEx+0x45e [c:\shared\netvmini\6x\adapter.c @ 288]
fffff88002f9d270 fffff880014ae683 : fffffa8002678120 fffffa8000b17020 0000000000000000 01cee12ce8a206e6 : ndis!ndisMInitializeAdapter+0x695
fffff88002f9d630 fffff880014b076c : fffffa8002678120 fffffa8000e33050 0000000000000000 fffffa8000c4a7d0 : ndis!ndisInitializeAdapter+0x113
fffff88002f9d690 fffff880014ae356 : fffffa8000e331a0 fffffa8002678120 0000000000000000 ffff24667b64d6c5 : ndis!ndisPnPStartDevice+0xac
fffff88002f9d6f0 fffff80002c3f17e : 0000000000000000 fffffa8002678120 fffffa8000e33050 fffff88002f9d820 : ndis!ndisPnPDispatch+0x246
fffff88002f9d790 fffff80002975b2d : fffffa8000c4a7d0 fffffa80014e6e30 fffff8000297f250 0000000000000000 : nt!PnpAsynchronousCall+0xce
fffff88002f9d7d0 fffff80002c4e4c6 : fffff80002a84200 fffffa8000afcb80 fffffa80014e6e30 fffffa8000afcd28 : nt!PnpStartDevice+0x11d
fffff88002f9d890 fffff80002c4e764 : fffffa8000afcb80 fffffa8000af0011 fffffa8000afcb80 0000000000000001 : nt!PnpStartDeviceNode+0x156
fffff88002f9d920 fffff80002c71e96 : fffffa8000afcb80 fffffa8000afcb80 0000000000000000 0000000000000000 : nt!PipProcessStartPhase1+0x74
fffff88002f9d950 fffff80002c72287 : fffffa8000afcb80 0000000000000001 0000000000000001 fffff80002af3c38 : nt!PipProcessDevNodeTree+0x296
fffff88002f9dbc0 fffff80002981b83 : 0000000100000003 0000000000000000 0000000000000001 0000000000000000 : nt!PiRestartDevice+0xc7
fffff88002f9dc10 fffff80002892a21 : fffff80002981870 fffff80002a25601 fffffa80009c3b00 0000000000000000 : nt!PnpDeviceActionWorker+0x313
fffff88002f9dcb0 fffff80002b25cce : 0000000000000000 fffffa80009c3b60 0000000000000080 fffffa800093a890 : nt!ExpWorkerThread+0x111
fffff88002f9dd40 fffff80002879fe6 : fffff800029fae80 fffffa80009c3b60 fffffa80009c3040 0000000000000000 : nt!PspSystemThreadStartup+0x5a
fffff88002f9dd80 0000000000000000 : fffff88002f9e000 fffff88002f98000 fffff88002f9c1b0 0000000000000000 : nt!KxStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
netvmini620!WdfRequestRetrieveInputBuffer+3e [c:\winddk\7600.16385.1\inc\wdf\kmdf\1.9\wdfrequest.h @ 1168]
fffff880`03873d4e 4883c438 add rsp,38h

FAULTING_SOURCE_CODE:
1164: size_t* Length
1165: )
1166: {
1167: return ((PFN_WDFREQUESTRETRIEVEINPUTBUFFER) WdfFunctions[WdfRequestRetrieveInputBufferTableIndex])(WdfDriverGlobals, Request, MinimumRequiredLength, Buffer, Length);

1168: }
1169:
1170: //
1171: // WDF Function: WdfRequestRetrieveOutputBuffer
1172: //
1173: typedef

SYMBOL_STACK_INDEX: 8

SYMBOL_NAME: netvmini620!WdfRequestRetrieveInputBuffer+3e

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: netvmini620

IMAGE_NAME: netvmini620.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 5284a852

FAILURE_BUCKET_ID: X64_0xD1_netvmini620!WdfRequestRetrieveInputBuffer+3e

BUCKET_ID: X64_0xD1_netvmini620!WdfRequestRetrieveInputBuffer+3e

Followup: MachineOwner

The WDf kd outputs are :
d> !wdfkd.wdfdriverinfo netvmini620.sys 0x10

Default driver image name: netvmini620
WDF library image name: Wdf01000
FxDriverGlobals 0xfffffa8000c03220
WdfBindInfo 0xfffff88003885110
Version v1.9 build(7600)

Driver Handles:
!WDFDRIVER 0x0000057fff276538
!WDFDEVICE 0x0000057fff20d988
!WDFIOTARGET 0x0000057fff545bc8
!WDFMEMORY 0x0000057fff37bc18
!WDFREQUEST 0x0000057ffe7792e8

kd> !WDFREQUEST 0x0000057ffe7792e8
!IRP 0xfffffa8001905dc0

State: Allocated by driver, IRP allocated by WDF

kd> !IRP 0xfffffa8001905dc0 1
Irp is active with 1 stacks 2 is current (= 0xfffffa8001905ed8)
No Mdl: No System Buffer: Thread 00000000: Irp is completed.
Flags = 00000000
ThreadListEntry.Flink = fffffa8001905de0
ThreadListEntry.Blink = fffffa8001905de0
IoStatus.Status = 00000000
IoStatus.Information = 00000000
RequestorMode = 00000000
Cancel = 00
CancelIrql = 0
ApcEnvironment = 00
UserIosb = 00000000
UserEvent = 00000000
Overlay.AsynchronousParameters.UserApcRoutine = 00000000
Overlay.AsynchronousParameters.UserApcContext = 00000000
Overlay.AllocationSize = 00000000 - 00000000
CancelRoutine = 00000000
UserBuffer = 00000000
&Tail.Overlay.DeviceQueueEntry = fffffa8001905e38
Tail.Overlay.Thread = 00000000
Tail.Overlay.AuxiliaryBuffer = 00000000
Tail.Overlay.ListEntry.Flink = 00000000
Tail.Overlay.ListEntry.Blink = 00000000
Tail.Overlay.CurrentStackLocation = fffffa8001905ed8
Tail.Overlay.OriginalFileObject = 00000000
Tail.Apc = 00000000
Tail.CompletionKey = 00000000
cmd flg cl Device File Completion-Context
[f, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000018 00122043 fffffa80018d7970

2

The request has been completed, the input buffer is no longer valid. You
supplied the input buffer and, it seems that you sent this request
synchronously to an io target. You supplied the buffer, you do not need to
get it from the request, right? If you had used an asynchronous method to
forward the request you could call WdfRequestGetCompletionParams.

Mark Roddy

On Thu, Nov 14, 2013 at 7:22 AM, wrote:

> Hi All,
> While Experimenting with WDF I came across Different
> Scenario . My driver created a WDF Request object . And I Formatted the
> request with preallcoated Buffer using the macro
> WdfIoTargetFormatRequestForInternalIoctl. When i try to retrieve the buffer
> using WdfRequestRetrieveInputBuffer ,the system crashing with Bugcheck of
> 0xD1.
>
> I analyzed the Bug , the buffer pointer was correct in
> IRP_MJ_INTERNAL_DEVICE_CONTROL location in IRP. Here am sending the
> !analyze -v report along with Wdfkd outputs.
>
> My question is ,why WdfRequestRetrieveInputBuffer giving bugcheck while
> Creation of WDF Request and retrieval of Buffer in same driver ? I tried
> this experiment in MSDN sample NetVmini.
>
>
> Fatal System Error: 0x000000d1
>
> (0x000000000000000A,0x0000000000000002,0x0000000000000000,0xFFFFF88000E87807)
>
> 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.
>
> Connected to Windows 7 7601 x64 target at (Thu Nov 14 17:14:54.550 2013
> (UTC + 5:30)), ptr64 TRUE
> Loading Kernel Symbols
> …
> …
> …
> Loading User Symbols
>
> Loading unloaded module list
> …
>
>****************************************************************************
> *
> *
> * Bugcheck Analysis
> *
> *
> *
>
> *****************************************************************************
>
> Use !analyze -v to get detailed debugging information.
>
> BugCheck D1, {a, 2, 0, fffff88000e87807}
>
> Probably caused by : netvmini620.sys (
> netvmini620!WdfRequestRetrieveInputBuffer+3e )
>
> Followup: MachineOwner
> ---------
>
> nt!RtlpBreakWithStatusInstruction:
> fffff80002880490 cc int 3<br>&gt; kd&gt; !analyze -v<br>&gt;<br>&gt;*******************************************************************************<br>&gt; *<br>&gt; *<br>&gt; * Bugcheck Analysis<br>&gt; *<br>&gt; *<br>&gt; *<br>&gt;<br>&gt; ******************************************************************************* <br>&gt;<br>&gt; DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)<br>&gt; An attempt was made to access a pageable (or completely invalid) address<br>&gt; at an<br>&gt; interrupt request level (IRQL) that is too high. This is usually<br>&gt; caused by drivers using improper addresses.<br>&gt; If kernel debugger is available get stack backtrace.<br>&gt; Arguments:<br>&gt; Arg1: 000000000000000a, memory referenced<br>&gt; Arg2: 0000000000000002, IRQL<br>&gt; Arg3: 0000000000000000, value 0 = read operation, 1 = write operation<br>&gt; Arg4: fffff88000e87807, address which referenced memory<br>&gt;<br>&gt; Debugging Details:<br>&gt; ------------------<br>&gt;<br>&gt;<br>&gt; READ_ADDRESS: 000000000000000a<br>&gt;<br>&gt; CURRENT_IRQL: 2<br>&gt;<br>&gt; FAULTING_IP:<br>&gt; Wdf01000!FxRequest::GetMemoryObject+41b<br>&gt; fffff88000e87807 664439490a cmp word ptr [rcx+0Ah],r9w
>
> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
>
> BUGCHECK_STR: 0xD1
>
> PROCESS_NAME: System
>
> TRAP_FRAME: fffff88002f9cd30 – (.trap 0xfffff88002f9cd30)
> .trap 0xfffff88002f9cd30
> NOTE: The trap frame does not contain all registers.
> Some register values may be zeroed or incorrect.
> rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000
> rdx=0000057ffe7792e8 rsi=0000000000000000 rdi=0000000000000000
> rip=fffff88000e87807 rsp=fffff88002f9cec0 rbp=0000057ffe779200
> r8=fffff88002f9cf77 r9=0000000000000000 r10=fffffa8001886d10
> r11=fffff88002f9cc40 r12=0000000000000000 r13=0000000000000000
> r14=0000000000000000 r15=0000000000000000
> iopl=0 nv up ei pl nz na po nc
> Wdf01000!FxRequest::GetMemoryObject+0x41b:
> fffff88000e87807 664439490a cmp word ptr [rcx+0Ah],r9w<br>&gt; ds:000000000000000a=???
> .trap
> Resetting default scope
>
> LOCK_ADDRESS: fffff80002a84440 – (!locks fffff80002a84440)
> !locks fffff80002a84440
>
> Resource @ nt!PiEngineLock (0xfffff80002a84440) Exclusively owned
> Contention Count = 5
> Threads: fffffa80009c3b60-01<>
> 1 total locks, 1 locks currently held
>
> PNP_TRIAGE:
> Lock address : 0xfffff80002a84440
> Thread Count : 1
> Thread address: 0xfffffa80009c3b60
> Thread wait : 0x18a0d
>
> LAST_CONTROL_TRANSFER: from fffff8000296fd92 to fffff80002880490
>
> STACK_TEXT:
> fffff88002f9c478 fffff8000296fd92 : 000000000000000a fffffa80009c3b60
> 0000000000000065 fffff800028c4178 : nt!RtlpBreakWithStatusInstruction
> fffff88002f9c480 fffff80002970b7e : 0000000000000003 0000000000000000
> fffff800028c49d0 00000000000000d1 : nt!KiBugCheckDebugBreak+0x12
> fffff88002f9c4e0 fffff80002888744 : 0000000000000000 00001f80018b0635
> 0000000000000000 fffff80002832790 : nt!KeBugCheck2+0x71e
> fffff88002f9cbb0 fffff80002887be9 : 000000000000000a 000000000000000a
> 0000000000000002 0000000000000000 : nt!KeBugCheckEx+0x104
> fffff88002f9cbf0 fffff80002886860 : 0000000000000000 0000000000000000
> 0000000000000000 fffffa8001886d10 : nt!KiBugCheckDispatch+0x69
> fffff88002f9cd30 fffff88000e87807 : fffffa8001905ed8 000000000000000f
> 0000000000000000 fffffa8001886d10 : nt!KiPageFault+0x260
> fffff88002f9cec0 fffff88000e7779e : 0000000000000000 fffff88002f9cfe8
> fffff88002f9d088 fffff88000e5ffe0 :
> Wdf01000!FxRequest::GetMemoryObject+0x41b
> fffff88002f9cf50 fffff88003873d4e : fffffa8001886d10 0000000000000000
> 0000000000000014 fffff88003888f19 :
> Wdf01000!imp_WdfRequestRetrieveInputBuffer+0x142
> fffff88002f9cfe0 fffff88003888f3e : 0000057ffe7792e8 0000000000000018
> fffff88002f9d098 fffff88002f9d088 :
> netvmini620!WdfRequestRetrieveInputBuffer+0x3e
> [c:\winddk\7600.16385.1\inc\wdf\kmdf\1.9\wdfrequest.h @ 1168]
> fffff88002f9d020 fffff880014aede5 : fffffa8000e331a0 fffff88003886100
> fffff88002f9d330 fffffa8000b9c5d0 : netvmini620!MPInitializeEx+0x45e
> [c:\shared\netvmini\6x\adapter.c @ 288]
> fffff88002f9d270 fffff880014ae683 : fffffa8002678120 fffffa8000b17020
> 0000000000000000 01cee12ce8a206e6 : ndis!ndisMInitializeAdapter+0x695
> fffff88002f9d630 fffff880014b076c : fffffa8002678120 fffffa8000e33050
> 0000000000000000 fffffa8000c4a7d0 : ndis!ndisInitializeAdapter+0x113
> fffff88002f9d690 fffff880014ae356 : fffffa8000e331a0 fffffa8002678120
> 0000000000000000 ffff24667b64d6c5 : ndis!ndisPnPStartDevice+0xac
> fffff88002f9d6f0 fffff80002c3f17e : 0000000000000000 fffffa8002678120
> fffffa8000e33050 fffff88002f9d820 : ndis!ndisPnPDispatch+0x246
> fffff88002f9d790 fffff80002975b2d : fffffa8000c4a7d0 fffffa80014e6e30
> fffff8000297f250 0000000000000000 : nt!PnpAsynchronousCall+0xce
> fffff88002f9d7d0 fffff80002c4e4c6 : fffff80002a84200 fffffa8000afcb80
> fffffa80014e6e30 fffffa8000afcd28 : nt!PnpStartDevice+0x11d
> fffff88002f9d890 fffff80002c4e764 : fffffa8000afcb80 fffffa8000af0011
> fffffa8000afcb80 0000000000000001 : nt!PnpStartDeviceNode+0x156
> fffff88002f9d920 fffff80002c71e96 : fffffa8000afcb80 fffffa8000afcb80
> 0000000000000000 0000000000000000 : nt!PipProcessStartPhase1+0x74
> fffff88002f9d950 fffff80002c72287 : fffffa8000afcb80 0000000000000001
> 0000000000000001 fffff80002af3c38 : nt!PipProcessDevNodeTree+0x296
> fffff88002f9dbc0 fffff80002981b83 : 0000000100000003 0000000000000000
> 0000000000000001 0000000000000000 : nt!PiRestartDevice+0xc7
> fffff88002f9dc10 fffff80002892a21 : fffff80002981870 fffff80002a25601
> fffffa80009c3b00 0000000000000000 : nt!PnpDeviceActionWorker+0x313
> fffff88002f9dcb0 fffff80002b25cce : 0000000000000000 fffffa80009c3b60
> 0000000000000080 fffffa800093a890 : nt!ExpWorkerThread+0x111
> fffff88002f9dd40 fffff80002879fe6 : fffff800029fae80 fffffa80009c3b60
> fffffa80009c3040 0000000000000000 : nt!PspSystemThreadStartup+0x5a
> fffff88002f9dd80 0000000000000000 : fffff88002f9e000 fffff88002f98000
> fffff88002f9c1b0 0000000000000000 : nt!KxStartSystemThread+0x16
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> netvmini620!WdfRequestRetrieveInputBuffer+3e
> [c:\winddk\7600.16385.1\inc\wdf\kmdf\1.9\wdfrequest.h @ 1168]
> fffff880`03873d4e 4883c438 add rsp,38h
>
> FAULTING_SOURCE_CODE:
> 1164: size_t Length
> 1165: )
> 1166: {
> 1167: return ((PFN_WDFREQUESTRETRIEVEINPUTBUFFER)
> WdfFunctions[WdfRequestRetrieveInputBufferTableIndex])(WdfDriverGlobals,
> Request, MinimumRequiredLength, Buffer, Length);
> > 1168: }
> 1169:
> 1170: //
> 1171: // WDF Function: WdfRequestRetrieveOutputBuffer
> 1172: //
> 1173: typedef
>
>
> SYMBOL_STACK_INDEX: 8
>
> SYMBOL_NAME: netvmini620!WdfRequestRetrieveInputBuffer+3e
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: netvmini620
>
> IMAGE_NAME: netvmini620.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 5284a852
>
> FAILURE_BUCKET_ID: X64_0xD1_netvmini620!WdfRequestRetrieveInputBuffer+3e
>
> BUCKET_ID: X64_0xD1_netvmini620!WdfRequestRetrieveInputBuffer+3e
>
> Followup: MachineOwner
>
>
> The WDf kd outputs are :
> d> !wdfkd.wdfdriverinfo netvmini620.sys 0x10
> ----------------------------------
> Default driver image name: netvmini620
> WDF library image name: Wdf01000
> FxDriverGlobals 0xfffffa8000c03220
> WdfBindInfo 0xfffff88003885110
> Version v1.9 build(7600)
> ----------------------------------
> Driver Handles:
> !WDFDRIVER 0x0000057fff276538
> !WDFDEVICE 0x0000057fff20d988
> !WDFIOTARGET 0x0000057fff545bc8
> !WDFMEMORY 0x0000057fff37bc18
> !WDFREQUEST 0x0000057ffe7792e8
> ----------------------------------
> kd> !WDFREQUEST 0x0000057ffe7792e8
> !IRP 0xfffffa8001905dc0
>
> State: Allocated by driver, IRP allocated by WDF
>
> kd> !IRP 0xfffffa8001905dc0 1
> Irp is active with 1 stacks 2 is current (= 0xfffffa8001905ed8)
> No Mdl: No System Buffer: Thread 00000000: Irp is completed.
> Flags = 00000000
> ThreadListEntry.Flink = fffffa8001905de0
> ThreadListEntry.Blink = fffffa8001905de0
> IoStatus.Status = 00000000
> IoStatus.Information = 00000000
> RequestorMode = 00000000
> Cancel = 00
> CancelIrql = 0
> ApcEnvironment = 00
> UserIosb = 00000000
> UserEvent = 00000000
> Overlay.AsynchronousParameters.UserApcRoutine = 00000000
> Overlay.AsynchronousParameters.UserApcContext = 00000000
> Overlay.AllocationSize = 00000000 - 00000000
> CancelRoutine = 00000000
> UserBuffer = 00000000
> &Tail.Overlay.DeviceQueueEntry = fffffa8001905e38
> Tail.Overlay.Thread = 00000000
> Tail.Overlay.AuxiliaryBuffer = 00000000
> Tail.Overlay.ListEntry.Flink = 00000000
> Tail.Overlay.ListEntry.Blink = 00000000
> Tail.Overlay.CurrentStackLocation = fffffa8001905ed8
> Tail.Overlay.OriginalFileObject = 00000000
> Tail.Apc = 00000000
> Tail.CompletionKey = 00000000
> cmd flg cl Device File Completion-Context
> [f, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000018 00122043 fffffa80018d7970
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>

3

The input buffer (and output) require a valid current irp stack location to know how to decode them. A self allocated request does not have a valid current irp stack location, the format call touches the next irp stack location, not the current.

d

Bent from my phone

From: Mark Roddymailto:xxxxx
Sent: ?11/?14/?2013 6:38 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: Re: [ntdev] Crash in WdfRequestRetrieveInputBuffer

The request has been completed, the input buffer is no longer valid. You supplied the input buffer and, it seems that you sent this request synchronously to an io target. You supplied the buffer, you do not need to get it from the request, right? If you had used an asynchronous method to forward the request you could call WdfRequestGetCompletionParams.

Mark Roddy

On Thu, Nov 14, 2013 at 7:22 AM, > wrote:
Hi All,
While Experimenting with WDF I came across Different Scenario . My driver created a WDF Request object . And I Formatted the request with preallcoated Buffer using the macro WdfIoTargetFormatRequestForInternalIoctl. When i try to retrieve the buffer using WdfRequestRetrieveInputBuffer ,the system crashing with Bugcheck of 0xD1.

I analyzed the Bug , the buffer pointer was correct in IRP_MJ_INTERNAL_DEVICE_CONTROL location in IRP. Here am sending the !analyze -v report along with Wdfkd outputs.

My question is ,why WdfRequestRetrieveInputBuffer giving bugcheck while Creation of WDF Request and retrieval of Buffer in same driver ? I tried this experiment in MSDN sample NetVmini.

Fatal System Error: 0x000000d1
(0x000000000000000A,0x0000000000000002,0x0000000000000000,0xFFFFF88000E87807)

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.

Connected to Windows 7 7601 x64 target at (Thu Nov 14 17:14:54.550 2013 (UTC + 5:30)), ptr64 TRUE
Loading Kernel Symbols
…
…
…
Loading User Symbols

Loading unloaded module list
…
Bugcheck Analysis

*

Use !analyze -v to get detailed debugging information.

BugCheck D1, {a, 2, 0, fffff88000e87807}

Probably caused by : netvmini620.sys ( netvmini620!WdfRequestRetrieveInputBuffer+3e )

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

nt!RtlpBreakWithStatusInstruction:
fffff80002880490 cc int 3<br>kd&gt; !analyze -v<br>*******************************************************************************<br>* *<br>* Bugcheck Analysis *<br>* *<br> ******************************************************************************* <br><br>DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)<br>An attempt was made to access a pageable (or completely invalid) address at an<br>interrupt request level (IRQL) that is too high. This is usually<br>caused by drivers using improper addresses.<br>If kernel debugger is available get stack backtrace.<br>Arguments:<br>Arg1: 000000000000000a, memory referenced<br>Arg2: 0000000000000002, IRQL<br>Arg3: 0000000000000000, value 0 = read operation, 1 = write operation<br>Arg4: fffff88000e87807, address which referenced memory<br><br>Debugging Details:<br>------------------<br><br>READ_ADDRESS: 000000000000000a<br><br>CURRENT_IRQL: 2<br><br>FAULTING_IP:<br>Wdf01000!FxRequest::GetMemoryObject+41b<br>fffff88000e87807 664439490a cmp word ptr [rcx+0Ah],r9w

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xD1

PROCESS_NAME: System

TRAP_FRAME: fffff88002f9cd30 – (.trap 0xfffff88002f9cd30)
.trap 0xfffff88002f9cd30
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000
rdx=0000057ffe7792e8 rsi=0000000000000000 rdi=0000000000000000
rip=fffff88000e87807 rsp=fffff88002f9cec0 rbp=0000057ffe779200
r8=fffff88002f9cf77 r9=0000000000000000 r10=fffffa8001886d10
r11=fffff88002f9cc40 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
Wdf01000!FxRequest::GetMemoryObject+0x41b:
fffff88000e87807 664439490a cmp word ptr [rcx+0Ah],r9w ds:000000000000000a=???
.trap
Resetting default scope

LOCK_ADDRESS: fffff80002a84440 – (!locks fffff80002a84440)
!locks fffff80002a84440

Resource @ nt!PiEngineLock (0xfffff80002a84440) Exclusively owned
Contention Count = 5
Threads: fffffa80009c3b60-01<>
1 total locks, 1 locks currently held

PNP_TRIAGE:
Lock address : 0xfffff80002a84440
Thread Count : 1
Thread address: 0xfffffa80009c3b60
Thread wait : 0x18a0d

LAST_CONTROL_TRANSFER: from fffff8000296fd92 to fffff80002880490

STACK_TEXT:
fffff88002f9c478 fffff8000296fd92 : 000000000000000a fffffa80009c3b60 0000000000000065 fffff800028c4178 : nt!RtlpBreakWithStatusInstruction
fffff88002f9c480 fffff80002970b7e : 0000000000000003 0000000000000000 fffff800028c49d0 00000000000000d1 : nt!KiBugCheckDebugBreak+0x12
fffff88002f9c4e0 fffff80002888744 : 0000000000000000 00001f80018b0635 0000000000000000 fffff80002832790 : nt!KeBugCheck2+0x71e
fffff88002f9cbb0 fffff80002887be9 : 000000000000000a 000000000000000a 0000000000000002 0000000000000000 : nt!KeBugCheckEx+0x104
fffff88002f9cbf0 fffff80002886860 : 0000000000000000 0000000000000000 0000000000000000 fffffa8001886d10 : nt!KiBugCheckDispatch+0x69
fffff88002f9cd30 fffff88000e87807 : fffffa8001905ed8 000000000000000f 0000000000000000 fffffa8001886d10 : nt!KiPageFault+0x260
fffff88002f9cec0 fffff88000e7779e : 0000000000000000 fffff88002f9cfe8 fffff88002f9d088 fffff88000e5ffe0 : Wdf01000!FxRequest::GetMemoryObject+0x41b
fffff88002f9cf50 fffff88003873d4e : fffffa8001886d10 0000000000000000 0000000000000014 fffff88003888f19 : Wdf01000!imp_WdfRequestRetrieveInputBuffer+0x142
fffff88002f9cfe0 fffff88003888f3e : 0000057ffe7792e8 0000000000000018 fffff88002f9d098 fffff88002f9d088 : netvmini620!WdfRequestRetrieveInputBuffer+0x3e [c:\winddk\7600.16385.1\inc\wdf\kmdf\1.9\wdfrequest.h @ 1168]
fffff88002f9d020 fffff880014aede5 : fffffa8000e331a0 fffff88003886100 fffff88002f9d330 fffffa8000b9c5d0 : netvmini620!MPInitializeEx+0x45e [c:\shared\netvmini\6x\adapter.c @ 288]
fffff88002f9d270 fffff880014ae683 : fffffa8002678120 fffffa8000b17020 0000000000000000 01cee12ce8a206e6 : ndis!ndisMInitializeAdapter+0x695
fffff88002f9d630 fffff880014b076c : fffffa8002678120 fffffa8000e33050 0000000000000000 fffffa8000c4a7d0 : ndis!ndisInitializeAdapter+0x113
fffff88002f9d690 fffff880014ae356 : fffffa8000e331a0 fffffa8002678120 0000000000000000 ffff24667b64d6c5 : ndis!ndisPnPStartDevice+0xac
fffff88002f9d6f0 fffff80002c3f17e : 0000000000000000 fffffa8002678120 fffffa8000e33050 fffff88002f9d820 : ndis!ndisPnPDispatch+0x246
fffff88002f9d790 fffff80002975b2d : fffffa8000c4a7d0 fffffa80014e6e30 fffff8000297f250 0000000000000000 : nt!PnpAsynchronousCall+0xce
fffff88002f9d7d0 fffff80002c4e4c6 : fffff80002a84200 fffffa8000afcb80 fffffa80014e6e30 fffffa8000afcd28 : nt!PnpStartDevice+0x11d
fffff88002f9d890 fffff80002c4e764 : fffffa8000afcb80 fffffa8000af0011 fffffa8000afcb80 0000000000000001 : nt!PnpStartDeviceNode+0x156
fffff88002f9d920 fffff80002c71e96 : fffffa8000afcb80 fffffa8000afcb80 0000000000000000 0000000000000000 : nt!PipProcessStartPhase1+0x74
fffff88002f9d950 fffff80002c72287 : fffffa8000afcb80 0000000000000001 0000000000000001 fffff80002af3c38 : nt!PipProcessDevNodeTree+0x296
fffff88002f9dbc0 fffff80002981b83 : 0000000100000003 0000000000000000 0000000000000001 0000000000000000 : nt!PiRestartDevice+0xc7
fffff88002f9dc10 fffff80002892a21 : fffff80002981870 fffff80002a25601 fffffa80009c3b00 0000000000000000 : nt!PnpDeviceActionWorker+0x313
fffff88002f9dcb0 fffff80002b25cce : 0000000000000000 fffffa80009c3b60 0000000000000080 fffffa800093a890 : nt!ExpWorkerThread+0x111
fffff88002f9dd40 fffff80002879fe6 : fffff800029fae80 fffffa80009c3b60 fffffa80009c3040 0000000000000000 : nt!PspSystemThreadStartup+0x5a
fffff88002f9dd80 0000000000000000 : fffff88002f9e000 fffff88002f98000 fffff88002f9c1b0 0000000000000000 : nt!KxStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
netvmini620!WdfRequestRetrieveInputBuffer+3e [c:\winddk\7600.16385.1\inc\wdf\kmdf\1.9\wdfrequest.h @ 1168]
fffff880`03873d4e 4883c438 add rsp,38h

FAULTING_SOURCE_CODE:
1164: size_t Length
1165: )
1166: {
1167: return ((PFN_WDFREQUESTRETRIEVEINPUTBUFFER) WdfFunctions[WdfRequestRetrieveInputBufferTableIndex])(WdfDriverGlobals, Request, MinimumRequiredLength, Buffer, Length);
> 1168: }
1169:
1170: //
1171: // WDF Function: WdfRequestRetrieveOutputBuffer
1172: //
1173: typedef

SYMBOL_STACK_INDEX: 8

SYMBOL_NAME: netvmini620!WdfRequestRetrieveInputBuffer+3e

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: netvmini620

IMAGE_NAME: netvmini620.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 5284a852

FAILURE_BUCKET_ID: X64_0xD1_netvmini620!WdfRequestRetrieveInputBuffer+3e

BUCKET_ID: X64_0xD1_netvmini620!WdfRequestRetrieveInputBuffer+3e

Followup: MachineOwner

The WDf kd outputs are :
d> !wdfkd.wdfdriverinfo netvmini620.sys 0x10
----------------------------------
Default driver image name: netvmini620
WDF library image name: Wdf01000
FxDriverGlobals 0xfffffa8000c03220
WdfBindInfo 0xfffff88003885110
Version v1.9 build(7600)
----------------------------------
Driver Handles:
!WDFDRIVER 0x0000057fff276538
!WDFDEVICE 0x0000057fff20d988
!WDFIOTARGET 0x0000057fff545bc8
!WDFMEMORY 0x0000057fff37bc18
!WDFREQUEST 0x0000057ffe7792e8
----------------------------------
kd> !WDFREQUEST 0x0000057ffe7792e8
!IRP 0xfffffa8001905dc0

State: Allocated by driver, IRP allocated by WDF

kd> !IRP 0xfffffa8001905dc0 1
Irp is active with 1 stacks 2 is current (= 0xfffffa8001905ed8)
No Mdl: No System Buffer: Thread 00000000: Irp is completed.
Flags = 00000000
ThreadListEntry.Flink = fffffa8001905de0
ThreadListEntry.Blink = fffffa8001905de0
IoStatus.Status = 00000000
IoStatus.Information = 00000000
RequestorMode = 00000000
Cancel = 00
CancelIrql = 0
ApcEnvironment = 00
UserIosb = 00000000
UserEvent = 00000000
Overlay.AsynchronousParameters.UserApcRoutine = 00000000
Overlay.AsynchronousParameters.UserApcContext = 00000000
Overlay.AllocationSize = 00000000 - 00000000
CancelRoutine = 00000000
UserBuffer = 00000000
&Tail.Overlay.DeviceQueueEntry = fffffa8001905e38
Tail.Overlay.Thread = 00000000
Tail.Overlay.AuxiliaryBuffer = 00000000
Tail.Overlay.ListEntry.Flink = 00000000
Tail.Overlay.ListEntry.Blink = 00000000
Tail.Overlay.CurrentStackLocation = fffffa8001905ed8
Tail.Overlay.OriginalFileObject = 00000000
Tail.Apc = 00000000
Tail.CompletionKey = 00000000
cmd flg cl Device File Completion-Context
[f, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000018 00122043 fffffa80018d7970

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

— NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers 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</mailto:xxxxx></mailto:xxxxx>

4

Thanks Doron.