I am rewriting a WDM driver to use KMDF. My driver forwards most requests to
the system supplied serial driver used as lower filter driver. The requests
are forwarded using WdfRequestSend with the
WDF_REQUEST_SEND_OPTION_SEND_AND_FORGET option. This completes successfully,
but after my event handler exits an access violation (c0000005) occurs at
Wdf01000!FxIFR+0x111. No doubt I am doing something wrong, but I don't see
how to find out what. Any ideas?

The call stack at various points and the WDF log are below:
In serial:
00 822c8048 82079738 f6453b38 serial!SerialIoControl (FPO: [Non-Fpo]) (CONV:
stdcall) [q:\wrkddk\serial\ioctl.c @ 597]
01 822c2048 822c2134 8206f490 nt!IopfCallDriver+0x51 (FPO: [0,0,0])
02 822c7968 8206f490 822c3ab8 Wdf01000!imp_WdfRequestSend+0x23a (FPO:
[Non-Fpo])
03 7df90b68 7dd3c540 f6453b38 Amcc5933!WdfRequestSend+0x1d (FPO: [Non-Fpo])
(CONV: stdcall) [q:\winddk\6000\inc\wdf\kmdf\10\wdfrequest.h @ 569]
04 7dd3dfb0 7df90b68 00000004 Amcc5933!AmccPciEvtDeviceControl+0xf4 (FPO:
[Non-Fpo]) (CONV: stdcall) [d:\dev\sikmdf\amcc5933\sys\transfer.c @ 158]
05 7dd3dfb0 7df90b68 00000004 Wdf01000!FxIoQueueIoDeviceControl::Invoke+0x30
(FPO: [Non-Fpo])
06 7df90b68 8206f490 822c2048
Wdf01000!FxIoQueue::DispatchRequestToDriver+0x445 (FPO: [Non-Fpo])
07 822c2000 f96ab188 822c2048 Wdf01000!FxIoQueue::DispatchEvents+0x485 (FPO:
[Non-Fpo])
08 00000000 822c3ba8 82079738 Wdf01000!FxIoQueue::QueueRequest+0x237 (FPO:
[Non-Fpo])
09 82079738 f6453c58 80a21a49 Wdf01000!FxPkgIo::Dispatch+0x377 (FPO:
[Non-Fpo])
0a 822c3ba8 82079738 82143230 Wdf01000!FxDevice::Dispatch+0x7f (FPO:
[Non-Fpo])
0b 820797f0 82017e08 82079738 nt!IopfCallDriver+0x51 (FPO: [0,0,0])
0c 822c3ba8 82079738 82017e08 nt!IopSynchronousServiceTail+0x94 (FPO:
[Non-Fpo])
0d 00000770 0000076c 00000000 nt!IopXxxControlFile+0x64f (FPO: [Non-Fpo])
0e 00000770 0000076c 00000000 nt!NtDeviceIoControlFile+0x2a (FPO: [Non-Fpo])
0f 00000770 0000076c 00000000 nt!KiFastCallEntry+0x158 (FPO: [0,3] TrapFrame
@ f6453d64)
10 7c865aae 00000770 0000076c ntdll!KiFastSystemCallRet (FPO: [0,0,0])
11 00000770 0000076c 00000000 ntdll!ZwDeviceIoControlFile+0xc (FPO: [10,0,0])
12 00000770 0012ff30 00000000 kernel32!GetCommState+0x5a (FPO: [Non-Fpo])

After return from serial:
00 7dd3dfb0 7df90b68 00000004 Amcc5933!AmccPciEvtDeviceControl+0xf4 (FPO:
[Non-Fpo]) (CONV: stdcall) [d:\dev\sikmdf\amcc5933\sys\transfer.c @ 158]
01 7dd3dfb0 7df90b68 00000004 Wdf01000!FxIoQueueIoDeviceControl::Invoke+0x30
(FPO: [Non-Fpo])
02 7df90b68 8206f490 822c2048
Wdf01000!FxIoQueue::DispatchRequestToDriver+0x445 (FPO: [Non-Fpo])
03 822c2000 f96ab188 822c2048 Wdf01000!FxIoQueue::DispatchEvents+0x485 (FPO:
[Non-Fpo])
04 00000000 822c3ba8 82079738 Wdf01000!FxIoQueue::QueueRequest+0x237 (FPO:
[Non-Fpo])
05 82079738 f6453c58 80a21a49 Wdf01000!FxPkgIo::Dispatch+0x377 (FPO:
[Non-Fpo])
06 822c3ba8 82079738 82143230 Wdf01000!FxDevice::Dispatch+0x7f (FPO:
[Non-Fpo])
07 820797f0 82017e08 82079738 nt!IopfCallDriver+0x51 (FPO: [0,0,0])
08 822c3ba8 82079738 82017e08 nt!IopSynchronousServiceTail+0x94 (FPO:
[Non-Fpo])
09 00000770 0000076c 00000000 nt!IopXxxControlFile+0x64f (FPO: [Non-Fpo])
0a 00000770 0000076c 00000000 nt!NtDeviceIoControlFile+0x2a (FPO: [Non-Fpo])
0b 00000770 0000076c 00000000 nt!KiFastCallEntry+0x158 (FPO: [0,3] TrapFrame
@ f6453d64)
0c 7c865aae 00000770 0000076c ntdll!KiFastSystemCallRet (FPO: [0,0,0])
0d 00000770 0000076c 00000000 ntdll!ZwDeviceIoControlFile+0xc (FPO: [10,0,0])
0e 00000770 0012ff30 00000000 kernel32!GetCommState+0x5a (FPO: [Non-Fpo])

At access violation:
00 0de00e00 00000005 0000000d Wdf01000!FxIFR+0x111 (FPO: [Non-Fpo])
01 822c78b0 00000005 0000000d Wdf01000!WPP_IFR_SF_q+0x21 (FPO: [Non-Fpo])
02 7df90b68 8206f490 822c2048
Wdf01000!FxIoQueue::DispatchRequestToDriver+0x664 (FPO: [Non-Fpo])
03 822c2000 f96ab188 822c2048 Wdf01000!FxIoQueue::DispatchEvents+0x485 (FPO:
[Non-Fpo])
04 00000000 822c3ba8 82079738 Wdf01000!FxIoQueue::QueueRequest+0x237 (FPO:
[Non-Fpo])
05 82079738 f6453c58 80a21a49 Wdf01000!FxPkgIo::Dispatch+0x377 (FPO:
[Non-Fpo])
06 822c3ba8 82079738 82143230 Wdf01000!FxDevice::Dispatch+0x7f (FPO:
[Non-Fpo])
07 820797f0 82017e08 82079738 nt!IopfCallDriver+0x51 (FPO: [0,0,0])
08 822c3ba8 82079738 82017e08 nt!IopSynchronousServiceTail+0x94 (FPO:
[Non-Fpo])
09 00000770 0000076c 00000000 nt!IopXxxControlFile+0x64f (FPO: [Non-Fpo])
0a 00000770 0000076c 00000000 nt!NtDeviceIoControlFile+0x2a (FPO: [Non-Fpo])
0b 00000770 0000076c 00000000 nt!KiFastCallEntry+0x158 (FPO: [0,3] TrapFrame
@ f6453d64)
0c 7c865aae 00000770 0000076c ntdll!KiFastSystemCallRet (FPO: [0,0,0])
0d 00000770 0000076c 00000000 ntdll!ZwDeviceIoControlFile+0xc (FPO: [10,0,0])
0e 00000770 0012ff30 00000000 kernel32!GetCommState+0x5a (FPO: [Non-Fpo])


