CreateFile fails with ERROR_INVALID_PARAMETER when using Reference String

OSR_Community_User · April 9, 2008, 1:18pm

Hello,

I add additional interface to our device in order to be able to communicate with it, and add a reference string to the device in order to allow my EvtDeviceFileCreate callback to recognize the initiator of the CreateFile caller.
I followed the instructions at http://blogs.msdn.com/doronh/archive/2006/08/18/706717.aspx to create the interface.
The interface is created, and I can see it in the registry.
However, when I call for CreateFile and specify the device path including the reference string, the function fails with with error code 0x57 (ERROR_INVALID_PARAMETER). Running WinDbg I can see that I don’t reach the EvtDeviceFileCreate callback.

If I remove the reference string from the path, the handle can be opened (and I can see that the callback has been reached with empty FileName). But - I can’t see in the registry a symbolic link that doesn’t contain the reference string. What do I miss?

Additional question: is it possible to determine by GUID who has called the CreateFile from the EvtDeviceFileCreate callback, rather then by reference name?

Thank you in advance,

Sasha.

OSR_Community_User · April 9, 2008, 1:33pm

More info:
I add the interface in the following way:

#define MY_REF_STR L"a"

NTSTATUS my_evt_device_add(IN WDFDRIVER driver, IN PWDFDEVICE_INIT dev_init)
{
…
add_my_new_ifc(device);
}

NTSTATUS acm_my_new_ifc(WDFDEVICE device)
{
NTSTATUS status;
UNICODE_STRING ref_str;

RtlInitUnicodeString(&ref_str, MY_REF_STR);

status = WdfDeviceCreateDeviceInterface(fdx->device, (LPGUID)&GUID_MY_GUID, &ref_str);
if (!NT_SUCCESS(status))
Error(“WdfDeviceCreateDeviceInterface failed %lx\n”, status);

return status;
}

Once my driver is loaded, I can see in the registry the following symbolic link:
\?<dev>#Vid_&Pid_##{}\a

Where “a” is a reference string.

Following call for CreateFile fails with error 0x57 (ERROR_INVALID_PARAMETER):
handle = CreateFile(“\\?\<dev>#Vid_&Pid_##{}\a”,
GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);

Following call for CreateFile succeeds:
handle = CreateFile(“\\?\<dev>#Vid_&Pid_##{}”,
GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);

Don_Burn_1 · April 9, 2008, 1:39pm

Take a look at
http://blogs.msdn.com/doronh/archive/2007/10/04/making-sure-the-io-manager-evaluates-the-security-of-your-device.aspx

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntdev…
> Hello,
>
> I add additional interface to our device in order to be able to
> communicate with it, and add a reference string to the device in order to
> allow my EvtDeviceFileCreate callback to recognize the initiator of the
> CreateFile caller.
> I followed the instructions at
> http://blogs.msdn.com/doronh/archive/2006/08/18/706717.aspx to create the
> interface.
> The interface is created, and I can see it in the registry.
> However, when I call for CreateFile and specify the device path including
> the reference string, the function fails with with error code 0x57
> (ERROR_INVALID_PARAMETER). Running WinDbg I can see that I don’t reach the
> EvtDeviceFileCreate callback.
>
> If I remove the reference string from the path, the handle can be opened
> (and I can see that the callback has been reached with empty FileName).
> But - I can’t see in the registry a symbolic link that doesn’t contain the
> reference string. What do I miss?
>
> Additional question: is it possible to determine by GUID who has called
> the CreateFile from the EvtDeviceFileCreate callback, rather then by
> reference name?
>
> Thank you in advance,
>
> Sasha.
>
>

OSR_Community_User · April 9, 2008, 2:26pm

Thanks for your reply.

According to this article, the FILE_DEVICE_SECURE_OPEN flag is set for WDFDEVICEs, and mine is one.
Also, I there would be a security issue, I would expect ERROR_ACCESS_DENIED error code, and not ERROR_INVALID_PARAMETER.

