Serial IOCTL Request transfer to CDC class request .

[Podun_Yu]

Dear team:

I am developing a USB virtual com port driver . It is a host client driver like usbser.sys.

When I got a IOCTL like a “IOCTL_SERIAL_SET_BAUD_RATE” ,I deal with it as follow steps :

1. WdfRequestRetrieveInputBuffer to get the Rate ,and save it in my driver
   2)Send down to lower driver (maybe hub or bus)
   /*for the reason I don’t know If bus driver understand this IOCTL ,so I do a Control transfer as follow */
   2.1)WDF_USB_CONTROL_SETUP_PACKET_INIT_CLASS (00100001,0x20,0,0)CDC Class
   (00100001 - host -dev , class , Interface)
   (0x20 is the “Set_Line_Coding” request in CDC Spec , for the reason baud rate in this request)

2.2)WdfUsbTargetDeviceFormatRequestForControlTransfer(WDFUSBDEVICE , Request , memory )
2.3)WdfSetCompleteRoutine()
2.4)WdfRequestSend()

I always got STATUS_UNSUCCESSFUL from complete routine .

Am I right that I processed the IOCTL like this?

Thanks for any advance!!

[Tim_Roberts]

xxxxx@hotmail.com wrote:

I am developing a USB virtual com port driver . It is a host client driver like usbser.sys.

When I got a IOCTL like a “IOCTL_SERIAL_SET_BAUD_RATE” ,I deal with it as follow steps :

1. WdfRequestRetrieveInputBuffer to get the Rate ,and save it in my driver
   2)Send down to lower driver (maybe hub or bus)
   /*for the reason I don’t know If bus driver understand this IOCTL ,so I do a Control transfer as follow */

Of course it doesn’t. The USB driver only understands URBs.

2.1)WDF_USB_CONTROL_SETUP_PACKET_INIT_CLASS (00100001,0x20,0,0)CDC Class
(00100001 - host -dev , class , Interface)
(0x20 is the “Set_Line_Coding” request in CDC Spec , for the reason baud rate in this request)

Well, your syntax there is a bit odd. A class-specific request going to
the interface would be 0x21 (00100001 in binary), but that’s not how you
specify it in the call.

WDF_USB_CONTROL_SETUP_PACKET_INIT_CLASS( &myPacket,
BMREQUEST_HOST_TO_DEVICE,
BMREQUEST_TO_INTERFACE,
SET_LINE_CODING,
0,
myInterfaceNumber
);

2.2)WdfUsbTargetDeviceFormatRequestForControlTransfer(WDFUSBDEVICE , Request , memory )
2.3)WdfSetCompleteRoutine()
2.4)WdfRequestSend()

I always got STATUS_UNSUCCESSFUL from complete routine .

Am I right that I processed the IOCTL like this?

Are you sure that your device supports the SET_LINE_CODING request? Are
you sending a 7-byte array with the request?

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

[Podun_Yu]

Thanks for your advance!

xxxxx@hotmail.com wrote:
> I am developing a USB virtual com port driver . It is a host client driver
like usbser.sys.
>
> When I got a IOCTL like a “IOCTL_SERIAL_SET_BAUD_RATE” ,I deal with it as
follow steps :
> 1) WdfRequestRetrieveInputBuffer to get the Rate ,and save it in my driver
> 2)Send down to lower driver (maybe hub or bus)
> /*for the reason I don’t know If bus driver understand this IOCTL ,so I
do a Control transfer as follow */
Of course it doesn’t. The USB driver only understands URBs.

Is that means I should transfer WDFREQUEST to URBs ? or call WdfUsbTargetPipeFormatRequestForUrb to format a URB?

> 2.1)WDF_USB_CONTROL_SETUP_PACKET_INIT_CLASS (00100001,0x20,0,0)CDC Class
> (00100001 - host -dev , class , Interface)
> (0x20 is the “Set_Line_Coding” request in CDC Spec , for the reason
baud rate in this request)