WDF log:
86: FxPkgIo::Dispatch - WDFDEVICE 0x7DD38E38 !devobj 0x822C3BA8
0x0000000e(IRP_MJ_DEVICE_CONTROL), IRP_MN 0, IRP 0x82079738
87: FxDevice::AllocateRequestMemory - Allocating FxRequest* 8206F490,
WDFREQUEST 7DF90B68
88: FxIoQueue::QueueRequest - Queuing WDFREQUEST 0x7DF90B68 on WDFQUEUE
0x7DD3DFB0
89: FxIoQueue::DispatchEvents - Thread 82143020 is processing WDFQUEUE
0x7DD3DFB0
90: FxIoQueue::DispatchRequestToDriver - Calling driver EvtIoDeviceControl
for WDFREQUEST 0x7DF90B68
91: imp_WdfRequestGetParameters - Enter: Request 7DF90B68, Parameters F6453B48
92: imp_WdfRequestFormatRequestUsingCurrentType - Enter: WDFREQUEST 7DF90B68
93: FxIoQueue::RequestCompletedCallback - Enter: WDFQUEUE 0x7DD3DFB0,
WDFREQUEST 0x7DF90B68
Unknown( 54): GUID=00000000-0000-0000-0000-000000000000 (No Format
Information found).
---- end of log ----

Re: WdfRequesSend causes WDF access violation by Eliyas

Eliyas
Thu Aug 30 07:52:42 PDT 2007

Show us the code that forwards request. Did you turn on framework verifier?

--
- This posting is provided "AS IS" with no warranties, and confers no
rights.



Re: WdfRequesSend causes WDF access violation by BobKeck

BobKeck
Thu Aug 30 08:18:03 PDT 2007

KMDF driver verifier is ON.