Do I miss something here?

Doron_Holan · April 9, 2008, 2:34pm

Does !wdflogdump say anything?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@jungo.com
Sent: Wednesday, April 09, 2008 11:27 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] CreateFile fails with ERROR_INVALID_PARAMETER when using Reference String

Thanks for your reply.

According to this article, the FILE_DEVICE_SECURE_OPEN flag is set for WDFDEVICEs, and mine is one.
Also, I there would be a security issue, I would expect ERROR_ACCESS_DENIED error code, and not ERROR_INVALID_PARAMETER.

Do I miss something here?

—
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

OSR_Community_User · April 9, 2008, 3:33pm

Hello Doron,

Thank you for your reply. The output of !wdfkd.wdflogdump is following. If I understand it correctly, the IRP_MJ_CREATE request was not dispatched by my driver. How can I know if it was posted at all?
Could be the problem is with CreateFile call itself?
Thank you in advance.

kd> !wdfkd.wdflogdump mydriver.sys
Trace searchpath is:

Trace format prefix is: %7!u!: %!FUNC! -
TMF file used for formatting IFR log is: c:\WinDDK\6000\tools\tracing\i386\wdf01005.tmf
Log at 8196d000
Gather log: Please wait, this may take a moment (reading 4032 bytes).
% read so far … 10, 20, 30, 40, 50, 60, 70, 80, 90, 100
There are 110 log entries
— start of log —
211: FxDevice::AllocateRequestMemory - Allocating FxRequest* 821BC378, WDFREQUEST 7DE43C80
212: FxIoQueue::QueueRequest - Queuing WDFREQUEST 0x7DE43C80 on WDFQUEUE 0x7DCFAD08
213: FxIoQueue::DispatchEvents - Thread 814B4618 is processing WDFQUEUE 0x7DCFAD08
214: FxIoQueue::DispatchRequestToDriver - Calling driver EvtIoRead for WDFREQUEST 0x7DE43C80
215: imp_WdfRequestRetrieveOutputBuffer - Enter: WDFREQUEST 0x7DE43C80
216: imp_WdfRequestGetParameters - Enter: Request 7DE43C80, Parameters F49DFB58
217: imp_WdfRequestCompleteWithInformation - Completing WDFREQUEST 0x7DE43C80, STATUS_SUCCESS
218: FxRequest::Complete - Completing WDFREQUEST 0x7DE43C80 for IRP 0x8150BBD8 with Information 0x1, STATUS_SUCCESS
219: FxIoQueue::RequestCompletedCallback - Enter: WDFQUEUE 0x7DCFAD08, WDFREQUEST 0x7DE43C80
220: FxIoQueue::DispatchRequestToDriver - WDFREQUEST 0x7DE43C80 dispatched to driver
221: FxDevice::FreeRequestMemory - Free FxRequest* 821BC378 memory
222: FxIoQueue::DispatchEvents - No requests on WDFQUEUE 0x7DCFAD08
223: FxPkgIo::Dispatch - WDFDEVICE 0x7E702BA8 !devobj 0xF8CE86E8 0x00000003(IRP_MJ_READ), IRP_MN 0, IRP 0x8150BBD8
224: FxDevice::AllocateRequestMemory - Allocating FxRequest* 821BC378, WDFREQUEST 7DE43C80
225: FxIoQueue::QueueRequest - Queuing WDFREQUEST 0x7DE43C80 on WDFQUEUE 0x7DCFAD08
226: FxIoQueue::DispatchEvents - Thread 814B4618 is processing WDFQUEUE 0x7DCFAD08
227: FxIoQueue::DispatchRequestToDriver - Calling driver EvtIoRead for WDFREQUEST 0x7DE43C80
228: imp_WdfRequestRetrieveOutputBuffer - Enter: WDFREQUEST 0x7DE43C80
229: imp_WdfRequestGetParameters - Enter: Request 7DE43C80, Parameters F49DFB58
230: imp_WdfRequestCompleteWithInformation - Completing WDFREQUEST 0x7DE43C80, STATUS_SUCCESS
231: FxRequest::Complete - Completing WDFREQUEST 0x7DE43C80 for IRP 0x8150BBD8 with Information 0x1, STATUS_SUCCESS
232: FxIoQueue::RequestCompletedCallback - Enter: WDFQUEUE 0x7DCFAD08, WDFREQUEST 0x7DE43C80
233: FxIoQueue::DispatchRequestToDriver - WDFREQUEST 0x7DE43C80 dispatched to driver
234: FxDevice::FreeRequestMemory - Free FxRequest* 821BC378 memory
235: FxIoQueue::DispatchEvents - No requests on WDFQUEUE 0x7DCFAD08
236: FxPkgIo::Dispatch - WDFDEVICE 0x7E702BA8 !devobj 0xF8CE86E8 0x00000003(IRP_MJ_READ), IRP_MN 0, IRP 0x8150BBD8
237: FxDevice::AllocateRequestMemory - Allocating FxRequest* 821BC378, WDFREQUEST 7DE43C80
238: FxIoQueue::QueueRequest - Queuing WDFREQUEST 0x7DE43C80 on WDFQUEUE 0x7DCFAD08
239: FxIoQueue::DispatchEvents - Thread 814B4618 is processing WDFQUEUE 0x7DCFAD08
240: FxIoQueue::DispatchRequestToDriver - Calling driver EvtIoRead for WDFREQUEST 0x7DE43C80
241: imp_WdfRequestRetrieveOutputBuffer - Enter: WDFREQUEST 0x7DE43C80
242: imp_WdfRequestGetParameters - Enter: Request 7DE43C80, Parameters F49DFB58
243: imp_WdfRequestCompleteWithInformation - Completing WDFREQUEST 0x7DE43C80, STATUS_SUCCESS
244: FxRequest::Complete - Completing WDFREQUEST 0x7DE43C80 for IRP 0x8150BBD8 with Information 0x1, STATUS_SUCCESS
245: FxIoQueue::RequestCompletedCallback - Enter: WDFQUEUE 0x7DCFAD08, WDFREQUEST 0x7DE43C80
246: FxIoQueue::DispatchRequestToDriver - WDFREQUEST 0x7DE43C80 dispatched to driver
247: FxDevice::FreeRequestMemory - Free FxRequest* 821BC378 memory
248: FxIoQueue::DispatchEvents - No requests on WDFQUEUE 0x7DCFAD08
249: FxPkgIo::Dispatch - WDFDEVICE 0x7E702BA8 !devobj 0xF8CE86E8 0x00000003(IRP_MJ_READ), IRP_MN 0, IRP 0x8150BBD8
250: FxDevice::AllocateRequestMemory - Allocating FxRequest* 821BC378, WDFREQUEST 7DE43C80
251: FxIoQueue::QueueRequest - Queuing WDFREQUEST 0x7DE43C80 on WDFQUEUE 0x7DCFAD08
252: FxIoQueue::DispatchEvents - Thread 814B4618 is processing WDFQUEUE 0x7DCFAD08
253: FxIoQueue::DispatchRequestToDriver - Calling driver EvtIoRead for WDFREQUEST 0x7DE43C80
254: imp_WdfRequestRetrieveOutputBuffer - Enter: WDFREQUEST 0x7DE43C80
255: imp_WdfRequestGetParameters - Enter: Request 7DE43C80, Parameters F49DFB58
256: imp_WdfRequestCompleteWithInformation - Completing WDFREQUEST 0x7DE43C80, STATUS_SUCCESS
257: FxRequest::Complete - Completing WDFREQUEST 0x7DE43C80 for IRP 0x8150BBD8 with Information 0x1, STATUS_SUCCESS
258: FxIoQueue::RequestCompletedCallback - Enter: WDFQUEUE 0x7DCFAD08, WDFREQUEST 0x7DE43C80
259: FxIoQueue::DispatchRequestToDriver - WDFREQUEST 0x7DE43C80 dispatched to driver
260: FxDevice::FreeRequestMemory - Free FxRequest* 821BC378 memory
261: FxIoQueue::DispatchEvents - No requests on WDFQUEUE 0x7DCFAD08
262: FxPkgIo::Dispatch - WDFDEVICE 0x7E702BA8 !devobj 0xF8CE86E8 0x00000003(IRP_MJ_READ), IRP_MN 0, IRP 0x8150BBD8
263: FxDevice::AllocateRequestMemory - Allocating FxRequest* 821BC378, WDFREQUEST 7DE43C80
264: FxIoQueue::QueueRequest - Queuing WDFREQUEST 0x7DE43C80 on WDFQUEUE 0x7DCFAD08
265: FxIoQueue::DispatchEvents - Thread 814B4618 is processing WDFQUEUE 0x7DCFAD08
266: FxIoQueue::DispatchRequestToDriver - Calling driver EvtIoRead for WDFREQUEST 0x7DE43C80
267: imp_WdfRequestRetrieveOutputBuffer - Enter: WDFREQUEST 0x7DE43C80
268: imp_WdfRequestGetParameters - Enter: Request 7DE43C80, Parameters F49DFB58
269: imp_WdfRequestCompleteWithInformation - Completing WDFREQUEST 0x7DE43C80, STATUS_SUCCESS
270: FxRequest::Complete - Completing WDFREQUEST 0x7DE43C80 for IRP 0x8150BBD8 with Information 0x1, STATUS_SUCCESS
271: FxIoQueue::RequestCompletedCallback - Enter: WDFQUEUE 0x7DCFAD08, WDFREQUEST 0x7DE43C80
272: FxIoQueue::DispatchRequestToDriver - WDFREQUEST 0x7DE43C80 dispatched to driver
273: FxDevice::FreeRequestMemory - Free FxRequest* 821BC378 memory
274: FxIoQueue::DispatchEvents - No requests on WDFQUEUE 0x7DCFAD08
275: FxPkgIo::Dispatch - WDFDEVICE 0x7E702BA8 !devobj 0xF8CE86E8 0x00000004(IRP_MJ_WRITE), IRP_MN 0, IRP 0x8150BBD8
276: FxDevice::AllocateRequestMemory - Allocating FxRequest* 821BC378, WDFREQUEST 7DE43C80
277: FxIoQueue::QueueRequest - Queuing WDFREQUEST 0x7DE43C80 on WDFQUEUE 0x7DCFAD08
278: FxIoQueue::DispatchEvents - Thread 814B4618 is processing WDFQUEUE 0x7DCFAD08
279: FxIoQueue::DispatchRequestToDriver - Calling driver EvtIoWrite for WDFREQUEST 0x7DE43C80
280: imp_WdfRequestRetrieveInputBuffer - Enter: WDFREQUEST 0x7DE43C80
281: imp_WdfRequestGetParameters - Enter: Request 7DE43C80, Parameters F49DFB48
282: imp_WdfRequestMarkCancelable - Enter: WDFREQUEST 0x7DE43C80
283: FxIoQueue::DispatchRequestToDriver - WDFREQUEST 0x7DE43C80 dispatched to driver
284: FxIoQueue::DispatchEvents - No requests on WDFQUEUE 0x7DCFAD08
285: imp_WdfRequestUnmarkCancelable - Enter: WDFREQUEST 0x7DE43C80
286: imp_WdfRequestCompleteWithInformation - Completing WDFREQUEST 0x7DE43C80, STATUS_SUCCESS
287: FxRequest::Complete - Completing WDFREQUEST 0x7DE43C80 for IRP 0x8150BBD8 with Information 0x8, STATUS_SUCCESS
288: FxIoQueue::RequestCompletedCallback - Enter: WDFQUEUE 0x7DCFAD08, WDFREQUEST 0x7DE43C80
289: FxIoQueue::DispatchEvents - Thread 80558E20 is processing WDFQUEUE 0x7DCFAD08
290: FxIoQueue::DispatchEvents - No requests on WDFQUEUE 0x7DCFAD08
291: FxDevice::FreeRequestMemory - Free FxRequest* 821BC378 memory
292: FxPkgIo::Dispatch - WDFDEVICE 0x7E702BA8 !devobj 0xF8CE86E8 0x00000003(IRP_MJ_READ), IRP_MN 0, IRP 0x8150BBD8
293: FxDevice::AllocateRequestMemory - Allocating FxRequest* 821BC378, WDFREQUEST 7DE43C80
294: FxIoQueue::QueueRequest - Queuing WDFREQUEST 0x7DE43C80 on WDFQUEUE 0x7DCFAD08
295: FxIoQueue::DispatchEvents - Thread 814B4618 is processing WDFQUEUE 0x7DCFAD08
296: FxIoQueue::DispatchRequestToDriver - Calling driver EvtIoRead for WDFREQUEST 0x7DE43C80
297: imp_WdfRequestRetrieveOutputBuffer - Enter: WDFREQUEST 0x7DE43C80
298: imp_WdfRequestGetParameters - Enter: Request 7DE43C80, Parameters F49DFB58
299: imp_WdfRequestCompleteWithInformation - Completing WDFREQUEST 0x7DE43C80, STATUS_SUCCESS
300: FxRequest::Complete - Completing WDFREQUEST 0x7DE43C80 for IRP 0x8150BBD8 with Information 0x9, STATUS_SUCCESS
301: FxIoQueue::RequestCompletedCallback - Enter: WDFQUEUE 0x7DCFAD08, WDFREQUEST 0x7DE43C80
302: FxIoQueue::DispatchRequestToDriver - WDFREQUEST 0x7DE43C80 dispatched to driver
303: FxDevice::FreeRequestMemory - Free FxRequest* 821BC378 memory
304: FxIoQueue::DispatchEvents - No requests on WDFQUEUE 0x7DCFAD08
305: FxPkgGeneral::Dispatch - WDFDEVICE 0x7E702BA8 !devobj 0xF8CE86E8 0x00000012(IRP_MJ_CLEANUP) IRP 0x8150BBD8
306: FxIoQueue::DispatchEvents - Thread 814B4618 is processing WDFQUEUE 0x7E0BD1E8
307: FxIoQueue::DispatchEvents - Driver has configured WDFQUEUE 0x7E0BD1E8 for WdfIoQueueDispatchManual
308: FxIoQueue::DispatchEvents - Thread 814B4618 is processing WDFQUEUE 0x7DCFAD08
309: FxIoQueue::DispatchEvents - No requests on WDFQUEUE 0x7DCFAD08
310: FxIoQueue::DispatchEvents - Thread 814B4618 is processing WDFQUEUE 0x7E266688
311: FxIoQueue::DispatchEvents - Driver has configured WDFQUEUE 0x7E266688 for WdfIoQueueDispatchManual
312: FxIoQueue::DispatchEvents - Thread 814B4618 is processing WDFQUEUE 0x7E940C18
313: FxIoQueue::DispatchEvents - Driver has configured WDFQUEUE 0x7E940C18 for WdfIoQueueDispatchManual
314: FxIoQueue::DispatchEvents - Thread 814B4618 is processing WDFQUEUE 0x7EAEF728
315: FxIoQueue::DispatchEvents - Driver has configured WDFQUEUE 0x7EAEF728 for WdfIoQueueDispatchManual
316: FxIoQueue::DispatchEvents - Thread 814B4618 is processing WDFQUEUE 0x04945350
317: FxIoQueue::DispatchEvents - Driver has configured WDFQUEUE 0x04945350 for WdfIoQueueDispatchManual
318: FxIoQueue::DispatchEvents - Thread 814B4618 is processing WDFQUEUE 0x05046660
319: FxIoQueue::DispatchEvents - Driver has configured WDFQUEUE 0x05046660 for WdfIoQueueDispatchManual
320: FxPkgGeneral::Dispatch - WDFDEVICE 0x7E702BA8 !devobj 0xF8CE86E8 0x00000002(IRP_MJ_CLOSE) IRP 0x8150BBD8
---- end of log ----

