IoGetDeviceProperty fails on an FTDI VCP

Manu_Bansal · August 5, 2009, 11:24pm

Hi,

I’m trying to query the device properties of an FTDI-created virtual comm port from a kernel mode driver. I’m calling IoGetDeviceProperty on a PDO obtained by traversing the device stack of the VCP starting with the top-level device object obtained from IoGetDeviceObjectPointer. Property calls always fail with STATUS_INVALID_DEVICE_REQUEST (0xc0000010).

My code seems fine because it works on other serial interfaces (a modem interface and a real serial interface). Am I missing something with the FTDI virtual serial port?

Thanks.

P.S.: Why does FTDI provide a serial comm API for their devices? Isn’t regular win32 serial API enough?

Doron_Holan · August 6, 2009, 1:05am

you sure it is a pnp device stack? What does !devstack say?
2) what do you mean by traversing the device stack to find the PDO? Are you issuing a IRP_MJ_PNP/IRP_MN_QUERY_DEVICE_RELATIONS(TargetDeviceRelations) to get the PDO? That is the approved way and does not require traversal.

My guess is that the FTDI comm ports are not rs232 compliant so they need their own APIs

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, August 05, 2009 8:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] IoGetDeviceProperty fails on an FTDI VCP

Hi,

I’m trying to query the device properties of an FTDI-created virtual comm port from a kernel mode driver. I’m calling IoGetDeviceProperty on a PDO obtained by traversing the device stack of the VCP starting with the top-level device object obtained from IoGetDeviceObjectPointer. Property calls always fail with STATUS_INVALID_DEVICE_REQUEST (0xc0000010).

My code seems fine because it works on other serial interfaces (a modem interface and a real serial interface). Am I missing something with the FTDI virtual serial port?

Thanks.

P.S.: Why does FTDI provide a serial comm API for their devices? Isn’t regular win32 serial API enough?

—
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

Manu_Bansal · August 6, 2009, 3:52pm

Yes, I am using IRP_MN_QUERY_DEVICE_RELATIONS to get the PDO, as in the
toastmon example. Here is the output from debugView that I’m generating from
my code:

Device symbolic link name
??\FTDIBUS#VID_0403+PID_6001+5&1fe0c285&0&1#0000#{86e0d1e0-8089-11d0-9ce4-08003e301f73}
topDeviceObject at 0x85e68e10
fileObject at 0x85e68e10
bottomPhysicalDeviceObject at 0x84b02558
Failed to get target class guid with getdevprop 0xc0000010

The corresponding !devstack output is here:

lkd> !devstack 85e68e10
!DevObj !DrvObj !DevExt ObjectName

85e68e10 \Driver\Serenum 85e68ec8
84e01230 \Driver\FTSER2K 84e012e8 VCP0
84dda040 \Driver\FTDIBUS 84dda0f8 000000c5
!DevNode 860fa498 :
DeviceInst is “FTDIBUS\VID_0403+PID_6001+5&1fe0c285&0&1\0000”
ServiceName is “FTSER2K”

lkd> !devstack 84b02558
!DevObj !DrvObj !DevExt ObjectName

84b02558 \Driver\FTDIBUS 84b02610
8506d668 \Driver\ACPI 85006ea0 000000c4
85e49de8 \Driver\usbhub 85e49ea0 USBPDO-4
!DevNode 86231c70 :
DeviceInst is “USB\Vid_0403&Pid_6001\5&1fe0c285&0&1”
ServiceName is “FTDIBUS”

I expect the PDO to point to 84dda040 which, I believe, will allow device
property calls as expected, but the PDO returned seems to run off to another
device stack. Things fit in for the real com port and a soft modem.

Thanks.

P.S.: I read further about FTDI API. With their virtual com port driver,
they promise to make it RS232 compliant, but they provide their own API off
a direct usb driver without creating a VCP. That makes sense. Also, the API
allows additional features such as reprogramming the board etc, which the
win32 API does not. Of course, in principle, this API could be implemented
on top of the win32 serial API as well, but that’s just too roundabout.

In general, is there any way to use a user-space API/protocol implementation
in a kernel-mode driver, or does the wheel always have to be invented twice?

On Wed, Aug 5, 2009 at 10:02 PM, Doron Holan wrote:

> 1) you sure it is a pnp device stack? What does !devstack
> say?
> 2) what do you mean by traversing the device stack to find the PDO? Are
> you issuing a
> IRP_MJ_PNP/IRP_MN_QUERY_DEVICE_RELATIONS(TargetDeviceRelations) to get the
> PDO? That is the approved way and does not require traversal.
>
> My guess is that the FTDI comm ports are not rs232 compliant so they need
> their own APIs
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
> Sent: Wednesday, August 05, 2009 8:26 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] IoGetDeviceProperty fails on an FTDI VCP
>
> Hi,
>
> I’m trying to query the device properties of an FTDI-created virtual comm
> port from a kernel mode driver. I’m calling IoGetDeviceProperty on a PDO
> obtained by traversing the device stack of the VCP starting with the
> top-level device object obtained from IoGetDeviceObjectPointer. Property
> calls always fail with STATUS_INVALID_DEVICE_REQUEST (0xc0000010).
>
> My code seems fine because it works on other serial interfaces (a modem
> interface and a real serial interface). Am I missing something with the FTDI
> virtual serial port?
>
> Thanks.
>
> P.S.: Why does FTDI provide a serial comm API for their devices? Isn’t
> regular win32 serial API enough?
>
> —
> 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
>
>
> —
> 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
>