Well, your syntax there is a bit odd. A class-specific request going to
the interface would be 0x21 (00100001 in binary), but that’s not how you
specify it in the call.

WDF_USB_CONTROL_SETUP_PACKET_INIT_CLASS( &myPacket,
BMREQUEST_HOST_TO_DEVICE,
BMREQUEST_TO_INTERFACE,
SET_LINE_CODING,
0,
myInterfaceNumber
);

My code is like this :
1.ntStatus = WdfRequestRetrieveInputMemory(Request, &wdfMemoryReq);
2.WDF_USB_CONTROL_SETUP_PACKET_INIT_CLASS(&wdfSetupPacket,BmRequestHostToDevice,BmRequestToInterface,SET_LINE_CODING,0,0);
3.ntStatus = WdfUsbTargetDeviceFormatRequestForControlTransfer(WDFUsbdevice, Request,&wdfSetupPacket,wdfMemoryReq,NULL);
4.Setcomplete routine()
5.WDFRequestSend()

I don’t really know if my device support “SET_LINE_CODING = 0x20”. My device is a standard USB device. I just want the Lower driver to process the IOCTL request and return Successful.

> 2.2)WdfUsbTargetDeviceFormatRequestForControlTransfer(WDFUSBDEVICE ,
>Request , memory )
> 2.3)WdfSetCompleteRoutine()
> 2.4)WdfRequestSend()
>
> I always got STATUS_UNSUCCESSFUL from complete routine .
>
> Am I right that I processed the IOCTL like this?

Are you sure that your device supports the SET_LINE_CODING request? Are
you sending a 7-byte array with the request?

My device is standard USB device .I don’t know the BUS driver will process the WDFRequest. should I transfer IOCTL wdfRequest to URBs ? and what is the 7 byte array? Is that the setup packet ?

[Chris_Aseltine]

Podun Yu wrote:

I don’t really know if my device support “SET_LINE_CODING
= 0x20”. My device is a standard USB device. I just want the
Lower driver to process the IOCTL request and return Successful.

Amazing. If you don’t know if your device supports SET_LINE_CODING, how can you possibly develop a driver for it? There is no such thing as a “standard USB device”.

[Tim_Roberts]

xxxxx@hotmail.com wrote:

> xxxxx@hotmail.com wrote:
>> I am developing a USB virtual com port driver . It is a host client driver like usbser.sys.
>> When I got a IOCTL like a “IOCTL_SERIAL_SET_BAUD_RATE” ,I deal with it as follow steps :
>> 1) WdfRequestRetrieveInputBuffer to get the Rate ,and save it in my driver
>> 2)Send down to lower driver (maybe hub or bus)
>> /*for the reason I don’t know If bus driver understand this IOCTL ,so I do a Control transfer as follow */
>> Of course it doesn’t. The USB driver only understands URBs.
Is that means I should transfer WDFREQUEST to URBs ? or call WdfUsbTargetPipeFormatRequestForUrb to format a URB?

>> 2.1)WDF_USB_CONTROL_SETUP_PACKET_INIT_CLASS (00100001,0x20,0,0)CDC Class
>> (00100001 - host -dev , class , Interface)
>> (0x20 is the “Set_Line_Coding” request in CDC Spec , for the reason
> baud rate in this request)
> Well, your syntax there is a bit odd. A class-specific request going to
> the interface would be 0x21 (00100001 in binary), but that’s not how you
> specify it in the call.
> WDF_USB_CONTROL_SETUP_PACKET_INIT_CLASS( &myPacket,
> BMREQUEST_HOST_TO_DEVICE,
> BMREQUEST_TO_INTERFACE,
> SET_LINE_CODING,
> 0,
> myInterfaceNumber
> );
My code is like this :
1.ntStatus = WdfRequestRetrieveInputMemory(Request, &wdfMemoryReq);
2.WDF_USB_CONTROL_SETUP_PACKET_INIT_CLASS(&wdfSetupPacket,BmRequestHostToDevice,BmRequestToInterface,SET_LINE_CODING,0,0);
3.ntStatus = WdfUsbTargetDeviceFormatRequestForControlTransfer(WDFUsbdevice, Request,&wdfSetupPacket,wdfMemoryReq,NULL);
4.Setcomplete routine()
5.WDFRequestSend()