OSR_Community_User · April 9, 2008, 5:09pm

Just to clarify: the output of !wdflogdump above remained the same before and after the failed CreateFile() call.

Thank you in advance,
Sasha.

Doron_Holan · April 9, 2008, 6:01pm

Does it work if you manually clear FILE_DEVICE_SECURE_OPEN from your devobj after creating it in AddDevice()?

e.g. WdfDeviceWdmGetDeviceObject(wdfdevice)->Flags &= ~FILE_DEVICE_SECURE_OPEN;

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@jungo.com
Sent: Wednesday, April 09, 2008 2:10 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] CreateFile fails with ERROR_INVALID_PARAMETER when using Reference String

Just to clarify: the output of !wdflogdump above remained the same before and after the failed CreateFile() call.

Thank you in advance,
Sasha.

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

OSR_Community_User · April 10, 2008, 2:36am

No, it doesn’t.

OSR_Community_User · April 10, 2008, 8:19am

More info about the the device for which I create the second interface: it’s first interface is a COM port.

Doron_Holan · April 10, 2008, 11:27am

What if you change the first interface to something other then a com port, some custom guid? What device class is your device installed under? What is the device type you specify when you create the device?

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@jungo.com
Sent: Thursday, April 10, 2008 5:19 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] CreateFile fails with ERROR_INVALID_PARAMETER when using Reference String