Peter_Viscarola_OSR · August 6, 2009, 4:06pm

The way I understand it, the FTDI API stuff is done in a series of DLLs that they provide (a “new style” library and and older “legacy” one). SOME of this work is likely to be confined JUST to user-mode (such as getting a list of the FTDI devices… they could do that with SetupDIxxx or WMI or something).

You can’t call user-mode DLLs from kernel-mode drivers. OTOH, maybe you can do what you want from JUST user mode??

Peter
OSR

Doron_Holan · August 6, 2009, 4:38pm

The result from QDR/TargetDeviceRelations is 0x84b02558? That is incorrect and their bus driver is reporting the wrong thing. I would turn on DV on their driver to see if they are screwing anything else up

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Manu Bansal
Sent: Thursday, August 06, 2009 12:52 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] IoGetDeviceProperty fails on an FTDI VCP

Yes, I am using IRP_MN_QUERY_DEVICE_RELATIONS to get the PDO, as in the toastmon example. Here is the output from debugView that I’m generating from my code:

Device symbolic link name ??\FTDIBUS#VID_0403+PID_6001+5&1fe0c285&0&1#0000#{86e0d1e0-8089-11d0-9ce4-08003e301f73}
topDeviceObject at 0x85e68e10
fileObject at 0x85e68e10
bottomPhysicalDeviceObject at 0x84b02558
Failed to get target class guid with getdevprop 0xc0000010

The corresponding !devstack output is here:

lkd> !devstack 85e68e10
!DevObj !DrvObj !DevExt ObjectName

85e68e10 \Driver\Serenum 85e68ec8
84e01230 \Driver\FTSER2K 84e012e8 VCP0
84dda040 \Driver\FTDIBUS 84dda0f8 000000c5
!DevNode 860fa498 :
DeviceInst is “FTDIBUS\VID_0403+PID_6001+5&1fe0c285&0&1\0000”
ServiceName is “FTSER2K”

lkd> !devstack 84b02558
!DevObj !DrvObj !DevExt ObjectName

84b02558 \Driver\FTDIBUS 84b02610
8506d668 \Driver\ACPI 85006ea0 000000c4
85e49de8 \Driver\usbhub 85e49ea0 USBPDO-4
!DevNode 86231c70 :
DeviceInst is “USB\Vid_0403&Pid_6001\5&1fe0c285&0&1”
ServiceName is “FTDIBUS”

I expect the PDO to point to 84dda040 which, I believe, will allow device property calls as expected, but the PDO returned seems to run off to another device stack. Things fit in for the real com port and a soft modem.

Thanks.

P.S.: I read further about FTDI API. With their virtual com port driver, they promise to make it RS232 compliant, but they provide their own API off a direct usb driver without creating a VCP. That makes sense. Also, the API allows additional features such as reprogramming the board etc, which the win32 API does not. Of course, in principle, this API could be implemented on top of the win32 serial API as well, but that’s just too roundabout.

In general, is there any way to use a user-space API/protocol implementation in a kernel-mode driver, or does the wheel always have to be invented twice?
On Wed, Aug 5, 2009 at 10:02 PM, Doron Holan > wrote:
1) you sure it is a pnp device stack? What does !devstack say?
2) what do you mean by traversing the device stack to find the PDO? Are you issuing a IRP_MJ_PNP/IRP_MN_QUERY_DEVICE_RELATIONS(TargetDeviceRelations) to get the PDO? That is the approved way and does not require traversal.

My guess is that the FTDI comm ports are not rs232 compliant so they need their own APIs

d

-----Original Message-----
From: xxxxx@lists.osr.com mailto:xxxxx [mailto:xxxxx@lists.osr.com mailto:xxxxx] On Behalf Of xxxxx@gmail.com mailto:xxxxx
Sent: Wednesday, August 05, 2009 8:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] IoGetDeviceProperty fails on an FTDI VCP

Hi,

I’m trying to query the device properties of an FTDI-created virtual comm port from a kernel mode driver. I’m calling IoGetDeviceProperty on a PDO obtained by traversing the device stack of the VCP starting with the top-level device object obtained from IoGetDeviceObjectPointer. Property calls always fail with STATUS_INVALID_DEVICE_REQUEST (0xc0000010).

My code seems fine because it works on other serial interfaces (a modem interface and a real serial interface). Am I missing something with the FTDI virtual serial port?

Thanks.

