[Beginner] Send Async Write Request to Remote I/O Target

I’m just trying to send a write request to a remote I/O target (another test driver in this setup). The target driver completes the write and completes it, but in my completion routine I get a BSOD:

I’m sure I’ve done something dumb… please enlighten me =)

VOID
RS232COM_EvtWriteCompletionRoutine(
In
WDFREQUEST Request,
In
WDFIOTARGET Target,
In
PWDF_REQUEST_COMPLETION_PARAMS Params,
In
WDFCONTEXT Context
)
{
UNREFERENCED_PARAMETER(Target);
UNREFERENCED_PARAMETER(Params);
TRACE_FUNCTION();
WDFREQUEST OldRequest;
ULONG_PTR information;
NTSTATUS status;
OldRequest = (WDFREQUEST)Context;

status = WdfRequestGetStatus(Request);
information=WdfRequestGetInformation(Request);

WdfObjectDelete(Request);

WdfRequestCompleteWithInformation(OldRequest, status, information);
}

void RS232COM_EvtWrite(
WDFQUEUE Queue,
WDFREQUEST Request,
size_t Length)
{
TRACE_FUNCTION();
UNREFERENCED_PARAMETER(Length);

WDFMEMORY memory;
WDFREQUEST newWriteAsync;
NTSTATUS status;

WDFDEVICE device = WdfIoQueueGetDevice(Queue);
RS232COM_Context *prs232com_context = DeviceGetRS232COM_Context(device);

INFO_MSG(“Write: 0x%X\n”, Length);

status = WdfRequestRetrieveInputMemory(Request, &memory);

if (!NT_SUCCESS(status))
{
ERROR_STATUS(“WdfRequestRetrieveInputMemory”, status);
return;
}
status = WdfRequestCreate(NULL, prs232com_context->USBTarget, &newWriteAsync);

if (!NT_SUCCESS(status))
{
ERROR_STATUS(“WdfRequestCreate”, status);
return;
}

status = WdfIoTargetFormatRequestForWrite(prs232com_context->USBTarget, newWriteAsync, memory, NULL, NULL);

if (!NT_SUCCESS(status))
{
ERROR_STATUS(“WdfIoTargetFormatRequestForWrite”, status);
return;
}

WdfRequestSetCompletionRoutine(newWriteAsync, RS232COM_EvtWriteCompletionRoutine, (WDFCONTEXT)Request);

if (!WdfRequestSend(newWriteAsync, prs232com_context->USBTarget, NULL))
{
status = WdfRequestGetStatus(newWriteAsync);

ERROR_STATUS(“WdfRequestSend”, status);
WdfRequestCompleteWithInformation(Request, status, 0);
}

}

Debug Dumps:

KDTARGET: Refreshing KD connection
USBCOM [TRACE] :Driver.c : DriverEntry
USBCOM [TRACE] :Driver.c : USBCOM_DeviceAdd
RS232COM [TRACE] :Driver.c : DriverEntry
RS232COM [TRACE] :Driver.c : RS232COM_DeviceAdd
RS232COM [ERROR] :WdfIoTargetOpen Failed with Status = 0xC000000E
RS232COM [TRACE] :Device.c : RS232COM_Device_Cleanup
RS232COM [TRACE] :Device.c : RS232COM_Device_Destroy
USBCOM [TRACE] :Device.c : USBCOM_EvtDevicePrepareHardware
USBCOM [TRACE] :Device.c : USBCOM_EvtD0Entry
+++++>WskKnrInit.
RS232COM [TRACE] :Driver.c : DriverEntry
RS232COM [TRACE] :Driver.c : RS232COM_DeviceAdd
RS232COM [TRACE] :Device.c : RS232COM_EvtDevicePrepareHardware
RS232COM [TRACE] :Device.c : RS232COM_EvtD0Entry
RS232COM [TRACE] :Queue.c : RS232COM_EvtWrite
RS232COM [INFOR] :Write: 0x6
USBCOM [TRACE] :Queue.c : USBCOM_EvtWrite
USBCOM [INFOR] :Write: 0x6
USBCOM [INFOR] :pUSBCOM_context->Size: 0x6
USBCOM [INFOR] :pUSBCOM_context->Buffer: "Hello
RS232COM [TRACE] :Queue.c : RS232COM_EvtWriteCompletionRoutine
KDTARGET: Refreshing KD connection

!analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

WDF_VIOLATION (10d)
The Kernel-Mode Driver Framework was notified that Windows detected an error
in a framework-based driver. In general, the dump file will yield additional
information about the driver that caused this bug check.
Arguments:
Arg1: 0000000000000003, Windows Driver Framework Verifier has encountered a fatal error.
In particular, an I/O request has been completed, but a framework
request object cannot be deleted because there are outstanding
references to the input buffer or the output buffer, or both. The
driver’s IFR will include details on the outstanding references.
Arg2: 00001fffaed68408, WDFREQUEST handle
Arg3: 0000000000000001, The number of outstanding references remaining on both buffers.
Arg4: ffffe0005103c660, Reserved.

Debugging Details:

