Hello,
My goal is to create a WDFREQUEST, copy the data from another existing WDFREQUEST object and send it to my IO Target (rudimentary disk mirroring). Once I create the WDFREQUEST object, how can I copy the data from the existing WDFREQUEST to this newly created Request object?
Thanks,
Rajib
xxxxx@intel.com wrote:
My goal is to create a WDFREQUEST, copy the data from another existing WDFREQUEST object and send it to my IO Target (rudimentary disk mirroring). Once I create the WDFREQUEST object, how can I copy the data from the existing WDFREQUEST to this newly created Request object?
There are no shortcuts for this. What are the important fields in the
original IRP? Those are the fields you need to set up. Is this at the
SRB level? Are you going to reuse the SRB or create a new one?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
My driver is lower disk class filter driver. I want to send the same SRB to a different disk.
Is it right to use the WdfRequestCreateFromIrp method using a different IO target?
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, January 15, 2013 10:58 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] How to copy WDFREQUEST
xxxxx@intel.com wrote:
My goal is to create a WDFREQUEST, copy the data from another existing WDFREQUEST object and send it to my IO Target (rudimentary disk mirroring). Once I create the WDFREQUEST object, how can I copy the data from the existing WDFREQUEST to this newly created Request object?
There are no shortcuts for this. What are the important fields in the original IRP? Those are the fields you need to set up. Is this at the SRB level? Are you going to reuse the SRB or create a new one?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
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
Ghosal, Rajib wrote:
My driver is lower disk class filter driver. I want to send the same SRB to a different disk.
Is it right to use the WdfRequestCreateFromIrp method using a different IO target?
Are you sending both requests at the same time? Here’s the potential
issue. A WDFREQUEST does not actually contain an IRP. It contains a
pointer to an IRP. When you call WdfRequestCreateFromIrp, the
WDFREQUEST that you get points to the IRP you pass in. You would thus
end up with two WDFREQUESTs that both wrap the same IRP. If you submit
them both at once, the result would not be happy.
When you call WdfRequestCreate, that creates a new IRP, so there is no
such conflict.
So, you’ll either call WdfRequestCreate and configure it to match the
parameters in the existing request, or you can create your own IRP,
populate it to match, and then call WdfRequestCreateFromIrp, but that
seems silly.
On the other hand, disk drivers are not my primary area, so there may be
subtleties I’m missing.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I want to send the request to the another target from the completion routine of the original IO. So to answer your question, I am not sending it at the same time. I will be sending one by one.
So what I am understanding now, I need to do the following:
Thanks,
Rajib
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, January 15, 2013 11:16 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] How to copy WDFREQUEST
Ghosal, Rajib wrote:
My driver is lower disk class filter driver. I want to send the same SRB to a different disk.
Is it right to use the WdfRequestCreateFromIrp method using a different IO target?
Are you sending both requests at the same time? Here’s the potential issue. A WDFREQUEST does not actually contain an IRP. It contains a pointer to an IRP. When you call WdfRequestCreateFromIrp, the WDFREQUEST that you get points to the IRP you pass in. You would thus end up with two WDFREQUESTs that both wrap the same IRP. If you submit them both at once, the result would not be happy.
When you call WdfRequestCreate, that creates a new IRP, so there is no such conflict.
So, you’ll either call WdfRequestCreate and configure it to match the parameters in the existing request, or you can create your own IRP, populate it to match, and then call WdfRequestCreateFromIrp, but that seems silly.
On the other hand, disk drivers are not my primary area, so there may be subtleties I’m missing.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
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 is one area where it’s just simpler (to me) to use WDM. In your completion routine, create a new IRP and MDL, copy the contents from the original IRP->MDL to the new MDL complete your original request (since you don’t want to add latency while sending the copy to your “other device”, then send the new IRP to the “other device”.
Of course, this depends on the type of CDB you’re copying to the new device. For READ, obviously do this from the completion routine, for a WRITE you’ll want to do this a little differently but you can figure that part out.
~kenny
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Ghosal, Rajib
Sent: Tuesday, January 15, 2013 1:27 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to copy WDFREQUEST
I want to send the request to the another target from the completion routine of the original IO. So to answer your question, I am not sending it at the same time. I will be sending one by one.
So what I am understanding now, I need to do the following:
Thanks,
Rajib
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, January 15, 2013 11:16 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] How to copy WDFREQUEST
Ghosal, Rajib wrote:
My driver is lower disk class filter driver. I want to send the same SRB to a different disk.
Is it right to use the WdfRequestCreateFromIrp method using a different IO target?
Are you sending both requests at the same time? Here’s the potential issue. A WDFREQUEST does not actually contain an IRP. It contains a pointer to an IRP. When you call WdfRequestCreateFromIrp, the WDFREQUEST that you get points to the IRP you pass in. You would thus end up with two WDFREQUESTs that both wrap the same IRP. If you submit them both at once, the result would not be happy.
When you call WdfRequestCreate, that creates a new IRP, so there is no such conflict.
So, you’ll either call WdfRequestCreate and configure it to match the parameters in the existing request, or you can create your own IRP, populate it to match, and then call WdfRequestCreateFromIrp, but that seems silly.
On the other hand, disk drivers are not my primary area, so there may be subtleties I’m missing.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
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
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
Ghosal, Rajib wrote:
I want to send the request to the another target from the completion routine of the original IO. So to answer your question, I am not sending it at the same time. I will be sending one by one.
So what I am understanding now, I need to do the following:
- Get the parameters from the exiting IO request using WdfRequestGetParameters()
2 . Create WdfRequestCreate()- Assign the param from step 1 to the request object in step 2. What function/or how can I do this ?
Look, you have to KNOW this. It depends on the request. I’ll give you
an example. For a USB request, there are only about three IRP fields
that are of any interest at all: the major function, the ioctl code, and
Parameters.Others.Argument1 which points to the URB. Everything else of
interest is contained in the URB. It is my impression that SRBs are
similar; the SRB is contained in Parameters.Scsi.Srb, and everything
else you need is in there.
Kenny’s advice is also worth considering. KMDF does not contain any
specific routines for dealing with SRBs, so you may find it easier to
working directly with IRPs instead.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
The SRB is available from params.Parameters.Others.Arg1 where param is the WDF_REQUEST_PARAMETRS. The SRB is intercepted from the EvtIoInternalDeviceControl .
Is there any way to assign the parameters to a newly created WDFREQUEST ?
WDF presents a WdfRequestCreate() function, what APIs can we use to assign fileds to the WDF REQUEST ?
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, January 15, 2013 12:01 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] How to copy WDFREQUEST
Ghosal, Rajib wrote:
I want to send the request to the another target from the completion routine of the original IO. So to answer your question, I am not sending it at the same time. I will be sending one by one.
So what I am understanding now, I need to do the following:
- Get the parameters from the exiting IO request using
WdfRequestGetParameters()
2 . Create WdfRequestCreate()- Assign the param from step 1 to the request object in step 2. What function/or how can I do this ?
Look, you have to KNOW this. It depends on the request. I’ll give you an example. For a USB request, there are only about three IRP fields that are of any interest at all: the major function, the ioctl code, and
Parameters.Others.Argument1 which points to the URB. Everything else of interest is contained in the URB. It is my impression that SRBs are similar; the SRB is contained in Parameters.Scsi.Srb, and everything else you need is in there.
Kenny’s advice is also worth considering. KMDF does not contain any specific routines for dealing with SRBs, so you may find it easier to working directly with IRPs instead.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
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
Ghosal, Rajib wrote:
Is there any way to assign the parameters to a newly created WDFREQUEST ?
WDF presents a WdfRequestCreate() function, what APIs can we use to assign fileds to the WDF REQUEST ?
WdfRequestWdmGetIrp gets you the IRP. You can then call
IoGetNextIrpStackLocation and do what you need there.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hello,
I am now creating a WDFREQUEST using WdfRequestCreateFromIrp() function. I get the original IO’s irp by calling WdfRequestWdmGetIrp() s follows:
pWdmIrp = WdfRequestWdmGetIrp(Request);
status = WdfRequestCreateFromIrp( WDF_NO_OBJECT_ATTRIBUTES, pWdmIrp, TRUE, &newRequest);
Then send the request as follows:
WdfRequestFormatRequestUsingCurrentType(Request);
WdfRequestSetCompletionRoutine(Request, CompletionRoutine,CompletionContext);
WdfRequestSend(Request, IoTarget, NULL);
It is giving a BSOD in WdfRequestSend pasted below.
My question is, when I create the WDFREQUEST using WdfRequestCreateFromIrp() does it copy the databuffer and all the fields from the original IRP?
Thanks,
Rajib
Use !analyze -v to get detailed debugging information.
BugCheck D1, {6, 2, 0, 887a5b82}
Probably caused by : wdffltr.sys ( wdffltr!WdfRequestSend+1d )
nt!RtlpBreakWithStatusInstruction:
82685840 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: 00000006, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 887a5b82, address which referenced memory
READ_ADDRESS: 00000006
CURRENT_IRQL: 2
FAULTING_IP:
ataport!IdePortSetupMappedDataBuffer+c
887a5b82 f6400605 test byte ptr [eax+6],5
DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO
BUGCHECK_STR: 0xD1
PROCESS_NAME: System
TRAP_FRAME: 80786238 – (.trap 0xffffffff80786238)
ErrCode = 00000000
eax=00000000 ebx=855480e0 ecx=85649718 edx=889ec140 esi=85649718 edi=8552c0e8
eip=887a5b82 esp=807862ac ebp=807862b0 iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00210202
ataport!IdePortSetupMappedDataBuffer+0xc:
887a5b82 f6400605 test byte ptr [eax+6],5 ds:0023:00000006=??
Resetting default scope
LOCK_ADDRESS: 82772be0 – (!locks 82772be0)
Resource @ nt!PiEngineLock (0x82772be0) Exclusively owned
Contention Count = 1
Threads: 848c2d48-01<*>
1 total locks, 1 locks currently held
PNP_TRIAGE:
Lock address : 0x82772be0
Thread Count : 1
Thread address: 0x848c2d48
Thread wait : 0x104
LAST_CONTROL_TRANSFER: from 826e9ffb to 82685840
STACK_TEXT:
80785e04 826e9ffb 00000003 82521bba 00000065 nt!RtlpBreakWithStatusInstruction
80785e54 826eaaf9 00000003 00000006 887a5b82 nt!KiBugCheckDebugBreak+0x1c
80786218 8264bcdb 0000000a 00000006 00000002 nt!KeBugCheck2+0x68b
80786218 887a5b82 0000000a 00000006 00000002 nt!KiTrap0E+0x2cf
807862b0 887a5dca 855480e0 85649718 807862e8 ataport!IdePortSetupMappedDataBuffer+0xc
807862c0 887a60ba 855480e0 85649718 855480e0 ataport!IdePortMapBuffers+0x36
807862e8 887a5b6b 85649718 85649718 855480e0 ataport!IdeStartIoCallBack+0x22
807862fc 887a604d 855480e0 85649700 85649718 ataport!IdePortSetupScatterGatherList+0x43
80786314 887a4a1e 855480e0 85649718 8552c0e8 ataport!IdeDispatchChannelRequest+0x59
8078632c 887a4def 855480e0 85649718 8564f52c ataport!IdeStartChannelRequest+0x42
80786350 887a5fb4 0052c0e8 00649718 856445d8 ataport!IdeStartDeviceRequest+0x15d
80786370 887a246b 00000103 85648d58 80786398 ataport!IdePortPdoDispatch+0x9a
80786380 82641c29 8552c030 85648d58 856445d8 ataport!IdePortDispatch+0x1d
80786398 8881f01a 85606ad8 85645010 85644218 nt!IofCallDriver+0x63
807863c0 88fbe98d 85606bc0 85645010 856445d8 Wdf01000!imp_WdfRequestSend+0x33c
807863d8 88fbea32 7a9bafe8 7a9bba20 00000000 wdffltr!WdfRequestSend+0x1d [c:\winddk\7600.16385.1\inc\wdf\kmdf\1.9\wdfrequest.h @ 661]
807863f8 88fbe7f0 7a9bbfe8 7a9bafe8 88fbe680 wdffltr!WdfFltrForwardRequestWithCompletion+0x72 [c:\sharedfolder\wdffltr_v10\filter\wdffltr.cpp @ 1798]
80786484 88820807 7a9bbde0 7a9bafe8 8564f52c wdffltr!WdfFltrInternalDeviceControl+0xe0 [c:\sharedfolder\wdffltr_v10\filter\wdffltr.cpp @ 1630]
807864c4 88820fd8 7a9bafe8 8078650c 85645010 Wdf01000!FxIoQueue::DispatchRequestToDriver+0x463
807864e4 88827438 85644200 00000000 85644218 Wdf01000!FxIoQueue::DispatchEvents+0x4af
80786504 88821eb5 85644200 85645010 856440d4 Wdf01000!FxIoQueue::QueueRequest+0x204
80786538 88820310 85648d58 856447e0 85648d58 Wdf01000!FxPkgIo::Dispatch+0x3ba
80786560 8881fe7e 006447e0 85648d58 85650008 Wdf01000!FxDevice::Dispatch+0x155
8078657c 82641c29 856447e0 85648d58 8564f480 Wdf01000!FxDevice::DispatchWithLock+0x77
80786594 88d915a4 85648d58 8564f480 807865e4 nt!IofCallDriver+0x63
807865a4 88d90fe8 856447e0 85645b80 85650008 CLASSPNP!SubmitTransferPacket+0x103
807865e4 88d91303 00000000 00648d58 00000000 CLASSPNP!ServiceTransferRequest+0x225
8078660c 88d913bf 85645ac8 00000000 85645ac8 CLASSPNP!ClassReadWrite+0x172
80786620 82641c29 85645ac8 85648d58 85651000 CLASSPNP!ClassGlobalDispatch+0x20
80786638 8260c64b 00000200 85645e48 85645b80 nt!IofCallDriver+0x63
80786670 88e238fb 00000054 807866ac 00000000 nt!HalExamineMBR+0x91
807866b0 88da5f48 85645ac8 8564c59c 00000000 disk!DiskInitFdo+0x16d
807866d8 88da3f5c 01645ac8 8564c5b8 8564c4c0 CLASSPNP!ClassPnpStartDevice+0x305
80786704 88d913bf 85645ac8 0164c4c0 85645ac8 CLASSPNP!ClassDispatchPnp+0x30e
80786718 82641c29 85645ac8 8564c4c0 8564c5dc CLASSPNP!ClassGlobalDispatch+0x20
80786730 827c66ca 80786784 85645818 00000000 nt!IofCallDriver+0x63
8078675c 8893a985 85645ac8 8564c4c0 85645818 nt!IoForwardIrpSynchronously+0x59
807867c4 8893fe02 85645760 8564c4c0 8564c5e4 partmgr!PmStartDevice+0x58
807867e4 88939152 85645760 00000000 85645760 partmgr!PmPnp+0xe4
807867f8 82641c29 85645760 8564c4c0 80786880 partmgr!PmGlobalDispatch+0x1d
80786810 827ca7a0 00000000 8552c030 807868d0 nt!IofCallDriver+0x63
8078682c 8261d2bb 8078685c 8261315d 807868d0 nt!PnpAsynchronousCall+0x92
80786890 827c172f 8261315d 807868d0 8554eb80 nt!PnpStartDevice+0xe1
807868ec 827c14d2 8554eb80 0000004b 00000000 nt!PnpStartDeviceNode+0x252
80786908 827c8ee5 00000000 00000000 00000000 nt!PipProcessStartPhase1+0x62
80786b04 8261fc0c 848c1518 00000000 80786b40 nt!PipProcessDevNodeTree+0x188
80786b4c 8261f284 00000000 85640bc8 899a0a20 nt!PnpDeviceActionWorker+0x120
80786b64 829a8e3d 00000000 00000000 00000000 nt!PnpRequestDeviceAction+0x11a
80786bdc 829bd08d 8080a188 00000007 8080a188 nt!IopInitializeBootDrivers+0x3cc
80786c64 829c11c3 0080a188 848c20b8 848c2d48 nt!IoInitSystem+0x5ba
80786d48 827984c6 80786d90 8281507a 8080a188 nt!Phase1InitializationDiscard+0xd01
80786d50 8281507a 8080a188 8252287e 00000000 nt!Phase1Initialization+0xd
80786d90 826bb819 827984b9 8080a188 00000000 nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19
STACK_COMMAND: kb
FOLLOWUP_IP:
wdffltr!WdfRequestSend+1d [c:\winddk\7600.16385.1\inc\wdf\kmdf\1.9\wdfrequest.h @ 661]
88fbe98d 5d pop ebp
FAULTING_SOURCE_LINE: c:\winddk\7600.16385.1\inc\wdf\kmdf\1.9\wdfrequest.h
FAULTING_SOURCE_FILE: c:\winddk\7600.16385.1\inc\wdf\kmdf\1.9\wdfrequest.h
FAULTING_SOURCE_LINE_NUMBER: 661
FAULTING_SOURCE_CODE:
657: PWDF_REQUEST_SEND_OPTIONS Options
658: )
659: {
660: return ((PFN_WDFREQUESTSEND) WdfFunctions[WdfRequestSendTableIndex])(WdfDriverGlobals, Request, Target, Options);
661: }
662:
663: //
664: // WDF Function: WdfRequestGetStatus
665: //
666: typedef
SYMBOL_STACK_INDEX: f
SYMBOL_NAME: wdffltr!WdfRequestSend+1d
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: wdffltr
IMAGE_NAME: wdffltr.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 50f703d8
FAILURE_BUCKET_ID: 0xD1_wdffltr!WdfRequestSend+1d
BUCKET_ID: 0xD1_wdffltr!WdfRequestSend+1d
xxxxx@intel.com wrote:
I am now creating a WDFREQUEST using WdfRequestCreateFromIrp() function. I get the original IO’s irp by calling WdfRequestWdmGetIrp() s follows:
pWdmIrp = WdfRequestWdmGetIrp(Request);
status = WdfRequestCreateFromIrp( WDF_NO_OBJECT_ATTRIBUTES, pWdmIrp, TRUE, &newRequest);Then send the request as follows:
WdfRequestFormatRequestUsingCurrentType(Request);
WdfRequestSetCompletionRoutine(Request, CompletionRoutine,CompletionContext);
WdfRequestSend(Request, IoTarget, NULL);It is giving a BSOD in WdfRequestSend pasted below.
Didn’t you mean to use newRequest in those last three calls? Where did
you get the IoTarget for the other device?
My question is, when I create the WDFREQUEST using WdfRequestCreateFromIrp() does it copy the databuffer and all the fields from the original IRP?
I think I advised you to do this, didn’t I? Having learned more about
what you’re doing, this may have been bad advice.
Remember that a WDFREQUEST is just a carrier. It doesn’t contain ANY of
the IRP fields. Instead, it contains a pointer to the IRP. When you
call WdfRequestRetrieveOutputBuffer, it doesn’t fetch that from the
WDFREQUEST. Instead, it gets the IRP from the WDFREQUEST and gets the
buffer from the IRP.
So, in this case, the new request will wrap the original IRP. You’re
just sending that IRP on another trip. That’s OK, as long as that IRP
doesn’t get completed in the meantime. When the IRP is completed, the
buffers are unlocked and the IRP’s memory is freed up.
You mentioned that you wanted to be able to complete the first IRP while
you finished the mirror operation. I’m not convinced that’s possible.
You need the buffers to stay valid while the mirror operation happens,
and that’s only possible if the IRP sticks around.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.