More info about the the device for which I create the second interface: it’s first interface is a COM port.

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

OSR_Community_User · April 10, 2008, 1:51pm

Hello Doron,

Thank you for your reply.
When working with a custom guid, and the interface is not defined as a com port, it works fine.
The device class my device is installed under could be Modem or Ports (from INF
File:
Class=Modem
or
Class=Ports)
I specify FILE_DEVICE_SERIAL_PORT for device when create it. However, seems that this flag
has no effect - when I remove the call for WdfDeviceInitSetDeviceType I still
have the problem.

More info about our goal:
We have a USB bus driver, which creates a child device. We use the child device
to install a virtual COM Port device. We can to communicate with the com port
using either CreateFile or opening a hyper-terminal utility. What we need, is
additional interface to communicate with the device - since communication
interfaces are exclusive, we can’t use the same interface to open additional
handle.

Thank you in advance for your next reply
Sasha.

P.S. By the way, your blog is very helpful

Doron_Holan · April 10, 2008, 2:16pm

Next guess is that the device is being marked as exclusive, either by an INF or class driver (in the modem case at least). is DO_EXCLUSIVE (0x00000008) set on any device object’s Flags field in the device stack? If there are upper filters like modem.sys, put a bp on their IRP_MJ_CREATE dispatch routine (!drvobj 3 will give you the entry point’s address) and see if it gets hit.