VOID
AmccPciEvtDeviceControl(
IN WDFQUEUE Queue,
IN WDFREQUEST Request
)
/*++

Routine Description:

Start the IRP on the device. This driver allows only one I/O to
be active on the adapter at any one time. If multiple I/Os are sent
to the driver, they will be queued and completed as they complete on
the adapter (one IRP per interrupt).

Arguments:

Queue - Default queue handle
Request - Handle to the write request
Parameters - Contains current stack location information from the
IRP

Return Value:

None

--*/
{
PAMCC_DEVICE_EXTENSION devExt;
REQUEST_CONTEXT * transfer;
NTSTATUS status;
size_t length;
WDF_DMA_DIRECTION direction;
WDFDMATRANSACTION dmaTransaction;
WDF_REQUEST_PARAMETERS params;
WDF_REQUEST_SEND_OPTIONS options;
BOOLEAN ret;

WDF_REQUEST_PARAMETERS_INIT(&params);

WdfRequestGetParameters(
Request,
&params
);

//
// Get the device extension.
//
devExt = AmccPciGetDevExt(WdfIoQueueGetDevice( Queue ));

//
// Validate and gather parameters.
//
switch (params.Type)
{
/*
case WdfRequestTypeDeviceControl:
if (params.Parameters.DeviceIoControl.IoControlCode == 1)
{
length = params.Parameters.Read.Length;
direction = WdfDmaDirectionReadFromDevice;
break;
}
*/
default:
WdfRequestFormatRequestUsingCurrentType(Request);
WDF_REQUEST_SEND_OPTIONS_INIT(&options,
WDF_REQUEST_SEND_OPTION_SEND_AND_FORGET);
TraceEvents(TRACE_LEVEL_INFORMATION, AMCC_TRACE_IO,
"Forwarding IO request at IRQL %d", KeGetCurrentIrql());

ret = WdfRequestSend(Request,
WdfDeviceGetIoTarget(WdfIoQueueGetDevice(Queue)), &options);
if (!ret)
{
status = WdfRequestGetStatus(Request);
TraceEvents(TRACE_LEVEL_WARNING, AMCC_TRACE_IO,
"Forwarding IO request failed %!STATUS!", status);
WdfRequestComplete(Request, status);
return;
}
return;
}



"Eliyas Yakub [MSFT]" wrote:

> Show us the code that forwards request. Did you turn on framework verifier?
>
> --
> - This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
>

Re: WdfRequesSend causes WDF access violation by Eliyas

Eliyas
Thu Aug 30 19:03:16 PDT 2007

The code looks right to me. What version of framework are you using? What is
the target OS? Right after you return from the ioctl handler, there is no
trace statement in the code but the stack shows the access violation in
tracing routines. That's wierd!

At access violation:
00 0de00e00 00000005 0000000d Wdf01000!FxIFR+0x111 (FPO: [Non-Fpo])
01 822c78b0 00000005 0000000d Wdf01000!WPP_IFR_SF_q+0x21 (FPO: [Non-Fpo])
02 7df90b68 8206f490 822c2048
Wdf01000!FxIoQueue::DispatchRequestToDriver+0x664 (FPO: [Non-Fpo])
03 822c2000 f96ab188 822c2048 Wdf01000!FxIoQueue::DispatchEvents+0x485 (FPO:
[Non-Fpo])

Following command will dump information about framework modules.

kd>lmvmwdf*


Right after you return from WdfRequestSend, can you dump the request object
and shows us the output? I have listed all the commands.

!wdfreqeust <request>

!wdfhandle <reqeust> <--- This will print the WDF request object pointer.

!wdfobject <object pointer>

dt FxRequest <object-pointer>


"Bob Keck" <BobKeck@discussions.microsoft.com> wrote in message
news:90AA024F-2983-4A07-9857-1A4225ABBB97@microsoft.com...
> KMDF driver verifier is ON.
>
> VOID
> AmccPciEvtDeviceControl(
> IN WDFQUEUE Queue,
> IN WDFREQUEST Request
> )
> /*++
>
> Routine Description:
>
> Start the IRP on the device. This driver allows only one I/O to
> be active on the adapter at any one time. If multiple I/Os are sent
> to the driver, they will be queued and completed as they complete on
> the adapter (one IRP per interrupt).
>
> Arguments:
>
> Queue - Default queue handle
> Request - Handle to the write request
> Parameters - Contains current stack location information from the
> IRP
>
> Return Value:
>
> None
>
> --*/
> {
> PAMCC_DEVICE_EXTENSION devExt;
> REQUEST_CONTEXT * transfer;
> NTSTATUS status;
> size_t length;
> WDF_DMA_DIRECTION direction;
> WDFDMATRANSACTION dmaTransaction;
> WDF_REQUEST_PARAMETERS params;
> WDF_REQUEST_SEND_OPTIONS options;
> BOOLEAN ret;
>
> WDF_REQUEST_PARAMETERS_INIT(&params);
>
> WdfRequestGetParameters(
> Request,
> &params
> );
>
> //
> // Get the device extension.
> //
> devExt = AmccPciGetDevExt(WdfIoQueueGetDevice( Queue ));
>
> //
> // Validate and gather parameters.
> //
> switch (params.Type)
> {
> /*
> case WdfRequestTypeDeviceControl:
> if (params.Parameters.DeviceIoControl.IoControlCode == 1)
> {
> length = params.Parameters.Read.Length;
> direction = WdfDmaDirectionReadFromDevice;
> break;
> }
> */
> default:
> WdfRequestFormatRequestUsingCurrentType(Request);
> WDF_REQUEST_SEND_OPTIONS_INIT(&options,
> WDF_REQUEST_SEND_OPTION_SEND_AND_FORGET);
> TraceEvents(TRACE_LEVEL_INFORMATION, AMCC_TRACE_IO,
> "Forwarding IO request at IRQL %d", KeGetCurrentIrql());
>
> ret = WdfRequestSend(Request,
> WdfDeviceGetIoTarget(WdfIoQueueGetDevice(Queue)), &options);
> if (!ret)
> {
> status = WdfRequestGetStatus(Request);
> TraceEvents(TRACE_LEVEL_WARNING, AMCC_TRACE_IO,
> "Forwarding IO request failed %!STATUS!", status);
> WdfRequestComplete(Request, status);
> return;
> }
> return;
> }
>
>
>
> "Eliyas Yakub [MSFT]" wrote:
>
>> Show us the code that forwards request. Did you turn on framework
>> verifier?
>>
>> --
>> - This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>>


Re: WdfRequesSend causes WDF access violation by BobKeck

BobKeck
Fri Aug 31 08:58:03 PDT 2007

The target machine is Windows XP SP2. I am nominally using framework version
1.5 (from DDK 6000). The information you requested follows:

kd> lmvmwdf*
start end module name
f9642000 f96bd000 Wdf01000 (deferred)
Image path: Wdf01000.sys
Image name: Wdf01000.sys
Timestamp: Thu Nov 02 04:54:18 2006 (4549B23A)
CheckSum: 00086DA0
ImageSize: 0007B000
Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0
f9ba2000 f9baf000 WDFLDR (deferred)
Image path: WDFLDR.SYS
Image name: WDFLDR.SYS
Timestamp: Thu Nov 02 04:54:05 2006 (4549B22D)
CheckSum: 00011D7F
ImageSize: 0000D000
File version: 1.5.6000.0
Product version: 1.5.6000.0
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 3.7 Driver
File date: 00000000.00000000
Translations: 0000.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft® Windows® Operating System
InternalName: wdfldr.sys
OriginalFilename: wdfldr.sys
ProductVersion: 1.5.6000.0
FileVersion: 1.5.6000.0 (vista_rtm.061101-2205)
FileDescription: WDFLDR
LegalCopyright: © Microsoft Corporation. All rights reserved.


Breakpoint 1 hit
Amcc5933!AmccPciEvtDeviceControl+0xf7:
f9b940e7 0fb64dc3 movzx ecx,byte ptr [ebp-3Dh]


kd> !wdfrequest 7dfb3fb0
!IRP 0x00000000
irp is NULL, the remaining results may not be correct...
!WDFQUEUE 0x7dd3a8b0
State: Pending, Allocated by WDF for incoming IRP


kd> !wdfhandle 7dfb3fb0

Dumping WDFHANDLE 0x7dfb3fb0
=============================
Handle type is WDFREQUEST
Refcount: 1
Contexts:
<no associated contexts or attribute callbacks>

!wdfobject 0x8204c048


kd> !wdfobject 8204c048

The type for object 0x8204c048 is FxRequest
State: FxObjectStateDeletedAndDisposed (0xa)
!wdfhandle 0x7dfb3fb0

dt FxRequest 0x8204c048

Contexts:
<no associated contexts or attribute callbacks>

Object debug extension 8204c030
*** WARNING: Unable to verify checksum for siccdtest.exe
*** ERROR: Module load completed but symbols could not be loaded for
siccdtest.exe
*** WARNING: Unable to verify timestamp for rpc_client.dll
*** ERROR: Module load completed but symbols could not be loaded for
rpc_client.dll
*** WARNING: Unable to verify timestamp for dpcdll.dll
*** ERROR: Module load completed but symbols could not be loaded for
dpcdll.dll
*** WARNING: Unable to verify timestamp for wuaueng.dll
*** ERROR: Module load completed but symbols could not be loaded for
wuaueng.dll
*** WARNING: Unable to verify timestamp for wuapi.dll
*** ERROR: Module load completed but symbols could not be loaded for wuapi.dll
*** WARNING: Unable to verify timestamp for licdll.dll
*** ERROR: Module load completed but symbols could not be loaded for
licdll.dll
*** WARNING: Unable to verify timestamp for licwmi.dll
*** ERROR: Module load completed but symbols could not be loaded for
licwmi.dll
*** WARNING: Unable to verify timestamp for mscordbi.dll
*** ERROR: Module load completed but symbols could not be loaded for
mscordbi.dll
*** WARNING: Unable to verify timestamp for mscoree.dll
*** ERROR: Module load completed but symbols could not be loaded for
mscoree.dll
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command 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: FxObjectDebugExtensionValues ***
*** ***
*************************************************************************
Extension signature incorrect...expected 0x0, got 0x444f7846
Verifier lock 0x8202cda0


kd> dt FxRequest 8204c048
Wdf01000!FxRequest
+0x000 __VFN_table : 0xf96aa1f4
+0x004 m_Type : 0x1008
+0x006 m_ObjectSize : 0xa0
+0x008 m_Refcnt : 1
+0x00c m_Globals : 0x822c5e80 _FX_DRIVER_GLOBALS
+0x010 m_ObjectFlags : 0x18c
+0x010 m_ObjectFlagsByName : FxObject::<unnamed-tag>::<unnamed-tag>
+0x012 m_ObjectState : 0xa
+0x014 m_ChildListHead : _LIST_ENTRY [ 0x8204c05c - 0x8204c05c ]
+0x01c m_SpinLock : 0
+0x020 m_ParentObject : (null)
+0x024 m_ChildEntry : _LIST_ENTRY [ 0x8204c06c - 0x8204c06c ]
+0x02c m_DisposeSingleEntry : _SINGLE_LIST_ENTRY
+0x030 m_NPLock : 0
+0x034 m_CsqContext : _IO_CSQ_IRP_CONTEXT
+0x034 m_ListEntry : _LIST_ENTRY [ 0x1 - 0x0 ]
+0x040 m_DrainSingleEntry : _SINGLE_LIST_ENTRY
+0x040 m_NextStackLocationFormatted : 0x1 ''
+0x044 m_Irp : FxIrp
+0x048 m_Target : (null)
+0x04c m_RequestContext : (null)
+0x050 m_Timer : (null)
+0x054 m_CancelAndCompletion : FxRequestCancelAndCompletion
+0x058 m_TargetCompletionContext : (null)
+0x05c m_IrpCompletionReferenceCount : 0
+0x060 m_TargetFlags : 0 ''
+0x060 m_TargetFlagsByName : FxRequestBase::<unnamed-tag>::<unnamed-tag>
+0x061 m_IrpAllocation : 0 ''
+0x062 m_Completed : 0 ''
+0x063 m_Canceled : 0 ''
+0x064 m_IrpReferenceCount : 0
+0x068 m_SystemBufferOffset : 0x68
+0x06a m_VerifierFlags : 136
+0x06a m_VeriferFlagsByName : FxRequestBase::<unnamed-tag>::<unnamed-tag>
+0x06c m_IrpQueue : (null)
+0x070 m_OutputBufferOffset : 0x70
+0x072 m_RequestBaseFlags : 0 ''
+0x072 m_RequestBaseFlagsByName :
FxRequestBase::<unnamed-tag>::<unnamed-tag>
+0x073 m_CompletionState : 0 ''
+0x074 m_AllocatedMdl : (null)
+0x078 m_IoQueue : 0x822c5748 FxIoQueue
+0x078 m_DeviceToFreeTo : 0x822c5748 FxDevice
+0x07c m_SystemBuffer : FxRequestSystemBuffer
+0x084 m_OutputBuffer : FxRequestOutputBuffer
+0x08c m_OwnerListEntry : _LIST_ENTRY [ 0x8204c0d4 - 0x8204c0d4 ]
+0x094 m_OwnerListEntry2 : _LIST_ENTRY [ 0x822c3530 - 0x822c3530 ]
+0x09c m_Presented : 0x1 ''
+0x09d m_PowerStopState : 0 ''



"Eliyas Yakub [MSFT]" wrote:

> The code looks right to me. What version of framework are you using? What is
> the target OS? Right after you return from the ioctl handler, there is no
> trace statement in the code but the stack shows the access violation in
> tracing routines. That's wierd!
>
> At access violation:
> 00 0de00e00 00000005 0000000d Wdf01000!FxIFR+0x111 (FPO: [Non-Fpo])
> 01 822c78b0 00000005 0000000d Wdf01000!WPP_IFR_SF_q+0x21 (FPO: [Non-Fpo])
> 02 7df90b68 8206f490 822c2048
> Wdf01000!FxIoQueue::DispatchRequestToDriver+0x664 (FPO: [Non-Fpo])
> 03 822c2000 f96ab188 822c2048 Wdf01000!FxIoQueue::DispatchEvents+0x485 (FPO:
> [Non-Fpo])
>
> Following command will dump information about framework modules.
>
> kd>lmvmwdf*
>
>
> Right after you return from WdfRequestSend, can you dump the request object
> and shows us the output? I have listed all the commands.
>
> !wdfreqeust <request>
>
> !wdfhandle <reqeust> <--- This will print the WDF request object pointer.
>
> !wdfobject <object pointer>
>
> dt FxRequest <object-pointer>
>
>
> "Bob Keck" <BobKeck@discussions.microsoft.com> wrote in message
> news:90AA024F-2983-4A07-9857-1A4225ABBB97@microsoft.com...
> > KMDF driver verifier is ON.
> >
> > VOID
> > AmccPciEvtDeviceControl(
> > IN WDFQUEUE Queue,
> > IN WDFREQUEST Request
> > )
> > /*++
> >
> > Routine Description:
> >
> > Start the IRP on the device. This driver allows only one I/O to
> > be active on the adapter at any one time. If multiple I/Os are sent
> > to the driver, they will be queued and completed as they complete on
> > the adapter (one IRP per interrupt).
> >
> > Arguments:
> >
> > Queue - Default queue handle
> > Request - Handle to the write request
> > Parameters - Contains current stack location information from the
> > IRP
> >
> > Return Value:
> >
> > None
> >
> > --*/
> > {
> > PAMCC_DEVICE_EXTENSION devExt;
> > REQUEST_CONTEXT * transfer;
> > NTSTATUS status;
> > size_t length;
> > WDF_DMA_DIRECTION direction;
> > WDFDMATRANSACTION dmaTransaction;
> > WDF_REQUEST_PARAMETERS params;
> > WDF_REQUEST_SEND_OPTIONS options;
> > BOOLEAN ret;
> >
> > WDF_REQUEST_PARAMETERS_INIT(¶ms);
> >
> > WdfRequestGetParameters(
> > Request,
> > ¶ms
> > );
> >
> > //
> > // Get the device extension.
> > //
> > devExt = AmccPciGetDevExt(WdfIoQueueGetDevice( Queue ));
> >
> > //
> > // Validate and gather parameters.
> > //
> > switch (params.Type)
> > {
> > /*
> > case WdfRequestTypeDeviceControl:
> > if (params.Parameters.DeviceIoControl.IoControlCode == 1)
> > {
> > length = params.Parameters.Read.Length;
> > direction = WdfDmaDirectionReadFromDevice;
> > break;
> > }
> > */
> > default:
> > WdfRequestFormatRequestUsingCurrentType(Request);
> > WDF_REQUEST_SEND_OPTIONS_INIT(&options,
> > WDF_REQUEST_SEND_OPTION_SEND_AND_FORGET);
> > TraceEvents(TRACE_LEVEL_INFORMATION, AMCC_TRACE_IO,
> > "Forwarding IO request at IRQL %d", KeGetCurrentIrql());
> >
> > ret = WdfRequestSend(Request,
> > WdfDeviceGetIoTarget(WdfIoQueueGetDevice(Queue)), &options);
> > if (!ret)
> > {
> > status = WdfRequestGetStatus(Request);
> > TraceEvents(TRACE_LEVEL_WARNING, AMCC_TRACE_IO,
> > "Forwarding IO request failed %!STATUS!", status);
> > WdfRequestComplete(Request, status);
> > return;
> > }
> > return;
> > }
> >
> >
> >
> > "Eliyas Yakub [MSFT]" wrote:
> >
> >> Show us the code that forwards request. Did you turn on framework
> >> verifier?
> >>
> >> --
> >> - This posting is provided "AS IS" with no warranties, and confers no
> >> rights.
> >>
> >>
> >>
>

Re: WdfRequesSend causes WDF access violation by Eliyas

Eliyas
Fri Aug 31 11:49:58 PDT 2007

State of the request object looks good. So it doesn't seem like the
framework is touching an invalid object. Can you turn off verbose tracing
iin the registry and try again?

-Eliyas

"Bob Keck" <BobKeck@discussions.microsoft.com> wrote in message
news:9FF3456D-10CC-48A4-9C21-0E2D14ADBEDF@microsoft.com...
> The target machine is Windows XP SP2. I am nominally using framework
> version
> 1.5 (from DDK 6000). The information you requested follows:
>
> kd> lmvmwdf*
> start end module name
> f9642000 f96bd000 Wdf01000 (deferred)
> Image path: Wdf01000.sys
> Image name: Wdf01000.sys
> Timestamp: Thu Nov 02 04:54:18 2006 (4549B23A)
> CheckSum: 00086DA0
> ImageSize: 0007B000
> Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0
> f9ba2000 f9baf000 WDFLDR (deferred)
> Image path: WDFLDR.SYS
> Image name: WDFLDR.SYS
> Timestamp: Thu Nov 02 04:54:05 2006 (4549B22D)
> CheckSum: 00011D7F
> ImageSize: 0000D000
> File version: 1.5.6000.0
> Product version: 1.5.6000.0
> File flags: 0 (Mask 3F)
> File OS: 40004 NT Win32
> File type: 3.7 Driver
> File date: 00000000.00000000
> Translations: 0000.04b0
> CompanyName: Microsoft Corporation
> ProductName: Microsoft® Windows® Operating System
> InternalName: wdfldr.sys
> OriginalFilename: wdfldr.sys
> ProductVersion: 1.5.6000.0
> FileVersion: 1.5.6000.0 (vista_rtm.061101-2205)
> FileDescription: WDFLDR
> LegalCopyright: © Microsoft Corporation. All rights reserved.
>
>
> Breakpoint 1 hit
> Amcc5933!AmccPciEvtDeviceControl+0xf7:
> f9b940e7 0fb64dc3 movzx ecx,byte ptr [ebp-3Dh]
>
>
> kd> !wdfrequest 7dfb3fb0
> !IRP 0x00000000
> irp is NULL, the remaining results may not be correct...
> !WDFQUEUE 0x7dd3a8b0
> State: Pending, Allocated by WDF for incoming IRP
>
>
> kd> !wdfhandle 7dfb3fb0
>
> Dumping WDFHANDLE 0x7dfb3fb0
> =============================
> Handle type is WDFREQUEST
> Refcount: 1
> Contexts:
> <no associated contexts or attribute callbacks>
>
> !wdfobject 0x8204c048
>
>
> kd> !wdfobject 8204c048
>
> The type for object 0x8204c048 is FxRequest
> State: FxObjectStateDeletedAndDisposed (0xa)
> !wdfhandle 0x7dfb3fb0
>
> dt FxRequest 0x8204c048
>
> Contexts:
> <no associated contexts or attribute callbacks>
>
> Object debug extension 8204c030
> *** WARNING: Unable to verify checksum for siccdtest.exe
> *** ERROR: Module load completed but symbols could not be loaded for
> siccdtest.exe
> *** WARNING: Unable to verify timestamp for rpc_client.dll
> *** ERROR: Module load completed but symbols could not be loaded for
> rpc_client.dll
> *** WARNING: Unable to verify timestamp for dpcdll.dll
> *** ERROR: Module load completed but symbols could not be loaded for
> dpcdll.dll
> *** WARNING: Unable to verify timestamp for wuaueng.dll
> *** ERROR: Module load completed but symbols could not be loaded for
> wuaueng.dll
> *** WARNING: Unable to verify timestamp for wuapi.dll
> *** ERROR: Module load completed but symbols could not be loaded for
> wuapi.dll
> *** WARNING: Unable to verify timestamp for licdll.dll
> *** ERROR: Module load completed but symbols could not be loaded for
> licdll.dll
> *** WARNING: Unable to verify timestamp for licwmi.dll
> *** ERROR: Module load completed but symbols could not be loaded for
> licwmi.dll
> *** WARNING: Unable to verify timestamp for mscordbi.dll
> *** ERROR: Module load completed but symbols could not be loaded for
> mscordbi.dll
> *** WARNING: Unable to verify timestamp for mscoree.dll
> *** ERROR: Module load completed but symbols could not be loaded for
> mscoree.dll
> *************************************************************************
> *** ***
> *** ***
> *** Your debugger is not using the correct symbols ***
> *** ***
> *** In order for this command 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: FxObjectDebugExtensionValues ***
> *** ***
> *************************************************************************
> Extension signature incorrect...expected 0x0, got 0x444f7846
> Verifier lock 0x8202cda0
>
>
> kd> dt FxRequest 8204c048
> Wdf01000!FxRequest
> +0x000 __VFN_table : 0xf96aa1f4
> +0x004 m_Type : 0x1008
> +0x006 m_ObjectSize : 0xa0
> +0x008 m_Refcnt : 1
> +0x00c m_Globals : 0x822c5e80 _FX_DRIVER_GLOBALS
> +0x010 m_ObjectFlags : 0x18c
> +0x010 m_ObjectFlagsByName : FxObject::<unnamed-tag>::<unnamed-tag>
> +0x012 m_ObjectState : 0xa
> +0x014 m_ChildListHead : _LIST_ENTRY [ 0x8204c05c - 0x8204c05c ]
> +0x01c m_SpinLock : 0
> +0x020 m_ParentObject : (null)
> +0x024 m_ChildEntry : _LIST_ENTRY [ 0x8204c06c - 0x8204c06c ]
> +0x02c m_DisposeSingleEntry : _SINGLE_LIST_ENTRY
> +0x030 m_NPLock : 0
> +0x034 m_CsqContext : _IO_CSQ_IRP_CONTEXT
> +0x034 m_ListEntry : _LIST_ENTRY [ 0x1 - 0x0 ]
> +0x040 m_DrainSingleEntry : _SINGLE_LIST_ENTRY
> +0x040 m_NextStackLocationFormatted : 0x1 ''
> +0x044 m_Irp : FxIrp
> +0x048 m_Target : (null)
> +0x04c m_RequestContext : (null)
> +0x050 m_Timer : (null)
> +0x054 m_CancelAndCompletion : FxRequestCancelAndCompletion
> +0x058 m_TargetCompletionContext : (null)
> +0x05c m_IrpCompletionReferenceCount : 0
> +0x060 m_TargetFlags : 0 ''
> +0x060 m_TargetFlagsByName : FxRequestBase::<unnamed-tag>::<unnamed-tag>
> +0x061 m_IrpAllocation : 0 ''
> +0x062 m_Completed : 0 ''
> +0x063 m_Canceled : 0 ''
> +0x064 m_IrpReferenceCount : 0
> +0x068 m_SystemBufferOffset : 0x68
> +0x06a m_VerifierFlags : 136
> +0x06a m_VeriferFlagsByName :
> FxRequestBase::<unnamed-tag>::<unnamed-tag>
> +0x06c m_IrpQueue : (null)
> +0x070 m_OutputBufferOffset : 0x70
> +0x072 m_RequestBaseFlags : 0 ''
> +0x072 m_RequestBaseFlagsByName :
> FxRequestBase::<unnamed-tag>::<unnamed-tag>
> +0x073 m_CompletionState : 0 ''
> +0x074 m_AllocatedMdl : (null)
> +0x078 m_IoQueue : 0x822c5748 FxIoQueue
> +0x078 m_DeviceToFreeTo : 0x822c5748 FxDevice
> +0x07c m_SystemBuffer : FxRequestSystemBuffer
> +0x084 m_OutputBuffer : FxRequestOutputBuffer
> +0x08c m_OwnerListEntry : _LIST_ENTRY [ 0x8204c0d4 - 0x8204c0d4 ]
> +0x094 m_OwnerListEntry2 : _LIST_ENTRY [ 0x822c3530 - 0x822c3530 ]
> +0x09c m_Presented : 0x1 ''
> +0x09d m_PowerStopState : 0 ''
>
>
>
> "Eliyas Yakub [MSFT]" wrote:
>
>> The code looks right to me. What version of framework are you using? What
>> is
>> the target OS? Right after you return from the ioctl handler, there is no
>> trace statement in the code but the stack shows the access violation in
>> tracing routines. That's wierd!
>>
>> At access violation:
>> 00 0de00e00 00000005 0000000d Wdf01000!FxIFR+0x111 (FPO: [Non-Fpo])
>> 01 822c78b0 00000005 0000000d Wdf01000!WPP_IFR_SF_q+0x21 (FPO: [Non-Fpo])
>> 02 7df90b68 8206f490 822c2048
>> Wdf01000!FxIoQueue::DispatchRequestToDriver+0x664 (FPO: [Non-Fpo])
>> 03 822c2000 f96ab188 822c2048 Wdf01000!FxIoQueue::DispatchEvents+0x485
>> (FPO:
>> [Non-Fpo])
>>
>> Following command will dump information about framework modules.
>>
>> kd>lmvmwdf*
>>
>>
>> Right after you return from WdfRequestSend, can you dump the request
>> object
>> and shows us the output? I have listed all the commands.
>>
>> !wdfreqeust <request>
>>
>> !wdfhandle <reqeust> <--- This will print the WDF request object pointer.
>>
>> !wdfobject <object pointer>
>>
>> dt FxRequest <object-pointer>
>>
>>
>> "Bob Keck" <BobKeck@discussions.microsoft.com> wrote in message
>> news:90AA024F-2983-4A07-9857-1A4225ABBB97@microsoft.com...
>> > KMDF driver verifier is ON.
>> >
>> > VOID
>> > AmccPciEvtDeviceControl(
>> > IN WDFQUEUE Queue,
>> > IN WDFREQUEST Request
>> > )
>> > /*++
>> >
>> > Routine Description:
>> >
>> > Start the IRP on the device. This driver allows only one I/O to
>> > be active on the adapter at any one time. If multiple I/Os are sent
>> > to the driver, they will be queued and completed as they complete on
>> > the adapter (one IRP per interrupt).
>> >
>> > Arguments:
>> >
>> > Queue - Default queue handle
>> > Request - Handle to the write request
>> > Parameters - Contains current stack location information from the
>> > IRP
>> >
>> > Return Value:
>> >
>> > None
>> >
>> > --*/
>> > {
>> > PAMCC_DEVICE_EXTENSION devExt;
>> > REQUEST_CONTEXT * transfer;
>> > NTSTATUS status;
>> > size_t length;
>> > WDF_DMA_DIRECTION direction;
>> > WDFDMATRANSACTION dmaTransaction;
>> > WDF_REQUEST_PARAMETERS params;
>> > WDF_REQUEST_SEND_OPTIONS options;
>> > BOOLEAN ret;
>> >
>> > WDF_REQUEST_PARAMETERS_INIT(¶ms);
>> >
>> > WdfRequestGetParameters(
>> > Request,
>> > ¶ms
>> > );
>> >
>> > //
>> > // Get the device extension.
>> > //
>> > devExt = AmccPciGetDevExt(WdfIoQueueGetDevice( Queue ));
>> >
>> > //
>> > // Validate and gather parameters.
>> > //
>> > switch (params.Type)
>> > {
>> > /*
>> > case WdfRequestTypeDeviceControl:
>> > if (params.Parameters.DeviceIoControl.IoControlCode == 1)
>> > {
>> > length = params.Parameters.Read.Length;
>> > direction = WdfDmaDirectionReadFromDevice;
>> > break;
>> > }
>> > */
>> > default:
>> > WdfRequestFormatRequestUsingCurrentType(Request);
>> > WDF_REQUEST_SEND_OPTIONS_INIT(&options,
>> > WDF_REQUEST_SEND_OPTION_SEND_AND_FORGET);
>> > TraceEvents(TRACE_LEVEL_INFORMATION, AMCC_TRACE_IO,
>> > "Forwarding IO request at IRQL %d", KeGetCurrentIrql());
>> >
>> > ret = WdfRequestSend(Request,
>> > WdfDeviceGetIoTarget(WdfIoQueueGetDevice(Queue)), &options);
>> > if (!ret)
>> > {
>> > status = WdfRequestGetStatus(Request);
>> > TraceEvents(TRACE_LEVEL_WARNING, AMCC_TRACE_IO,
>> > "Forwarding IO request failed %!STATUS!", status);
>> > WdfRequestComplete(Request, status);
>> > return;
>> > }
>> > return;
>> > }
>> >
>> >
>> >
>> > "Eliyas Yakub [MSFT]" wrote:
>> >
>> >> Show us the code that forwards request. Did you turn on framework
>> >> verifier?
>> >>
>> >> --
>> >> - This posting is provided "AS IS" with no warranties, and confers no
>> >> rights.
>> >>
>> >>
>> >>
>>


Re: WdfRequesSend causes WDF access violation by BobKeck

BobKeck
Tue Sep 04 05:58:05 PDT 2007

Turning off verbose tracing fixes the problem. Thank you for finding at least
a work around
for the problem.

"Eliyas Yakub [MSFT]" wrote:

> State of the request object looks good. So it doesn't seem like the
> framework is touching an invalid object. Can you turn off verbose tracing
> iin the registry and try again?
>
> -Eliyas
>
> "Bob Keck" <BobKeck@discussions.microsoft.com> wrote in message
> news:9FF3456D-10CC-48A4-9C21-0E2D14ADBEDF@microsoft.com...
> > The target machine is Windows XP SP2. I am nominally using framework
> > version
> > 1.5 (from DDK 6000). The information you requested follows:
> >
> > kd> lmvmwdf*
> > start end module name
> > f9642000 f96bd000 Wdf01000 (deferred)
> > Image path: Wdf01000.sys
> > Image name: Wdf01000.sys
> > Timestamp: Thu Nov 02 04:54:18 2006 (4549B23A)
> > CheckSum: 00086DA0
> > ImageSize: 0007B000
> > Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0
> > f9ba2000 f9baf000 WDFLDR (deferred)
> > Image path: WDFLDR.SYS
> > Image name: WDFLDR.SYS
> > Timestamp: Thu Nov 02 04:54:05 2006 (4549B22D)
> > CheckSum: 00011D7F
> > ImageSize: 0000D000
> > File version: 1.5.6000.0
> > Product version: 1.5.6000.0
> > File flags: 0 (Mask 3F)
> > File OS: 40004 NT Win32
> > File type: 3.7 Driver
> > File date: 00000000.00000000
> > Translations: 0000.04b0
> > CompanyName: Microsoft Corporation
> > ProductName: Microsoft® Windows® Operating System
> > InternalName: wdfldr.sys
> > OriginalFilename: wdfldr.sys
> > ProductVersion: 1.5.6000.0
> > FileVersion: 1.5.6000.0 (vista_rtm.061101-2205)
> > FileDescription: WDFLDR
> > LegalCopyright: © Microsoft Corporation. All rights reserved.
> >
> >
> > Breakpoint 1 hit
> > Amcc5933!AmccPciEvtDeviceControl+0xf7:
> > f9b940e7 0fb64dc3 movzx ecx,byte ptr [ebp-3Dh]
> >
> >
> > kd> !wdfrequest 7dfb3fb0
> > !IRP 0x00000000
> > irp is NULL, the remaining results may not be correct...
> > !WDFQUEUE 0x7dd3a8b0
> > State: Pending, Allocated by WDF for incoming IRP
> >
> >
> > kd> !wdfhandle 7dfb3fb0
> >
> > Dumping WDFHANDLE 0x7dfb3fb0
> > =============================
> > Handle type is WDFREQUEST
> > Refcount: 1
> > Contexts:
> > <no associated contexts or attribute callbacks>
> >
> > !wdfobject 0x8204c048
> >
> >
> > kd> !wdfobject 8204c048
> >
> > The type for object 0x8204c048 is FxRequest
> > State: FxObjectStateDeletedAndDisposed (0xa)
> > !wdfhandle 0x7dfb3fb0
> >
> > dt FxRequest 0x8204c048
> >
> > Contexts:
> > <no associated contexts or attribute callbacks>
> >
> > Object debug extension 8204c030
> > *** WARNING: Unable to verify checksum for siccdtest.exe
> > *** ERROR: Module load completed but symbols could not be loaded for
> > siccdtest.exe
> > *** WARNING: Unable to verify timestamp for rpc_client.dll
> > *** ERROR: Module load completed but symbols could not be loaded for
> > rpc_client.dll
> > *** WARNING: Unable to verify timestamp for dpcdll.dll
> > *** ERROR: Module load completed but symbols could not be loaded for
> > dpcdll.dll
> > *** WARNING: Unable to verify timestamp for wuaueng.dll
> > *** ERROR: Module load completed but symbols could not be loaded for
> > wuaueng.dll
> > *** WARNING: Unable to verify timestamp for wuapi.dll
> > *** ERROR: Module load completed but symbols could not be loaded for
> > wuapi.dll
> > *** WARNING: Unable to verify timestamp for licdll.dll
> > *** ERROR: Module load completed but symbols could not be loaded for
> > licdll.dll
> > *** WARNING: Unable to verify timestamp for licwmi.dll
> > *** ERROR: Module load completed but symbols could not be loaded for
> > licwmi.dll
> > *** WARNING: Unable to verify timestamp for mscordbi.dll
> > *** ERROR: Module load completed but symbols could not be loaded for
> > mscordbi.dll
> > *** WARNING: Unable to verify timestamp for mscoree.dll
> > *** ERROR: Module load completed but symbols could not be loaded for
> > mscoree.dll
> > *************************************************************************
> > *** ***
> > *** ***
> > *** Your debugger is not using the correct symbols ***
> > *** ***
> > *** In order for this command 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: FxObjectDebugExtensionValues ***
> > *** ***
> > *************************************************************************
> > Extension signature incorrect...expected 0x0, got 0x444f7846
> > Verifier lock 0x8202cda0
> >
> >
> > kd> dt FxRequest 8204c048
> > Wdf01000!FxRequest
> > +0x000 __VFN_table : 0xf96aa1f4
> > +0x004 m_Type : 0x1008
> > +0x006 m_ObjectSize : 0xa0
> > +0x008 m_Refcnt : 1
> > +0x00c m_Globals : 0x822c5e80 _FX_DRIVER_GLOBALS
> > +0x010 m_ObjectFlags : 0x18c
> > +0x010 m_ObjectFlagsByName : FxObject::<unnamed-tag>::<unnamed-tag>
> > +0x012 m_ObjectState : 0xa
> > +0x014 m_ChildListHead : _LIST_ENTRY [ 0x8204c05c - 0x8204c05c ]
> > +0x01c m_SpinLock : 0
> > +0x020 m_ParentObject : (null)
> > +0x024 m_ChildEntry : _LIST_ENTRY [ 0x8204c06c - 0x8204c06c ]
> > +0x02c m_DisposeSingleEntry : _SINGLE_LIST_ENTRY
> > +0x030 m_NPLock : 0
> > +0x034 m_CsqContext : _IO_CSQ_IRP_CONTEXT
> > +0x034 m_ListEntry : _LIST_ENTRY [ 0x1 - 0x0 ]
> > +0x040 m_DrainSingleEntry : _SINGLE_LIST_ENTRY
> > +0x040 m_NextStackLocationFormatted : 0x1 ''
> > +0x044 m_Irp : FxIrp
> > +0x048 m_Target : (null)
> > +0x04c m_RequestContext : (null)
> > +0x050 m_Timer : (null)
> > +0x054 m_CancelAndCompletion : FxRequestCancelAndCompletion
> > +0x058 m_TargetCompletionContext : (null)
> > +0x05c m_IrpCompletionReferenceCount : 0
> > +0x060 m_TargetFlags : 0 ''
> > +0x060 m_TargetFlagsByName : FxRequestBase::<unnamed-tag>::<unnamed-tag>
> > +0x061 m_IrpAllocation : 0 ''
> > +0x062 m_Completed : 0 ''
> > +0x063 m_Canceled : 0 ''
> > +0x064 m_IrpReferenceCount : 0
> > +0x068 m_SystemBufferOffset : 0x68
> > +0x06a m_VerifierFlags : 136
> > +0x06a m_VeriferFlagsByName :
> > FxRequestBase::<unnamed-tag>::<unnamed-tag>
> > +0x06c m_IrpQueue : (null)
> > +0x070 m_OutputBufferOffset : 0x70
> > +0x072 m_RequestBaseFlags : 0 ''
> > +0x072 m_RequestBaseFlagsByName :
> > FxRequestBase::<unnamed-tag>::<unnamed-tag>
> > +0x073 m_CompletionState : 0 ''
> > +0x074 m_AllocatedMdl : (null)
> > +0x078 m_IoQueue : 0x822c5748 FxIoQueue
> > +0x078 m_DeviceToFreeTo : 0x822c5748 FxDevice
> > +0x07c m_SystemBuffer : FxRequestSystemBuffer
> > +0x084 m_OutputBuffer : FxRequestOutputBuffer
> > +0x08c m_OwnerListEntry : _LIST_ENTRY [ 0x8204c0d4 - 0x8204c0d4 ]
> > +0x094 m_OwnerListEntry2 : _LIST_ENTRY [ 0x822c3530 - 0x822c3530 ]
> > +0x09c m_Presented : 0x1 ''
> > +0x09d m_PowerStopState : 0 ''
> >
> >
> >
> > "Eliyas Yakub [MSFT]" wrote:
> >
> >> The code looks right to me. What version of framework are you using? What
> >> is
> >> the target OS? Right after you return from the ioctl handler, there is no
> >> trace statement in the code but the stack shows the access violation in
> >> tracing routines. That's wierd!
> >>
> >> At access violation:
> >> 00 0de00e00 00000005 0000000d Wdf01000!FxIFR+0x111 (FPO: [Non-Fpo])
> >> 01 822c78b0 00000005 0000000d Wdf01000!WPP_IFR_SF_q+0x21 (FPO: [Non-Fpo])
> >> 02 7df90b68 8206f490 822c2048
> >> Wdf01000!FxIoQueue::DispatchRequestToDriver+0x664 (FPO: [Non-Fpo])
> >> 03 822c2000 f96ab188 822c2048 Wdf01000!FxIoQueue::DispatchEvents+0x485
> >> (FPO:
> >> [Non-Fpo])
> >>
> >> Following command will dump information about framework modules.
> >>
> >> kd>lmvmwdf*
> >>
> >>
> >> Right after you return from WdfRequestSend, can you dump the request
> >> object
> >> and shows us the output? I have listed all the commands.
> >>
> >> !wdfreqeust <request>
> >>
> >> !wdfhandle <reqeust> <--- This will print the WDF request object pointer.
> >>
> >> !wdfobject <object pointer>
> >>
> >> dt FxRequest <object-pointer>
> >>
> >>
> >> "Bob Keck" <BobKeck@discussions.microsoft.com> wrote in message
> >> news:90AA024F-2983-4A07-9857-1A4225ABBB97@microsoft.com...
> >> > KMDF driver verifier is ON.
> >> >
> >> > VOID
> >> > AmccPciEvtDeviceControl(
> >> > IN WDFQUEUE Queue,
> >> > IN WDFREQUEST Request
> >> > )
> >> > /*++
> >> >
> >> > Routine Description:
> >> >
> >> > Start the IRP on the device. This driver allows only one I/O to
> >> > be active on the adapter at any one time. If multiple I/Os are sent
> >> > to the driver, they will be queued and completed as they complete on
> >> > the adapter (one IRP per interrupt).
> >> >
> >> > Arguments:
> >> >
> >> > Queue - Default queue handle
> >> > Request - Handle to the write request
> >> > Parameters - Contains current stack location information from the
> >> > IRP
> >> >
> >> > Return Value:
> >> >
> >> > None
> >> >
> >> > --*/
> >> > {
> >> > PAMCC_DEVICE_EXTENSION devExt;
> >> > REQUEST_CONTEXT * transfer;
> >> > NTSTATUS status;
> >> > size_t length;
> >> > WDF_DMA_DIRECTION direction;
> >> > WDFDMATRANSACTION dmaTransaction;
> >> > WDF_REQUEST_PARAMETERS params;
> >> > WDF_REQUEST_SEND_OPTIONS options;
> >> > BOOLEAN ret;
> >> >
> >> > WDF_REQUEST_PARAMETERS_INIT(¶ms);
> >> >
> >> > WdfRequestGetParameters(
> >> > Request,
> >> > ¶ms
> >> > );
> >> >
> >> > //
> >> > // Get the device extension.
> >> > //
> >> > devExt = AmccPciGetDevExt(WdfIoQueueGetDevice( Queue ));
> >> >
> >> > //
> >> > // Validate and gather parameters.
> >> > //
> >> > switch (params.Type)
> >> > {
> >> > /*
> >> > case WdfRequestTypeDeviceControl:
> >> > if (params.Parameters.DeviceIoControl.IoControlCode == 1)
> >> > {
> >> > length = params.Parameters.Read.Length;
> >> > direction = WdfDmaDirectionReadFromDevice;
> >> > break;
> >> > }
> >> > */
> >> > default:
> >> > WdfRequestFormatRequestUsingCurrentType(Request);
> >> > WDF_REQUEST_SEND_OPTIONS_INIT(&options,
> >> > WDF_REQUEST_SEND_OPTION_SEND_AND_FORGET);
> >> > TraceEvents(TRACE_LEVEL_INFORMATION, AMCC_TRACE_IO,
> >> > "Forwarding IO request at IRQL %d", KeGetCurrentIrql());
> >> >
> >> > ret = WdfRequestSend(Request,
> >> > WdfDeviceGetIoTarget(WdfIoQueueGetDevice(Queue)), &options);
> >> > if (!ret)
> >> > {
> >> > status = WdfRequestGetStatus(Request);
> >> > TraceEvents(TRACE_LEVEL_WARNING, AMCC_TRACE_IO,
> >> > "Forwarding IO request failed %!STATUS!", status);
> >> > WdfRequestComplete(Request, status);
> >> > return;

Re: WdfRequesSend causes WDF access violation by Eliyas

Eliyas
Tue Sep 04 19:29:45 PDT 2007

I didn't expect it to work. I was hoping the system would crash elsewhere
enabling us to find the problem. I would like to take this offline and get
to the bottom of the issue. Would you please contact me by email? Just
remove "online" from my email address.

--
- This posting is provided "AS IS" with no warranties, and confers no
rights.



RE: WdfRequesSend causes WDF access violation by BobKeck

BobKeck
Thu Sep 13 10:28:03 PDT 2007

For anyone who happens to encounter a similar problem, this was caused by my
providing an EvtIoDeviceControl call back that had the wrong number of
arguments (two instead of five). This resulted in a warning error from the
compiler which is easy to miss (and I missed it), doesn't necessarily look
particularly important if you see it and does not stop the build from
succeeding.
An interesting feature of this error was that if verbose tracing was turned
off, the access violation did not occur and the driver seemed to work
correctly.

"Bob Keck" wrote:

> I am rewriting a WDM driver to use KMDF. My driver forwards most requests to
> the system supplied serial driver used as lower filter driver. The requests
> are forwarded using WdfRequestSend with the
> WDF_REQUEST_SEND_OPTION_SEND_AND_FORGET option. This completes successfully,
> but after my event handler exits an access violation (c0000005) occurs at
> Wdf01000!FxIFR+0x111. No doubt I am doing something wrong, but I don't see
> how to find out what. Any ideas?
>
> The call stack at various points and the WDF log are below:
> In serial:
> 00 822c8048 82079738 f6453b38 serial!SerialIoControl (FPO: [Non-Fpo]) (CONV:
> stdcall) [q:\wrkddk\serial\ioctl.c @ 597]
> 01 822c2048 822c2134 8206f490 nt!IopfCallDriver+0x51 (FPO: [0,0,0])
> 02 822c7968 8206f490 822c3ab8 Wdf01000!imp_WdfRequestSend+0x23a (FPO:
> [Non-Fpo])
> 03 7df90b68 7dd3c540 f6453b38 Amcc5933!WdfRequestSend+0x1d (FPO: [Non-Fpo])
> (CONV: stdcall) [q:\winddk\6000\inc\wdf\kmdf\10\wdfrequest.h @ 569]
> 04 7dd3dfb0 7df90b68 00000004 Amcc5933!AmccPciEvtDeviceControl+0xf4 (FPO:
> [Non-Fpo]) (CONV: stdcall) [d:\dev\sikmdf\amcc5933\sys\transfer.c @ 158]
> 05 7dd3dfb0 7df90b68 00000004 Wdf01000!FxIoQueueIoDeviceControl::Invoke+0x30
> (FPO: [Non-Fpo])
> 06 7df90b68 8206f490 822c2048
> Wdf01000!FxIoQueue::DispatchRequestToDriver+0x445 (FPO: [Non-Fpo])
> 07 822c2000 f96ab188 822c2048 Wdf01000!FxIoQueue::DispatchEvents+0x485 (FPO:
> [Non-Fpo])
> 08 00000000 822c3ba8 82079738 Wdf01000!FxIoQueue::QueueRequest+0x237 (FPO:
> [Non-Fpo])
> 09 82079738 f6453c58 80a21a49 Wdf01000!FxPkgIo::Dispatch+0x377 (FPO:
> [Non-Fpo])
> 0a 822c3ba8 82079738 82143230 Wdf01000!FxDevice::Dispatch+0x7f (FPO:
> [Non-Fpo])
> 0b 820797f0 82017e08 82079738 nt!IopfCallDriver+0x51 (FPO: [0,0,0])
> 0c 822c3ba8 82079738 82017e08 nt!IopSynchronousServiceTail+0x94 (FPO:
> [Non-Fpo])
> 0d 00000770 0000076c 00000000 nt!IopXxxControlFile+0x64f (FPO: [Non-Fpo])
> 0e 00000770 0000076c 00000000 nt!NtDeviceIoControlFile+0x2a (FPO: [Non-Fpo])
> 0f 00000770 0000076c 00000000 nt!KiFastCallEntry+0x158 (FPO: [0,3] TrapFrame
> @ f6453d64)
> 10 7c865aae 00000770 0000076c ntdll!KiFastSystemCallRet (FPO: [0,0,0])
> 11 00000770 0000076c 00000000 ntdll!ZwDeviceIoControlFile+0xc (FPO: [10,0,0])
> 12 00000770 0012ff30 00000000 kernel32!GetCommState+0x5a (FPO: [Non-Fpo])
>
> After return from serial:
> 00 7dd3dfb0 7df90b68 00000004 Amcc5933!AmccPciEvtDeviceControl+0xf4 (FPO:
> [Non-Fpo]) (CONV: stdcall) [d:\dev\sikmdf\amcc5933\sys\transfer.c @ 158]
> 01 7dd3dfb0 7df90b68 00000004 Wdf01000!FxIoQueueIoDeviceControl::Invoke+0x30
> (FPO: [Non-Fpo])
> 02 7df90b68 8206f490 822c2048
> Wdf01000!FxIoQueue::DispatchRequestToDriver+0x445 (FPO: [Non-Fpo])
> 03 822c2000 f96ab188 822c2048 Wdf01000!FxIoQueue::DispatchEvents+0x485 (FPO:
> [Non-Fpo])
> 04 00000000 822c3ba8 82079738 Wdf01000!FxIoQueue::QueueRequest+0x237 (FPO:
> [Non-Fpo])
> 05 82079738 f6453c58 80a21a49 Wdf01000!FxPkgIo::Dispatch+0x377 (FPO:
> [Non-Fpo])
> 06 822c3ba8 82079738 82143230 Wdf01000!FxDevice::Dispatch+0x7f (FPO:
> [Non-Fpo])
> 07 820797f0 82017e08 82079738 nt!IopfCallDriver+0x51 (FPO: [0,0,0])
> 08 822c3ba8 82079738 82017e08 nt!IopSynchronousServiceTail+0x94 (FPO:
> [Non-Fpo])
> 09 00000770 0000076c 00000000 nt!IopXxxControlFile+0x64f (FPO: [Non-Fpo])
> 0a 00000770 0000076c 00000000 nt!NtDeviceIoControlFile+0x2a (FPO: [Non-Fpo])
> 0b 00000770 0000076c 00000000 nt!KiFastCallEntry+0x158 (FPO: [0,3] TrapFrame
> @ f6453d64)
> 0c 7c865aae 00000770 0000076c ntdll!KiFastSystemCallRet (FPO: [0,0,0])
> 0d 00000770 0000076c 00000000 ntdll!ZwDeviceIoControlFile+0xc (FPO: [10,0,0])
> 0e 00000770 0012ff30 00000000 kernel32!GetCommState+0x5a (FPO: [Non-Fpo])
>
> At access violation:
> 00 0de00e00 00000005 0000000d Wdf01000!FxIFR+0x111 (FPO: [Non-Fpo])
> 01 822c78b0 00000005 0000000d Wdf01000!WPP_IFR_SF_q+0x21 (FPO: [Non-Fpo])
> 02 7df90b68 8206f490 822c2048
> Wdf01000!FxIoQueue::DispatchRequestToDriver+0x664 (FPO: [Non-Fpo])
> 03 822c2000 f96ab188 822c2048 Wdf01000!FxIoQueue::DispatchEvents+0x485 (FPO:
> [Non-Fpo])
> 04 00000000 822c3ba8 82079738 Wdf01000!FxIoQueue::QueueRequest+0x237 (FPO:
> [Non-Fpo])
> 05 82079738 f6453c58 80a21a49 Wdf01000!FxPkgIo::Dispatch+0x377 (FPO:
> [Non-Fpo])
> 06 822c3ba8 82079738 82143230 Wdf01000!FxDevice::Dispatch+0x7f (FPO:
> [Non-Fpo])
> 07 820797f0 82017e08 82079738 nt!IopfCallDriver+0x51 (FPO: [0,0,0])
> 08 822c3ba8 82079738 82017e08 nt!IopSynchronousServiceTail+0x94 (FPO:
> [Non-Fpo])
> 09 00000770 0000076c 00000000 nt!IopXxxControlFile+0x64f (FPO: [Non-F