I don’t really know if my device support “SET_LINE_CODING = 0x20”. My device is a standard USB device. I just want the Lower driver to process the IOCTL request and return Successful.

>> 2.2)WdfUsbTargetDeviceFormatRequestForControlTransfer(WDFUSBDEVICE ,
>> Request , memory )
>> 2.3)WdfSetCompleteRoutine()
>> 2.4)WdfRequestSend()
>>
>> I always got STATUS_UNSUCCESSFUL from complete routine .
>>
>> Am I right that I processed the IOCTL like this?
> Are you sure that your device supports the SET_LINE_CODING request? Are
> you sending a 7-byte array with the request?
My device is standard USB device .I don’t know the BUS driver will process the WDFRequest. should I transfer IOCTL wdfRequest to URBs ? and what is the 7 byte array? Is that the setup packet ?

---

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

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

[Tim_Roberts]

xxxxx@hotmail.com wrote:

Is that means I should transfer WDFREQUEST to URBs ? or call WdfUsbTargetPipeFormatRequestForUrb to format a URB?

Your driver is a translator. You are receiving serial port requests
from above, and you are sending URBs down below. The drivers below are
all USB drivers. They don’t know ANYTHING about serial port requests.
When you get a serial port request, YOU have to translate that to a URB
to that will cause the equivalent action to happen in your device.

ONLY YOU know what your device’s capabilities are. ONLY YOU know
whether every request makes sense. If you get a serial port request
that has no meaning for your device, then you need to complete that
request. You can’t send it down, because the drivers below you don’t
speak serial port.

My code is like this :
1.ntStatus = WdfRequestRetrieveInputMemory(Request, &wdfMemoryReq);
2.WDF_USB_CONTROL_SETUP_PACKET_INIT_CLASS(&wdfSetupPacket,BmRequestHostToDevice,BmRequestToInterface,SET_LINE_CODING,0,0);
3.ntStatus = WdfUsbTargetDeviceFormatRequestForControlTransfer(WDFUsbdevice, Request,&wdfSetupPacket,wdfMemoryReq,NULL);
4.Setcomplete routine()
5.WDFRequestSend()

I don’t really know if my device support “SET_LINE_CODING = 0x20”. My device is a standard USB device. I just want the Lower driver to process the IOCTL request and return Successful.

The phrase “standard USB device” doesn’t mean anything. Only you can
know which requests your device understands. If your device is supposed
to be compliant with the USB Communication Device Class spec (which is
where serial port adapters would generally be), then it should be
honoring the set of standard requests that are outlined in the spec.
SET_LINE_CODING is one of those requests, although support is optional.

What, exactly, is your device?

> Are you sure that your device supports the SET_LINE_CODING request? Are
> you sending a 7-byte array with the request?
My device is standard USB device .I don’t know the BUS driver will process the WDFRequest. should I transfer IOCTL wdfRequest to URBs ? and what is the 7 byte array? Is that the setup packet ?

Are you just guessing at all of this? Trying things at random and
hoping that they work? The behavior of a USB serial port adapter is
spelled out quite clearly in the USB Communication Device Class
specification, available for free from the USB Implementor’s Forum at
www.usb.org. All of the standard requests that a CDC device can/must
support are listed there, along with the format of those requests. If
you have not read the CDC specification, then you have no business
writing a driver for such a device.

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

[Fredrik_H]

This thread seems to be the place where I should ask my question too.
I am also developing a USB virtual com port driver like usbser.sys and I have a question about the IOCTL request: IOCTL_SERIAL_SET_DTR.