What is the actual code that tries to open the file? Perhaps there is an invalid set of flags in the call (which leads to invalid parameter being returned)

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@jungo.com
Sent: Thursday, April 10, 2008 10:52 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] CreateFile fails with ERROR_INVALID_PARAMETER when using Reference String

Hello Doron,

Thank you for your reply.
When working with a custom guid, and the interface is not defined as a com port, it works fine.
The device class my device is installed under could be Modem or Ports (from INF
File:
Class=Modem
or
Class=Ports)
I specify FILE_DEVICE_SERIAL_PORT for device when create it. However, seems that this flag
has no effect - when I remove the call for WdfDeviceInitSetDeviceType I still
have the problem.

More info about our goal:
We have a USB bus driver, which creates a child device. We use the child device
to install a virtual COM Port device. We can to communicate with the com port
using either CreateFile or opening a hyper-terminal utility. What we need, is
additional interface to communicate with the device - since communication
interfaces are exclusive, we can’t use the same interface to open additional
handle.

Thank you in advance for your next reply
Sasha.

P.S. By the way, your blog is very helpful

—
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

Chris_Aseltine · April 10, 2008, 2:48pm

Sasha Pigovat wrote:

We have a USB bus driver, which creates a child device. We use
the child device to install a virtual COM Port device. We can to
communicate with the com port using either CreateFile or
opening a hyper-terminal utility. What we need, is additional
interface to communicate with the device - since communication
interfaces are exclusive, we can’t use the same interface to
open additional handle.