P.S.: Why does FTDI provide a serial comm API for their devices? Isn’t regular win32 serial API enough?

—
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

—
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

— 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</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

Manu_Bansal · August 6, 2009, 7:12pm

@Doron: That helps. I updated the FTDI drivers and everything works fine
now. Digi International is shipping FTDI-board based hardware kits with '03
drivers when FTDI has been regularly releasing updates. A USB2.0 enumeration
fix was actually listed in the release notes.

Thanks alot!

@Peter: I’m writing a (virtual) miniport driver. That’s the only reason I’ve
to be in the kernel-mode. Perhaps I could write a user-mode driver using the
DLL and make my kernel mode hook talk to it. Would that be a better design
in this case?

On Thu, Aug 6, 2009 at 1:32 PM, Doron Holan wrote:

> The result from QDR/TargetDeviceRelations is 0x84b02558? That is
> incorrect and their bus driver is reporting the wrong thing. I would turn
> on DV on their driver to see if they are screwing anything else up
>
>
>
> d
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *Manu Bansal
> Sent: Thursday, August 06, 2009 12:52 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] IoGetDeviceProperty fails on an FTDI VCP
>
>
>
> Yes, I am using IRP_MN_QUERY_DEVICE_RELATIONS to get the PDO, as in the
> toastmon example. Here is the output from debugView that I’m generating from
> my code:
>
> Device symbolic link name
> ??\FTDIBUS#VID_0403+PID_6001+5&1fe0c285&0&1#0000#{86e0d1e0-8089-11d0-9ce4-08003e301f73}
> topDeviceObject at 0x85e68e10
> fileObject at 0x85e68e10
> bottomPhysicalDeviceObject at 0x84b02558
> Failed to get target class guid with getdevprop 0xc0000010
>
>
> The corresponding !devstack output is here:
>
> lkd> !devstack 85e68e10
> !DevObj !DrvObj !DevExt ObjectName
> > 85e68e10 \Driver\Serenum 85e68ec8
> 84e01230 \Driver\FTSER2K 84e012e8 VCP0
> 84dda040 \Driver\FTDIBUS 84dda0f8 000000c5
> !DevNode 860fa498 :
> DeviceInst is “FTDIBUS\VID_0403+PID_6001+5&1fe0c285&0&1\0000”
> ServiceName is “FTSER2K”
>
> lkd> !devstack 84b02558
> !DevObj !DrvObj !DevExt ObjectName
> > 84b02558 \Driver\FTDIBUS 84b02610
> 8506d668 \Driver\ACPI 85006ea0 000000c4
> 85e49de8 \Driver\usbhub 85e49ea0 USBPDO-4
> !DevNode 86231c70 :
> DeviceInst is “USB\Vid_0403&Pid_6001\5&1fe0c285&0&1”
> ServiceName is “FTDIBUS”
>
>
> I expect the PDO to point to 84dda040 which, I believe, will allow device
> property calls as expected, but the PDO returned seems to run off to another
> device stack. Things fit in for the real com port and a soft modem.
>
> Thanks.
>
> P.S.: I read further about FTDI API. With their virtual com port driver,
> they promise to make it RS232 compliant, but they provide their own API off
> a direct usb driver without creating a VCP. That makes sense. Also, the API
> allows additional features such as reprogramming the board etc, which the
> win32 API does not. Of course, in principle, this API could be implemented
> on top of the win32 serial API as well, but that’s just too roundabout.
>
> In general, is there any way to use a user-space API/protocol
> implementation in a kernel-mode driver, or does the wheel always have to be
> invented twice?
>
> On Wed, Aug 5, 2009 at 10:02 PM, Doron Holan
> wrote:
>
> 1) you sure it is a pnp device stack? What does !devstack
> say?
> 2) what do you mean by traversing the device stack to find the PDO? Are
> you issuing a
> IRP_MJ_PNP/IRP_MN_QUERY_DEVICE_RELATIONS(TargetDeviceRelations) to get the
> PDO? That is the approved way and does not require traversal.
>
> My guess is that the FTDI comm ports are not rs232 compliant so they need
> their own APIs
>
> d
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
> Sent: Wednesday, August 05, 2009 8:26 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] IoGetDeviceProperty fails on an FTDI VCP
>
> Hi,
>
> I’m trying to query the device properties of an FTDI-created virtual comm
> port from a kernel mode driver. I’m calling IoGetDeviceProperty on a PDO
> obtained by traversing the device stack of the VCP starting with the
> top-level device object obtained from IoGetDeviceObjectPointer. Property
> calls always fail with STATUS_INVALID_DEVICE_REQUEST (0xc0000010).
>
> My code seems fine because it works on other serial interfaces (a modem
> interface and a real serial interface). Am I missing something with the FTDI
> virtual serial port?
>
> Thanks.
>
> P.S.: Why does FTDI provide a serial comm API for their devices? Isn’t
> regular win32 serial API enough?
>
> —
> 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
>
>
> —
> 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
>
>
> — 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
>
>
> —
> 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
>