I know that this is for the Data Terminal Ready signal for RS-232 ports. But I can’t understand what to do with it in my case. I guess I must (like all the other serial IOCTL requests) transform it to some kind of CDC class request. But what is the CDC class request I should transform it to? I can’t find any feasible request in the usb CDC specification. Or what should I do with it?
Any suggestion is welcome!

[Igor_Sharovar]

>I am also developing a USB virtual com port driver like usbser.sys and I have a question about >the IOCTL request: IOCTL_SERIAL_SET_DTR. I know that this is for the Data Terminal Ready >signal for RS-232 ports. But I can’t understand what to do with it in my case. I guess I must (like >all the other serial IOCTL requests) transform it to some kind of CDC class request. But what is >the CDC class request I should transform it to? I can’t find any feasible request in the usb CDC >specification. Or what should I do with it?

Look at SET_CONTROL_LINE_STATE request, bit D0.

Igor Sharovar

[Fredrik_H]

I have some problems leading to a BSOD.
I’m working on translating the serial IOCTL SET_DTR to a usb CDC request. Here are some of my code:

case IOCTL_SERIAL_SET_DTR:
//@todo This is causing a BSOD!

WDF_USB_CONTROL_SETUP_PACKET_INIT_CLASS(&packet,
BmRequestHostToDevice,
BmRequestToInterface,
0x22,
0x0001,
0);

status = WdfUsbTargetDeviceFormatRequestForControlTransfer(pDevCtx->UsbDevice, request, &packet, NULL, NULL);
if(!NT_SUCCESS(status))
{
KdPrint((DRIVER_NAME “WdfUsbTargetDeviceFormatRequestForControlTransfer failed with status 0x%08x\n”, status));
break;
}

WdfRequestSetCompletionRoutine(request, SerialRequestComplete, NULL);

if(WdfRequestSend(request, WdfDeviceGetIoTarget(device), WDF_NO_SEND_OPTIONS) == FALSE)
{
status = WdfRequestGetStatus(request);
KdPrint((DRIVER_NAME “WdfRequestSend failed with status 0x%08x\n”, status));
break;
}
break;

the value 0x22 is for the CDC request type SET_CONTROL_LINE_STATE and the value 0x0001 is for setting RTS = 0 and DTR = 1. (Right?)

I have not used WdfRequestRetriveInputMemory because I think that no buffer is needed, in this case. But I have also tried too use it but it fails with the error code: 0xC0000023 (aka STATUS_BUFFER_TOO_SMALL).

The line causing the BSOD seems to be:
status = WdfUsbTargetDeviceFormatRequestForControlTransfer(pDevCtx->UsbDevice, request, &packet, NULL, NULL);
And I can’t understand why it happens. Can you guys see if I’m missing something or if I missunderstands it totaly?

[Scott_Noone_OSR]

wrote in message news:xxxxx@ntdev…
> I have some problems leading to a BSOD.

Let me be the first to say it: post the !analyze -v output so that we don’t
have to guess what the crash is.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntdev…
> I have some problems leading to a BSOD.
> I’m working on translating the serial IOCTL SET_DTR to a usb CDC request.
> Here are some of my code:
>
> case IOCTL_SERIAL_SET_DTR:
> //@todo This is causing a BSOD!
>
> WDF_USB_CONTROL_SETUP_PACKET_INIT_CLASS(&packet,
> BmRequestHostToDevice,
> BmRequestToInterface,
> 0x22,
> 0x0001,
> 0);
>
> status =
> WdfUsbTargetDeviceFormatRequestForControlTransfer(pDevCtx->UsbDevice,
> request, &packet, NULL, NULL);
> if(!NT_SUCCESS(status))
> {
> KdPrint((DRIVER_NAME “WdfUsbTargetDeviceFormatRequestForControlTransfer
> failed with status 0x%08x\n”, status));
> break;
> }
>
> WdfRequestSetCompletionRoutine(request, SerialRequestComplete, NULL);
>
> if(WdfRequestSend(request, WdfDeviceGetIoTarget(device),
> WDF_NO_SEND_OPTIONS) == FALSE)
> {
> status = WdfRequestGetStatus(request);
> KdPrint((DRIVER_NAME “WdfRequestSend failed with status 0x%08x\n”,
> status));
> break;
> }
> break;
>
>
> the value 0x22 is for the CDC request type SET_CONTROL_LINE_STATE and the
> value 0x0001 is for setting RTS = 0 and DTR = 1. (Right?)
>
> I have not used WdfRequestRetriveInputMemory because I think that no
> buffer is needed, in this case. But I have also tried too use it but it
> fails with the error code: 0xC0000023 (aka STATUS_BUFFER_TOO_SMALL).
>
> The line causing the BSOD seems to be:
> status =
> WdfUsbTargetDeviceFormatRequestForControlTransfer(pDevCtx->UsbDevice,
> request, &packet, NULL, NULL);
> And I can’t understand why it happens. Can you guys see if I’m missing
> something or if I missunderstands it totaly?
>