Adding a reference string isn’t going to help you here since modem stacks are exclusive open.

*Actually*, from what I remember, TAPI will open Modem.sys with different reference strings in order to do different things. So if you are opening the stack with your own reference string, modem.sys is probably getting confused and blocking the create with INVALID_PARAMETER (Doron can confirm this theory).

Anyway, you said you had a bus driver below this virtual COM port, right? Why not enumerate another device on a different stack (either a raw PDO, or some other device with a real simple function driver on top of it) that ultimately sends I/O down to your device in the same place?

OSR_Community_User · April 10, 2008, 3:24pm

I get the IRP_MJ_CREATE of Modem.sys indeed, which is the upper driver of my virtual com port. This one drops me out.
Within the driver code I set (at list tried ) the device to non-exclusive mode, with the following command:
WdfDeviceInitSetExclusive(dev_init, FALSE);
Does that mean that modem.sys enforces my device to be exclusive? Or, it is exclusive by itself, and as a filter driver, doesn’t pass the IRP_MJ_CREATE requests?

Regarding the CreateFile call that fails:
handle = CreateFile(“\\?\…\a”, GENERIC_READ | GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING,
0, NULL);
Where “…” is #Vid_&Pid_##{}, and ‘a’ is the reference string (I can supply the whole string if it’s necessary, but I don’t think that will be helpful).