“KERNEL32.DLL” was not found in the image list.
Debugger will attempt to load “KERNEL32.DLL” at given base 00000000`00000000.

Please provide the full image name, including the extension (i.e. kernel32.dll)
for more reliable results.Base address and size overrides can be given as
.reload <image.ext>=,.
Unable to add module at 0000000000000000<br><br>BUGCHECK_STR: 0x10D_3<br><br>DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT<br><br>PROCESS_NAME: DeviceExerciso<br><br>CURRENT_IRQL: 0<br><br>ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) amd64fre<br><br>LAST_CONTROL_TRANSFER: from fffff8027f3e1a46 to fffff8027f35eb90<br><br>STACK_TEXT: <br>ffffd001d72a4358 fffff8027f3e1a46 : 0000000000000000 0000000000000000 ffffd001d72a44c0 fffff8027f24e8cc : nt!DbgBreakPointWithStatus<br>ffffd001d72a4360 fffff8027f3e1357 : 0000000000000003 0000000000000003 fffff8027f365f80 000000000000010d : nt!KiBugCheckDebugBreak+0x12<br>ffffd001d72a43c0 fffff8027f3580a4 : 00001fffaed68408 ffffd001d72a4bc0 ffff26107d980014 ffffd001d72a4b78 : nt!KeBugCheck2+0x8ab<br>ffffd001d72a4ad0 fffff801d86c7caa : 000000000000010d 0000000000000003 00001fffaed68408 0000000000000001 : nt!KeBugCheckEx+0x104<br>ffffd001d72a4b10 fffff801d868f4b7 : ffffe00051297bf0 0000000000000000 0000000000000004 ffffe0005103c660 : Wdf01000!FxVerifierBugCheck+0x1e<br>ffffd001d72a4b50 fffff801d865900d : ffffe0005103c660 fffff80100000000 00001fff00000001 0000000000000000 : Wdf01000!FxRequest::CompleteInternal+0x3bdf7<br>ffffd001d72a4c10 fffff801da7a0549 : ffffe0004f4bf910 ffffe00051297bf0 0000000000000000 ffffe0004f4ff020 : Wdf01000!imp_WdfRequestCompleteWithInformation+0x9d<br>ffffd001d72a4c70 fffff801da7a0356 : 00001fffaed68408 fffff80100000000 0000000000000006 00001fffaed68408 : COMTester!WdfRequestCompleteWithInformation+0x49 [c:\program files (x86)\windows kits\8.1\include\wdf\kmdf\1.9\wdfrequest.h @ 1038]<br>ffffd001d72a4cb0 fffff801d86594d9 : 00001fffb0b406e8 00001fffb0b00fd8 ffffe00051413c48 00001fffaed68408 : COMTester!RS232COM_EvtWriteCompletionRoutine+0x76 [c:\users\admin\desktop\com_tester\comtester\queue.c @ 101]<br>ffffd001d72a4d00 fffff801d8659c51 : ffffd001d72a5c50 ffffd001d72a5c48 0000e0004f76cad0 00001f80012addfb : Wdf01000!FxRequestBase::CompleteSubmitted+0x496<br>ffffd001d72a4df0 fffff8027f304efd : ffffe000510544b0 0000000000000000 0000000000000000 0000000000000000 : Wdf01000!FxIoTarget::_RequestCompletionRoutine+0x162<br>ffffd001d72a4e70 fffff8027f2a3378 : ffffe0004fff0330 ffffd001d72a4f49 0000000000000000 ffffe0004fff044b : nt!IopUnloadSafeCompletion+0x49<br>ffffd001d72a4ea0 fffff801d86538fc : 5f4d4f4342535570 0000000000000000 0000000000000004 ffffe0005054e420 : nt!IopfCompleteRequest+0x588<br>ffffd001d72a4fb0 fffff801d865900d : 00001fffafaa87c8 fffff80200000000 ffffe00000000001 ffffe0004f433500 : Wdf01000!FxRequest::CompleteInternal+0x23c<br>ffffd001d72a5070 fffff801d9dea1e9 : ffffe000505579f0 ffffe00050f54020 00001fffafaa87c8 ffffe0004f4335d6 : Wdf01000!imp_WdfRequestCompleteWithInformation+0x9d<br>ffffd001d72a50d0 fffff801d9dea157 : 00001fffaf0abfd8 ffffe00000000000 0000000000000006 0000000000000003 : USBTester!WdfRequestCompleteWithInformation+0x49 [c:\program files (x86)\windows kits\8.1\include\wdf\kmdf\1.9\wdfrequest.h @ 1038]<br>ffffd001d72a5110 fffff801d86e19a2 : 00001fffafaa87c8 00001fffaf0abfd8 0000000000000006 ffffe0004feaf500 : USBTester!USBCOM_EvtWrite+0x167 [c:\users\admin\desktop\usbtester\usbtester\queue.c @ 97]<br>ffffd001d72a5170 fffff801d869a002 : 0000000000000000 ffffe00050f54020 ffffe00050557830 00001fffaf0abfd8 : Wdf01000!FxIoQueueIoRead::Invoke+0x4a<br>ffffd001d72a51a0 fffff801d8654123 : ffffe00050557830 ffffd001d72a52c9 ffffe0005054e420 0000000000000001 : Wdf01000!FxIoQueue::DispatchRequestToDriver+0x457f2<br>ffffd001d72a5270 fffff801d8660279 : ffffe00050557830 ffffe00050f54000 0000000000000000 0000000000000001 : Wdf01000!FxIoQueue::DispatchEvents+0x363<br>ffffd001d72a5330 fffff801d8658d93 : 00001fff00000600 ffffe00050f54020 ffffe0004fff0330 ffffe0004fff0330 : Wdf01000!FxIoQueue::QueueRequest+0x8d<br>ffffd001d72a53a0 fffff801d865a056 : 00001fffb0b026d8 0000000000000000 ffffe000505507c0 00001fffaed68408 : Wdf01000!FxDevice::DispatchWithLock+0xb51<br>ffffd001d72a5480 fffff801da7a070a : ffffe0005103c800 ffffe0004f4bf910 ffffe0004f4ff020 0000000000000000 : Wdf01000!imp_WdfRequestSend+0x156<br>ffffd001d72a54e0 fffff801da7a02a0 : 00001fffb0b406e8 00001fffb0b00fd8 0000000000000000 0000000000000000 : COMTester!WdfRequestSend+0x4a [c:\program files (x86)\windows kits\8.1\include\wdf\kmdf\1.9\wdfrequest.h @ 661]<br>ffffd001d72a5520 fffff801d86e19a2 : 00001fffb0b026d8 00001fffaed68408 0000000000000006 ffffe0004f4fa900 : COMTester!RS232COM_EvtWrite+0x130 [c:\users\admin\desktop\com_tester\comtester\queue.c @ 149]<br>ffffd001d72a5590 fffff801d869a002 : 0000000000000000 ffffe00051297bf0 ffffe0004f4fd920 00001fffaed68408 : Wdf01000!FxIoQueueIoRead::Invoke+0x4a<br>ffffd001d72a55c0 fffff801d8654123 : ffffe0004f4fd920 ffffd001d72a56e9 ffffe0005103c660 0000000000000001 : Wdf01000!FxIoQueue::DispatchRequestToDriver+0x457f2<br>ffffd001d72a5690 fffff801d8660279 : ffffe0004f4fd920 ffffe00051297b00 0000000000000000 fffff6fb7dbf0048 : Wdf01000!FxIoQueue::DispatchEvents+0x363<br>ffffd001d72a5750 fffff801d8658d93 : 0000000000000700 ffffe00051297bf0 ffffe0004f4a05c0 ffffe0004f4a05c0 : Wdf01000!FxIoQueue::QueueRequest+0x8d<br>ffffd001d72a57c0 fffff8027f6098ec : 0000000000000000 ffffd001d72a5900 ffffe0005124f950 ffffe0004f4fa900 : Wdf01000!FxDevice::DispatchWithLock+0xb51<br>ffffd001d72a58a0 fffff8027f609298 : ffffe00051031705 ffffd001d72a5b80 0000000000000000 ffffe000510317e0 : nt!IopSynchronousServiceTail+0x16c<br>ffffd001d72a5970 fffff8027f3637b3 : ffffe0004f4fad01 0000000000000000 0000000000000000 0000000000000000 : nt!NtWriteFile+0x750<br>ffffd001d72a5a90 0000000076e22772 : 0000000076e2241f 0000002376edd1dc 0000000000000023 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13<br>0000000000c0ec48 0000000076e2241f : 0000002376edd1dc 0000000000000023 0000000000000000 0000000000d0ff18 : wow64cpu!CpupSyscallStub+0x2<br>0000000000c0ec50 0000000076de323a : 0000000000000000 0000000076e21503 0000000000000000 0000000076de3420 : wow64cpu!ReadWriteFileFault+0x31<br>0000000000c0ed00 0000000076de317e : 0000000000000000 0000000000000000 0000000000c0fd30 0000000000c0f670 : wow64!RunCpuSimulation+0xa<br>0000000000c0ed50 00007fff3f02f15b : 00000000008400f8 0000000000000000 0000000000000010 000000007ee1c000 : wow64!Wow64LdrpInitialize+0x172<br>0000000000c0f290 00007fff3f01a188 : 00007fff3ef60000 0000000000000000 0000000000000000 000000007ee1c000 : ntdll!LdrpInitializeProcess+0x157b<br>0000000000c0f5b0 00007fff3efb6a5a : 0000000000c0f670 0000000000000000 0000000000000000 000000007ee1c000 : ntdll!_LdrpInitialize+0x636dc<br>0000000000c0f620 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!LdrInitializeThunk+0xe<br><br>STACK_COMMAND: kb<br><br>FOLLOWUP_IP: <br>COMTester!WdfRequestCompleteWithInformation+49 [c:\program files (x86)\windows kits\8.1\include\wdf\kmdf\1.9\wdfrequest.h @ 1038]<br>fffff801da7a0549 4883c438 add rsp,38h

FAULTING_SOURCE_LINE: c:\program files (x86)\windows kits\8.1\include\wdf\kmdf\1.9\wdfrequest.h

FAULTING_SOURCE_FILE: c:\program files (x86)\windows kits\8.1\include\wdf\kmdf\1.9\wdfrequest.h

FAULTING_SOURCE_LINE_NUMBER: 1038

FAULTING_SOURCE_CODE:
1034: ULONG_PTR Information
1035: )
1036: {
1037: ((PFN_WDFREQUESTCOMPLETEWITHINFORMATION) WdfFunctions[WdfRequestCompleteWithInformationTableIndex])(WdfDriverGlobals, Request, Status, Information);
> 1038: }
1039:
1040: //
1041: // WDF Function: WdfRequestGetParameters
1042: //
1043: typedef

SYMBOL_STACK_INDEX: 7

SYMBOL_NAME: COMTester!WdfRequestCompleteWithInformation+49

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: COMTester

IMAGE_NAME: COMTester.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 54248b9b

BUCKET_ID_FUNC_OFFSET: 49

FAILURE_BUCKET_ID: 0x10D_3_COMTester!WdfRequestCompleteWithInformation

BUCKET_ID: 0x10D_3_COMTester!WdfRequestCompleteWithInformation

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0x10d_3_comtester!wdfrequestcompletewithinformation

FAILURE_ID_HASH: {452dcbe5-72c3-1c99-1bfb-96f9b8c0d6f0}

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

kd> !wdfkd.wdflogdump COMTester
Trace searchpath is:

Trace format prefix is: %7!u!: %!FUNC! -
Trying to extract TMF information from - C:\ProgramData\dbg\sym\Wdf01000.pdb\910864B4254D480C94ABAE23F3EBE0662\Wdf01000.pdb
Log at 0xffffe000510f8000
Gather log: Please wait, this may take a moment (reading 4024 bytes).
% read so far … 10, 20, 30, 100
There are 30 log entries
— start of log —
1: FxIFRStart - FxIFR logging started
2: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x00001FFFAEDB06A8 !devobj 0xFFFFE000510544B0 entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
3: FxIoTargetRemote::OpenTargetHandle - ZwCreateFile for WDFIOTARGET 00001FFFB0B00FD8 returned status STATUS_SUCCESS, info 0x0
4: FxPkgPnp::Dispatch - WDFDEVICE 0x00001FFFAEDB06A8 !devobj 0xFFFFE000510544B0, IRP_MJ_PNP, 0x00000000(IRP_MN_START_DEVICE) IRP 0xFFFFE000510454E0
5: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x00001FFFAEDB06A8 !devobj 0xFFFFE000510544B0 entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
6: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x00001FFFAEDB06A8 !devobj 0xFFFFE000510544B0 entering PnP State WdfDevStatePnpHardwareAvailable from WdfDevStatePnpInitStarting
7: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x00001FFFAEDB06A8 !devobj 0xFFFFE000510544B0 entering power policy state WdfDevStatePwrPolStarting from WdfDevStatePwrPolObjectCreated
8: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x00001FFFAEDB06A8 !devobj 0xFFFFE000510544B0 entering power idle state FxIdleStarted from FxIdleStopped
9: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x00001FFFAEDB06A8 !devobj 0xFFFFE000510544B0 entering Power State WdfDevStatePowerStartingCheckDeviceType from WdfDevStatePowerObjectCreated
10: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x00001FFFAEDB06A8 !devobj 0xFFFFE000510544B0 entering Power State WdfDevStatePowerD0Starting from WdfDevStatePowerStartingCheckDeviceType
11: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x00001FFFAEDB06A8 !devobj 0xFFFFE000510544B0 entering Power State WdfDevStatePowerD0StartingConnectInterrupt from WdfDevStatePowerD0Starting
12: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x00001FFFAEDB06A8 !devobj 0xFFFFE000510544B0 entering Power State WdfDevStatePowerD0StartingDmaEnable from WdfDevStatePowerD0StartingConnectInterrupt
13: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x00001FFFAEDB06A8 !devobj 0xFFFFE000510544B0 entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from WdfDevStatePowerD0StartingDmaEnable
14: FxPkgIo::ResumeProcessingForPower - Power resume all queues of WDFDEVICE 0x00001FFFAEDB06A8
15: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x00001FFFAEDB06A8 !devobj 0xFFFFE000510544B0 entering power idle state FxIdleStartedPowerUp from FxIdleStarted
16: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x00001FFFAEDB06A8 !devobj 0xFFFFE000510544B0 entering power idle state FxIdleDisabled from FxIdleStartedPowerUp
17: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x00001FFFAEDB06A8 !devobj 0xFFFFE000510544B0 entering Power State WdfDevStatePowerDecideD0State from WdfDevStatePowerD0StartingStartSelfManagedIo
18: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x00001FFFAEDB06A8 !devobj 0xFFFFE000510544B0 entering Power State WdfDevStatePowerD0 from WdfDevStatePowerDecideD0State
19: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x00001FFFAEDB06A8 !devobj 0xFFFFE000510544B0 entering power policy state WdfDevStatePwrPolStartingPoweredUp from WdfDevStatePwrPolStarting
20: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x00001FFFAEDB06A8 !devobj 0xFFFFE000510544B0 entering power policy state WdfDevStatePwrPolStartingSucceeded from WdfDevStatePwrPolStartingPoweredUp
21: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x00001FFFAEDB06A8 !devobj 0xFFFFE000510544B0 entering power policy state WdfDevStatePwrPolStartingDecideS0Wake from WdfDevStatePwrPolStartingSucceeded
22: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x00001FFFAEDB06A8 !devobj 0xFFFFE000510544B0 entering power policy state WdfDevStatePwrPolStarted from WdfDevStatePwrPolStartingDecideS0Wake
23: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x00001FFFAEDB06A8 !devobj 0xFFFFE000510544B0 entering power idle state FxIdleDisabled from FxIdleDisabled
24: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x00001FFFAEDB06A8 !devobj 0xFFFFE000510544B0 entering PnP State WdfDevStatePnpEnableInterfaces from WdfDevStatePnpHardwareAvailable
25: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x00001FFFAEDB06A8 !devobj 0xFFFFE000510544B0 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpEnableInterfaces
26: FxPkgPnp::Dispatch - WDFDEVICE 0x00001FFFAEDB06A8 !devobj 0xFFFFE000510544B0, IRP_MJ_PNP, 0x00000014(IRP_MN_QUERY_PNP_DEVICE_STATE) IRP 0xFFFFE0005126FC60
27: FxPkgFdo::HandleQueryPnpDeviceStateCompletion - WDFDEVICE 0x00001FFFAEDB06A8 !devobj 0xFFFFE000510544B0 returning PNP_DEVICE_STATE 0x0 IRP 0xFFFFE0005126FC60
28: FxPkgPnp::Dispatch - WDFDEVICE 0x00001FFFAEDB06A8 !devobj 0xFFFFE000510544B0, IRP_MJ_PNP, 0x00000007(IRP_MN_QUERY_DEVICE_RELATIONS) type BusRelations IRP 0xFFFFE0005126FC60
29: FxRequest::CompleteInternal - WDFREQUEST 0x00001FFFAED68408, PIRP 0xFFFFE0004F4A05C0, Major Function 0x4, completed with outstanding references on WDFMEMORY 0x00001FFFAED68331 or 0x0000000000000000 retrieved from this request
30: FxRequest::CompleteInternal - WDFMEMORY 0x00001FFFAED68331, buffer FFFFE0004F4CE040, PMDL 0000000000000000, length 6 bytes
---- end of log ----</image.ext>

Roscoe, Roscoe, Roscoe… Dump the log, like the !analyze -v tells you to. That should make the problem clear.

Peter
OSR
@OSRDrivers

kd> !wdfkd.wdflogdump COMTester ?

That was at the bottom of the email, unless I’m missing something else?

On Fri, Sep 26, 2014 at 6:41 AM, wrote:

> Roscoe, Roscoe, Roscoe… Dump the log, like the !analyze -v tells you
> to. That should make the problem clear.
>
> Peter
> OSR
> @OSRDrivers
>
>
> —
> 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
>


Thanks in advance,
Roscoe Casita

Why are you completing the request in your completion routine?

xxxxx@broadcom.com wrote:

Why are you completing the request in your completion routine?

He’s not. He creates a new request and submits that, passing the
original request as context. In the completion routine, he deletes his
new request, and then completes the original. A pretty ordinary idiom.

I’ve been scanning the code and haven’t found the problem yet.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

xxxxx@gmail.com wrote:

I’m just trying to send a write request to a remote I/O target (another test driver in this setup). The target driver completes the write and completes it, but in my completion routine I get a BSOD:

I’m sure I’ve done something dumb… please enlighten me =)

VOID
RS232COM_EvtWriteCompletionRoutine(
In
WDFREQUEST Request,
In
WDFIOTARGET Target,
In
PWDF_REQUEST_COMPLETION_PARAMS Params,
In
WDFCONTEXT Context
)
{
UNREFERENCED_PARAMETER(Target);
UNREFERENCED_PARAMETER(Params);
TRACE_FUNCTION();
WDFREQUEST OldRequest;
ULONG_PTR information;
NTSTATUS status;
OldRequest = (WDFREQUEST)Context;

status = WdfRequestGetStatus(Request);
information=WdfRequestGetInformation(Request);

WdfObjectDelete(Request);

WdfRequestCompleteWithInformation(OldRequest, status, information);
}

Are you SURE that’s EXACTLY how the code looks? If you swapped those
last two lines, you would see exactly the results you got.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Perhaps the easiest in this case would be this:

Does someone have a sample of sending a request (using the memory from the
current request) to a remote I/O target?

  1. Get Memory from current request
  2. create new request.
  3. Send request (async or sync)
  4. complete old request.

The reason its bsod’ing is that the memory reference in of the first
request still has an outstanding memory reference.

Do I need to deleteobject on the old request’s memory in order to remove
the reference? I was under the belief that by deleting the sent request it
will delete the reference to the memory object/ chain of references?

On Fri, Sep 26, 2014 at 6:51 AM, Roscoe Casita
wrote:

> kd> !wdfkd.wdflogdump COMTester ?
>
> That was at the bottom of the email, unless I’m missing something else?
>
> On Fri, Sep 26, 2014 at 6:41 AM, wrote:
>
>> Roscoe, Roscoe, Roscoe… Dump the log, like the !analyze -v tells you
>> to. That should make the problem clear.
>>
>> Peter
>> OSR
>> @OSRDrivers
>>
>>
>> —
>> 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
>>
>
>
>
> –
> Thanks in advance,
> Roscoe Casita
>


Thanks in advance,
Roscoe Casita

Added some more tracing to be 100% sure, So I must be doing something
wrong with the WDFMEMORY Object? Do I somehow grab that from the old
request, and delete that before deleting the request, and before completing
the original request?

On Fri, Sep 26, 2014 at 10:18 AM, Tim Roberts wrote:

> xxxxx@gmail.com wrote:
> > I’m just trying to send a write request to a remote I/O target (another
> test driver in this setup). The target driver completes the write and
> completes it, but in my completion routine I get a BSOD:
> >
> >
> > I’m sure I’ve done something dumb… please enlighten me =)
> >
> > VOID
> > RS232COM_EvtWriteCompletionRoutine(
> > In
> > WDFREQUEST Request,
> > In
> > WDFIOTARGET Target,
> > In
> > PWDF_REQUEST_COMPLETION_PARAMS Params,
> > In
> > WDFCONTEXT Context
> > )
> > {
> > UNREFERENCED_PARAMETER(Target);
> > UNREFERENCED_PARAMETER(Params);
> > TRACE_FUNCTION();
> > WDFREQUEST OldRequest;
> > ULONG_PTR information;
> > NTSTATUS status;
> > OldRequest = (WDFREQUEST)Context;
> >
> > status = WdfRequestGetStatus(Request);
> > information=WdfRequestGetInformation(Request);
> >
> >
> > WdfObjectDelete(Request);
> >
> > WdfRequestCompleteWithInformation(OldRequest, status,
> information);
> > }
>
> Are you SURE that’s EXACTLY how the code looks? If you swapped those
> last two lines, you would see exactly the results you got.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> 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
>


Thanks in advance,
Roscoe Casita

Just an example will go a long way for me btw, I can find how to forward a
request, but I wanted to send it to a remote target.

On Fri, Sep 26, 2014 at 11:01 AM, Roscoe Casita
wrote:

> Added some more tracing to be 100% sure, So I must be doing something
> wrong with the WDFMEMORY Object? Do I somehow grab that from the old
> request, and delete that before deleting the request, and before completing
> the original request?
>
> On Fri, Sep 26, 2014 at 10:18 AM, Tim Roberts wrote:
>
>> xxxxx@gmail.com wrote:
>> > I’m just trying to send a write request to a remote I/O target (another
>> test driver in this setup). The target driver completes the write and
>> completes it, but in my completion routine I get a BSOD:
>> >
>> >
>> > I’m sure I’ve done something dumb… please enlighten me =)
>> >
>> > VOID
>> > RS232COM_EvtWriteCompletionRoutine(
>> > In
>> > WDFREQUEST Request,
>> > In
>> > WDFIOTARGET Target,
>> > In
>> > PWDF_REQUEST_COMPLETION_PARAMS Params,
>> > In
>> > WDFCONTEXT Context
>> > )
>> > {
>> > UNREFERENCED_PARAMETER(Target);
>> > UNREFERENCED_PARAMETER(Params);
>> > TRACE_FUNCTION();
>> > WDFREQUEST OldRequest;
>> > ULONG_PTR information;
>> > NTSTATUS status;
>> > OldRequest = (WDFREQUEST)Context;
>> >
>> > status = WdfRequestGetStatus(Request);
>> > information=WdfRequestGetInformation(Request);
>> >
>> >
>> > WdfObjectDelete(Request);
>> >
>> > WdfRequestCompleteWithInformation(OldRequest, status,
>> information);
>> > }
>>
>> Are you SURE that’s EXACTLY how the code looks? If you swapped those
>> last two lines, you would see exactly the results you got.
>>
>> –
>> Tim Roberts, xxxxx@probo.com
>> Providenza & Boekelheide, Inc.
>>
>>
>> —
>> 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
>>
>
>
>
> –
> Thanks in advance,
> Roscoe Casita
>


Thanks in advance,
Roscoe Casita

I’m not sure if it’s legal to create WDFREQUEST on the stack and return while it’s pending.

Roscoe Casita wrote:

Perhaps the easiest in this case would be this:

Does someone have a sample of sending a request (using the memory from
the current request) to a remote I/O target?

  1. Get Memory from current request
  2. create new request.
  3. Send request (async or sync)
  4. complete old request.

The documentation for WdfRequestRetrieveInputMemory has an example that
does exactly this, although it doesn’t show the completion routine.

There’s no particularly reason why you need to create a new request
here. You should just be able to format the existing request and send
it down. That would eliminate one potential source of trouble.

The reason its bsod’ing is that the memory reference in of the first
request still has an outstanding memory reference.

Do I need to deleteobject on the old request’s memory in order to
remove the reference? I was under the belief that by deleting the sent
request it will delete the reference to the memory object/ chain of
references?

Yes, it should. I can’t see anything wrong in your code. The
lower-level driver is completing the request immediately, so your
completion routine is actually being called in the same call stack as
the submission, but that shouldn’t matter here.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

xxxxx@broadcom.com wrote:

I’m not sure if it’s legal to create WDFREQUEST on the stack and return while it’s pending.

Oh, of course it is. After you call WdfRequestSend, the request isn’t
owned by you any more. You can’t do anything more with it until you get
a completion callback, and at that point the request handle is handed to
you.

Besides, that’s not an issue here. If you look at his dump, the request
is getting completed synchronously, so his completion routine is running
before WdfRequestSend has returned.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

The Target is NOT local/below me, its a different target in the system,
this is for me to understand how to relay requests between these two
drivers

[RS232COM] <—> [USBCOM]

I’ll check the sample, thank you!

On Fri, Sep 26, 2014 at 11:09 AM, Tim Roberts wrote:

> xxxxx@broadcom.com wrote:
> > I’m not sure if it’s legal to create WDFREQUEST on the stack and return
> while it’s pending.
>
> Oh, of course it is. After you call WdfRequestSend, the request isn’t
> owned by you any more. You can’t do anything more with it until you get
> a completion callback, and at that point the request handle is handed to
> you.
>
> Besides, that’s not an issue here. If you look at his dump, the request
> is getting completed synchronously, so his completion routine is running
> before WdfRequestSend has returned.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> 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
>


Thanks in advance,
Roscoe Casita

… So this works… at the suggestion of Scott Noone =)

  1. Why is this required ( is it? if not what is the correct way?)
  2. Where is the documentation to this effect?

/// Remote Target IO Completion Routine for writing to the other device.
/// 1. The memory has already been ‘used’ by the other device, we just need
to fill out
// how much memory was written.
// 2. Get the status of the remote request,
// 3. Get the information from the remote request,
// 4. Delete the old request to free the memory (assumption?)
// 5. Complete the Original request with the status and size from the
remote request.

VOID
RS232COM_EvtWriteCompletionRoutine(
In
WDFREQUEST Request,
In
WDFIOTARGET Target,
In
PWDF_REQUEST_COMPLETION_PARAMS Params,
In
WDFCONTEXT Context
)
{
UNREFERENCED_PARAMETER(Target);
UNREFERENCED_PARAMETER(Params);
TRACE_FUNCTION();
WDFREQUEST OldRequest;
ULONG_PTR information;
NTSTATUS status;
OldRequest = (WDFREQUEST)Context;

TRACE_MSG(“Before WdfRequestGetStatus On The Sent Request.\n”);
status = WdfRequestGetStatus(Request);
information=WdfRequestGetInformation(Request);

WDF_REQUEST_REUSE_PARAMS params;
WDF_REQUEST_REUSE_PARAMS_INIT(
&params,
WDF_REQUEST_REUSE_NO_FLAGS,
STATUS_SUCCESS
);
TRACE_MSG(“After Get Stats & Information, before WdfRequestReuse.\n”);

status = WdfRequestReuse(
Request,
&params
);
ASSERT(NT_SUCCESS(status));

TRACE_MSG(“After WdfRequestReuse, before WdfObjectDelete.\n”);
WdfObjectDelete(Request);

TRACE_MSG(“After WdfObjectDelete. Before
WdfRequestCompleteWithInformation\n”);
WdfRequestCompleteWithInformation(OldRequest, status, information);
TRACE_MSG(“Function Exit RS232COM_EvtWriteCompletionRoutine\n”);
}


TRACE:
RS232COM [TRACE] :Queue.c : RS232COM_EvtWrite
RS232COM [INFOR] :Write: 0x7
RS232COM [TRACE] : Before WdfRequestSetCompletionRoutine
RS232COM [TRACE] :After Call WdfRequestSetCompletionRoutine, Before
WdfRequestSend
USBCOM [TRACE] :Queue.c : USBCOM_EvtWrite
USBCOM [INFOR] :Write: 0x7
USBCOM [INFOR] :pUSBCOM_context->Size: 0x7
USBCOM [INFOR] :pUSBCOM_context->Buffer: “Hello”
RS232COM [TRACE] :Queue.c : RS232COM_EvtWriteCompletionRoutine
RS232COM [TRACE] :Before WdfRequestGetStatus On The Sent Request.
RS232COM [TRACE] :After Get Stats & Information, before WdfRequestReuse.
RS232COM [TRACE] :After WdfRequestReuse, before WdfObjectDelete.
RS232COM [TRACE] :After WdfObjectDelete. Before
WdfRequestCompleteWithInformation
RS232COM [TRACE] :Function Exit RS232COM_EvtWriteCompletionRoutine
RS232COM [TRACE] :RS232COM_EvtWrite Function Exit

On Fri, Sep 26, 2014 at 11:16 AM, Roscoe Casita
wrote:

> The Target is NOT local/below me, its a different target in the system,
> this is for me to understand how to relay requests between these two
> drivers
>
> [RS232COM] <—> [USBCOM]
>
> I’ll check the sample, thank you!
>
>
> On Fri, Sep 26, 2014 at 11:09 AM, Tim Roberts wrote:
>
>> xxxxx@broadcom.com wrote:
>> > I’m not sure if it’s legal to create WDFREQUEST on the stack and return
>> while it’s pending.
>>
>> Oh, of course it is. After you call WdfRequestSend, the request isn’t
>> owned by you any more. You can’t do anything more with it until you get
>> a completion callback, and at that point the request handle is handed to
>> you.
>>
>> Besides, that’s not an issue here. If you look at his dump, the request
>> is getting completed synchronously, so his completion routine is running
>> before WdfRequestSend has returned.
>>
>> –
>> Tim Roberts, xxxxx@probo.com
>> Providenza & Boekelheide, Inc.
>>
>>
>> —
>> 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
>>
>
>
>
> –
> Thanks in advance,
> Roscoe Casita
>


Thanks in advance,
Roscoe Casita

Sorry, Ros… I stopped reading at the code and didn’t see the attached dump.

It’s weird. So, to summarize: if you reset the new request for reuse before deleting the object you’re “good to go” :slight_smile: but if you do not “reuse” the Request… It blue screens? Is that the summary?

Peter
OSR
@OSRDrivers

That is the summary. The important part is I dug around on msdn for a long
time and still have not found information that dictates this usage.
On Sep 26, 2014 4:51 PM, wrote:

> Sorry, Ros… I stopped reading at the code and didn’t see the attached
> dump.
>
> It’s weird. So, to summarize: if you reset the new request for reuse
> before deleting the object you’re “good to go” :slight_smile: but if you do not
> “reuse” the Request… It blue screens? Is that the summary?
>
> Peter
> OSR
> @OSRDrivers
>
>
> —
> 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
>

As as note, I get to drill the tech support team about “always get a log
file… Because what’s the first thing we will ask you for?”.

I’ll always do the same on a bsod =)
On Sep 26, 2014 5:10 PM, xxxxx@gmail.com wrote:

That is the summary. The important part is I dug around on msdn for a long
time and still have not found information that dictates this usage.
On Sep 26, 2014 4:51 PM, wrote:
>
>> Sorry, Ros… I stopped reading at the code and didn’t see the attached
>> dump.
>>
>> It’s weird. So, to summarize: if you reset the new request for reuse
>> before deleting the object you’re “good to go” :slight_smile: but if you do not
>> “reuse” the Request… It blue screens? Is that the summary?
>>
>> Peter
>> OSR
>> @OSRDrivers
>>
>>
>> —
>> 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
>>
>

This would probably because the new request takes a reference on the wdfmemory object of the parent request. When you complete a parent request we want to make sure you are not creating a hand grenade by leaving dangling references to memory. If the number of references on the WDFMEMORY in the request are >0, we stop with a WDF violation.

When you format the new request, that takes a reference on the parent request WDFMEMORY (assuming you pass it in). That reference through the format action is still there when the new request completes back to your driver. You can clear that reference by either

a) Deleting the new request

b) Reseting the request, thus clearing the format, thus releasing the reference

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Roscoe Casita
Sent: Friday, September 26, 2014 2:13 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] [Beginner] Send Async Write Request to Remote I/O Target

That is the summary. The important part is I dug around on msdn for a long time and still have not found information that dictates this usage.
On Sep 26, 2014 4:51 PM, > wrote:
Sorry, Ros… I stopped reading at the code and didn’t see the attached dump.

It’s weird. So, to summarize: if you reset the new request for reuse before deleting the object you’re “good to go” :slight_smile: but if you do not “reuse” the Request… It blue screens? Is that the summary?

Peter
OSR
@OSRDrivers


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

Wow! thanks for chiming in Doron!

Your describing exactly the behavior that the sample did!

  1. Create new request for the remote target.
  2. Set the memory reference to the old memory reference.
  3. Set the completion routine.
  4. Send the request.
  5. In the call back routine, Get the status code and information.
  6. Delete the request.
  7. complete the original request with the status code and information: ->
    BSOD because reference to the memory object.

The following steps Don’t create the bsod:

  1. Create new request for the remote target.
  2. Set the memory reference to the old memory reference.
  3. Set the completion routine.
  4. Send the request.
  5. In the call back routine, Get the status code and information.
  6. Reset the Request.
  7. Delete the request.
  8. complete the original request with the status code and information: ->
    BSOD because reference to the memory object.

Thanks again for the input!

On Fri, Sep 26, 2014 at 2:18 PM, Doron Holan
wrote:

> This would probably because the new request takes a reference on the
> wdfmemory object of the parent request. When you complete a parent request
> we want to make sure you are not creating a hand grenade by leaving
> dangling references to memory. If the number of references on the WDFMEMORY
> in the request are >0, we stop with a WDF violation.
>
>
>
> When you format the new request, that takes a reference on the parent
> request WDFMEMORY (assuming you pass it in). That reference through the
> format action is still there when the new request completes back to your
> driver. You can clear that reference by either
>
> a) Deleting the new request
>
> b) Reseting the request, thus clearing the format, thus releasing
> the reference
>
>
>
> d
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *Roscoe Casita
> Sent: Friday, September 26, 2014 2:13 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] [Beginner] Send Async Write Request to Remote I/O
> Target
>
>
>
> That is the summary. The important part is I dug around on msdn for a long
> time and still have not found information that dictates this usage.
>
> On Sep 26, 2014 4:51 PM, wrote:
>
> Sorry, Ros… I stopped reading at the code and didn’t see the attached
> dump.
>
> It’s weird. So, to summarize: if you reset the new request for reuse
> before deleting the object you’re “good to go” :slight_smile: but if you do not
> “reuse” the Request… It blue screens? Is that the summary?
>
> Peter
> OSR
> @OSRDrivers
>
>
> —
> 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
>
> —
> 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
>


Thanks in advance,
Roscoe Casita

What version of WDF?

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Roscoe Casita
Sent: Friday, September 26, 2014 2:57 PM
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] [Beginner] Send Async Write Request to Remote I/O Target

Wow! thanks for chiming in Doron!

Your describing exactly the behavior that the sample did!

  1. Create new request for the remote target.
  2. Set the memory reference to the old memory reference.
  3. Set the completion routine.
  4. Send the request.
  5. In the call back routine, Get the status code and information.
  6. Delete the request.
  7. complete the original request with the status code and information: -> BSOD because reference to the memory object.

The following steps Don’t create the bsod:

  1. Create new request for the remote target.
  2. Set the memory reference to the old memory reference.
  3. Set the completion routine.
  4. Send the request.
  5. In the call back routine, Get the status code and information.
  6. Reset the Request.
  7. Delete the request.
  8. complete the original request with the status code and information: -> BSOD because reference to the memory object.

Thanks again for the input!

On Fri, Sep 26, 2014 at 2:18 PM, Doron Holan > wrote:
This would probably because the new request takes a reference on the wdfmemory object of the parent request. When you complete a parent request we want to make sure you are not creating a hand grenade by leaving dangling references to memory. If the number of references on the WDFMEMORY in the request are >0, we stop with a WDF violation.

When you format the new request, that takes a reference on the parent request WDFMEMORY (assuming you pass it in). That reference through the format action is still there when the new request completes back to your driver. You can clear that reference by either

a) Deleting the new request

b) Reseting the request, thus clearing the format, thus releasing the reference

d

From: xxxxx@lists.osr.commailto:xxxxx [mailto:xxxxx@lists.osr.commailto:xxxxx] On Behalf Of Roscoe Casita
Sent: Friday, September 26, 2014 2:13 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] [Beginner] Send Async Write Request to Remote I/O Target

That is the summary. The important part is I dug around on msdn for a long time and still have not found information that dictates this usage.
On Sep 26, 2014 4:51 PM, > wrote:
Sorry, Ros… I stopped reading at the code and didn’t see the attached dump.

It’s weird. So, to summarize: if you reset the new request for reuse before deleting the object you’re “good to go” :slight_smile: but if you do not “reuse” the Request… It blue screens? Is that the summary?

Peter
OSR
@OSRDrivers


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


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


Thanks in advance,
Roscoe Casita
— 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>