[Fredrik_H]

> Let me be the first to say it: post the !analyze -v output so that we

don’t have to guess what the crash is.

And what is that and where do I find it?

[Gregory_G_Dyess]

Try the “Alternate Career Path” section in your local library…

— xxxxx@hotmail.com wrote:

From: xxxxx@hotmail.com
To: “Windows System Software Devs Interest List”
Subject: RE:[ntdev] Serial IOCTL Request transfer to CDC class request .
Date: Tue, 20 Jul 2010 10:17:45 -0400 (EDT)

> Let me be the first to say it: post the !analyze -v output so that we
> don’t have to guess what the crash is.

And what is that and where do I find it?

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

[Scott_Noone_OSR]

Install WinDBG:

http://www.microsoft.com/whdc/devtools/debugging/default.mspx

And read the kernel_debugging_tutorial.doc file that gets installed with it.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntdev…
>> Let me be the first to say it: post the !analyze -v output so that we
>> don’t have to guess what the crash is.
>
> And what is that and where do I find it?
>

[Tim_Roberts]

xxxxx@hotmail.com wrote:

I have some problems leading to a BSOD.
I’m working on translating the serial IOCTL SET_DTR to a usb CDC request. Here are some of my code:
…
the value 0x22 is for the CDC request type SET_CONTROL_LINE_STATE and the value 0x0001 is for setting RTS = 0 and DTR = 1. (Right?)

I have not used WdfRequestRetriveInputMemory because I think that no buffer is needed, in this case. But I have also tried too use it but it fails with the error code: 0xC0000023 (aka STATUS_BUFFER_TOO_SMALL).

Does that ioctl provide an input buffer? If not, then why would you
expect to be able to retrieve one?

The line causing the BSOD seems to be:
status = WdfUsbTargetDeviceFormatRequestForControlTransfer(pDevCtx->UsbDevice, request, &packet, NULL, NULL);

Why does that “seem” to be the line? What was the bugcheck code? Did
you do an !analyze -v? How is “packet” declared?

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

[Gary_Little-3]

Well, dude, or dudette, whichever the case may be, that rejoinder gives us
an excellent evaluation of where you stand in developing drivers. First
thing you need to do is connect a system running WinDbg, then run !analyze
-v in WinDbg.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Tuesday, July 20, 2010 9:18 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Serial IOCTL Request transfer to CDC class request .

Let me be the first to say it: post the !analyze -v output so that we
don’t have to guess what the crash is.

And what is that and where do I find it?

---

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

[Maxim_S_Shatskih]

> an excellent evaluation of where you stand in developing drivers. First

thing you need to do is connect a system running WinDbg, then run !analyze
-v in WinDbg.

Reading about IRQLs is one more major point.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

[Fredrik_H]

> Does that ioctl provide an input buffer? If not, then why would you

expect to be able to retrieve one?

I see your point there…

Why does that “seem” to be the line? What was the bugcheck code? Did
you do an !analyze -v? How is “packet” declared?

Because the driver goes so far every time before crashing the system. And no, I have not done the !analyze -v yet, but I will do it today.