OSR_Community_User · April 10, 2008, 3:42pm

Does that mean that there is no way (trick) to reach the additional interface I create for my device?

Thank you for your reply,

Sasha.

Chris_Aseltine · April 10, 2008, 3:45pm

Sasha Pigovat wrote:

Does that mean that there is no way (trick) to reach the additional
interface I create for my device?

If my earlier explanation is correct, and I bet it is, then no, there’s no way to use reference strings in this way. But like I said, using reference strings isn’t going to help you get around an exclusive open stack that’s already open anyway.

In other words, you’re not really “creating an additional interface” in that it would be totally separate from your existing one. Reference strings are really only for knowing who is opening you (or for what purpose), I think Doron’s blog explains this…

Tim_Roberts · April 10, 2008, 4:05pm

xxxxx@jungo.com wrote:

Does that mean that there is no way (trick) to reach the additional interface I create for my device?

Right. I’m sure you’ve read the discussion this week about managing a
PnP device with a separate control device? This is exactly the reason
why people do such a thing. Device interfaces don’t create a new
device. They create an alternative way to gain access to an EXISTING
device. In the case of a filter, the existing device belongs to and was
created by the serial driver.

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

Michal_Vodicka-2 · April 10, 2008, 4:54pm

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, April 10, 2008 10:05 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] CreateFile fails with
ERROR_INVALID_PARAMETER when using Reference String

xxxxx@jungo.com wrote:
> Does that mean that there is no way (trick) to reach the
additional interface I create for my device?
>

Right. I’m sure you’ve read the discussion this week about
managing a
PnP device with a separate control device? This is exactly
the reason
why people do such a thing. Device interfaces don’t create a new
device. They create an alternative way to gain access to an EXISTING
device. In the case of a filter, the existing device belongs
to and was
created by the serial driver.

To be even more technical, device interfaces are just symbolic links to
devices. I’d recommend to use WinObj tool to examine created
interfaces/links and their values. It can be rather surprising
experience

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

OSR_Community_User · April 13, 2008, 4:04am

Hello all,

Thank you very much for your help. I’m very glad to join to ntdev forum - it’s very challenging experience :-).

Sasha.