Packet is declared:
WDF_USB_CONTROL_SETUP_PACKET packet;

Correct?

[Fredrik_H]

Here are a !analyze -v output on the dump file created when BSOD occoured:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Loading Dump File [C:\windows\Minidump\Mini072110-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: C:\WinDDK\7600.16385.1\src\MyDrivers\mydriver\objchk_wxp_x86\i386;C:\windows\symbols\sys;C:\windows\symbols\dll;C:\windows\symbols\exe;
Executable search path is: C:\windows\system32\drivers
Unable to load image ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Windows XP Kernel Version 2600 (Service Pack 3) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055d720
Debug session time: Wed Jul 21 09:18:27.000 2010 (UTC + 2:00)
System Uptime: 0 days 17:42:54.657
Unable to load image ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Loading Kernel Symbols
…
…
Loading User Symbols
Loading unloaded module list
…
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck C9, {7, b94349ec, 89e76eb8, 0}

*** ERROR: Module load completed but symbols could not be loaded for wdf01000.sys
Probably caused by : mydriver.sys ( mydriver!WdfRequestCompleteWithInformation+1d )

Followup: MachineOwner

1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)
The IO manager has caught a misbehaving driver.
Arguments:
Arg1: 00000007, IRP passed to IoCompleteRequest still has cancel routine set
Arg2: b94349ec, the cancel routine pointer
Arg3: 89e76eb8, the IRP
Arg4: 00000000

Debugging Details:

BUGCHECK_STR: 0xc9_7

DRIVER_VERIFIER_IO_VIOLATION_TYPE: 7

IRP_CANCEL_ROUTINE:
USBPORT!USBPORT_CancelActiveTransferIrp+0
b94349ec 8bff mov edi,edi

FAULTING_IP:
USBPORT!USBPORT_CancelActiveTransferIrp+0
b94349ec 8bff mov edi,edi

FOLLOWUP_IP:
mydriver!WdfRequestCompleteWithInformation+1d [c:\winddk\7600.16385.1\inc\wdf\kmdf\1.9\wdfrequest.h @ 1038]
ba3b933d 5d pop ebp

IRP_ADDRESS: 89e76eb8

DEVICE_OBJECT: 88d68030

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: rundll32.exe

LAST_CONTROL_TRANSFER: from 8065885c to 804f9f43

STACK_TEXT:
a6b3166c 8065885c 000000c9 00000007 b94349ec nt!_woutput+0x414
a6b316e8 a69c5d6b 87feecd0 87fbd4d8 00000000 nt!HvpReadFileImageAndBuildMap+0x172
WARNING: Stack unwind information not available. Following frames may be wrong.
a6b31710 a69b8983 00000000 00000002 87feedbc wdf01000+0x22d6b
a6b31728 ba3b933d 00000000 87fbd4d8 00000000 wdf01000+0x15983
a6b31740 ba3bb647 78042b20 00000000 00000000 mydriver!WdfRequestCompleteWithInformation+0x1d [c:\winddk\7600.16385.1\inc\wdf\kmdf\1.9\wdfrequest.h @ 1038]
a6b31780 a69d2072 78011328 78042b20 00000000 mydriver!EvtIoDeviceControl+0x317 [c:\winddk\7600.16385.1\src\mydrivers\mydriver\ioctl.c @ 315]
a6b317a4 a69d33d0 78011328 78042b20 00000000 wdf01000+0x2f072
a6b317d4 a69d59ac 78042b20 87fbd4d8 87feecd0 wdf01000+0x303d0
a6b317f0 a69d6a36 87feec00 00000000 87f42eb0 wdf01000+0x329ac
a6b31810 a69d8824 87fbd4d8 87eb92d0 87f34f38 wdf01000+0x33a36
a6b31834 a69c7a3f 89e76eb8 a6b31874 804ef19f wdf01000+0x35824
a6b31840 804ef19f 87eb92d0 89e76eb8 806e6428 wdf01000+0x24a3f
a6b31874 80662b28 87f07be8 89233748 00000000 nt!MiFlushSectionInternal+0x256
a6b31888 804ef19f 87f07be8 89e76eb8 806e6428 nt!MiRemovePhysicalMemory+0x34c
a6b318bc ba38a4b2 00000001 87ff6760 00040000 nt!MiFlushSectionInternal+0x256
a6b318e4 ba38ac7a 87ff6760 00000001 87ff6888 Modem!SetDtr+0x4c
a6b31a1c ba38add4 87ff6760 8a002e90 87ff66a8 Modem!UniOpenStarter+0x4b4
a6b31a38 804ef19f 87ff66a8 8a002e90 806e6428 Modem!UniOpen+0x50
a6b31a6c 805831fa 87e38358 87f879ec a6b31c04 nt!MiFlushSectionInternal+0x256
a6b31b4c 805bf434 87e38370 00000000 87f87948 nt!SeQueryInformationToken+0x11e
a6b31bc4 805bb9c0 00000000 a6b31c04 00000040 nt!MiFindExportedRoutineByName+0x52
a6b31c18 80576033 00000000 00000000 00000001 nt!IopInitializeDCB+0x96
a6b31c94 805769aa 018f951c c0100080 018f94bc nt!SeAssignSecurity+0xa
a6b31cf0 805790b4 018f951c c0100080 018f94bc nt!SepDuplicateToken+0x22a
a6b31d30 8054163c 018f951c c0100080 018f94bc nt!SeAccessCheckByType+0x638
a6b31d64 7c90e514 badb0d00 018f9484 a72c9d98 nt!RtlIpv4StringToAddressExW+0xbd
a6b31d78 00000000 00000000 00000000 00000000 0x7c90e514

STACK_COMMAND: kb

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: 4

SYMBOL_NAME: mydriver!WdfRequestCompleteWithInformation+1d

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: mydriver

IMAGE_NAME: mydriver.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4c4693be

FAILURE_BUCKET_ID: 0xc9_7_mydriver!WdfRequestCompleteWithInformation+1d

BUCKET_ID: 0xc9_7_mydriver!WdfRequestCompleteWithInformation+1d

Followup: MachineOwner

1: kd> !devobj ffffffff88d68030 f
80562ed8: Unable to get value of ObpRootDirectoryObject
88d68030: Could not read device object or _DEVICE_OBJECT not found
1: kd> lmvm mydriver
start end module name
ba3b8000 ba3bc800 mydriver (private pdb symbols) c:\winddk\7600.16385.1\src\mydrivers\mydriver\objchk_wxp_x86\i386\mydriver.pdb
Loaded symbol image file: mydriver.sys
Mapped memory image file: C:\windows\system32\drivers\mydriver.sys
Image path: mydriver.sys
Image name: mydriver.sys
Timestamp: Wed Jul 21 08:29:18 2010 (4C4693BE)
CheckSum: 0001457C
ImageSize: 00004800
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

First of all, anyone know where to find symbols for wdf01000.sys? I tried to download symbols from http://go.microsoft.com/fwlink/?LinkId=79331
but it didn’t help. I also googled it but I don’t find any helpfull information.

Second, my problem seems to be with the completion of the request (or do I missunderstand this too?)
If so, why can’t I use the WdfRequestCompleteWithInformation function in the completion callback, or is it something else making this error?

[Chris_Aseltine]

Fredrik H wrote:

Second, my problem seems to be with the completion
of the request (or do I missunderstand this too?)

Well, frankly, what I don’t understand is that you’re completing the request but the stack backtrace indicates that you’re doing it in the context of the original request from modem.sys to set the DTR.

Are you sending this IRP synchronously? Is there a possibility you’re double completing it somehow? Post your entire IOCTL handler from ioctl.c, I bet you are sending the request down and then completing it at the same time at the bottom of your switch/case on the IOCTL code.

[Fredrik_H]

Thanks Chris, you are absolutly right, I have missed to set a flag so it won’t complete it at the end of my function.
Thanks…