Oh, I thought you were already using two different interface GUIDs. Does not matter, you still have the same problem if you have more than one device to support in that you need to associate InterfaceX with InterfaceY from the same device. The API you want to use is SetupDiGetDeviceRegistryProperty, not the new property API (although the new property API maps back to the older properties available from SetupDiGetDeviceRegistryProperty). The property you want to query for is SPDRP_PHYSICAL_DEVICE_OBJECT_NAME. the 2 instances belonging to the same device will share the same PDO name. Please note that the PDO name does not remain constant across reboots or unplug/replug, but will remain constant as long as the device is plugged in.
Now, back to the device instance path. To get that string, you need a DEVINST, which you get from SP_DEVINFO_DATA::DevInst. You would then pass this to CM_Get_Device_ID which would fill in the device instance path in your Buffer parameter. You would then compare the device instance paths for the 2 interfaces to see if they were the same.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jeremy Ramer
Sent: Tuesday, March 03, 2009 9:44 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] single device, multiple interface
I think the simplest solution to this issue is to use a unique GUID
for each interface, rather than the same GUID for both interfaces.
On Tue, Mar 3, 2009 at 10:18 AM, Jeremy Ramer wrote:
> I noticed that SetupDiGetDeviceInterfaceProperty() is only available
> for Vista and later. I’m developing for XP so I won’t be able to use
> that.
>
> On Tue, Mar 3, 2009 at 10:06 AM, Jeremy Ramer wrote:
>> Sorry for my lack of knowledge of the device interface. To get this
>> device instance id would you be using
>> SetupDiGetDeviceInterfaceProperty() or SetupDiGetDeviceInstanceId()?
>> I am having issues with both functions, likely because I am not
>> setting up the correct input. The msdn docs seem to be sending me in
>> circles. Are there any sample drivers that use this method? I have not
>> found any yet.
>>
>> On Tue, Mar 3, 2009 at 9:15 AM, Doron Holan wrote:
>>> You most definitely should NOT parse the filename that you get. Instead, you can query for the device instance id property and then do a string compare on that property between 2 interface instances.
>>>
>>> d
>>>
>>> Sent from my phone with no t9, all spilling mistakes are not intentional.
>>>
>>> -----Original Message-----
>>> From: Jeremy Ramer
>>> Sent: Tuesday, March 03, 2009 7:55 AM
>>> To: Windows System Software Devs Interest List
>>> Subject: Re: [ntdev] single device, multiple interface
>>>
>>>
>>> Thanks for the answers! They seem to work well and make sense.
>>>
>>> I am now working through how an application will identify the
>>> interface it wants to use. I am currently using this method to get the
>>> device name:
>>> SetupDiGetClassDevs() - with my GUID
>>> SetupDiEnumDeviceInterfaces()
>>> SetupDiGetDeviceInterfaceDetail()
>>> [allocate memory]
>>> SetupDiGetDeviceInterfaceDetail()
>>>
>>> Is my only option to enum both interfaces and parse the DevicePath to
>>> check for the interface I want? I believe I cannot assume that the
>>> interfaces will always enum in the same order and just use a specific
>>> index in SetupDiEnumDeviceInterfaces(). Are there any better options?
>>>
>>> Thanks!
>>> Jeremy
>>>
>>> On Mon, Mar 2, 2009 at 1:04 PM, Doron Holan wrote:
>>>> To differentiate between the 2 you should set a flag in the context area of the WDFFILEOBJECT. You then check this flag when initially processing each request.
>>>>
>>>> To indicate failure in EvtDeviceFileCreate, complete the WDFREQUEST with a failure NTSTATUS value instead of STATUS_SUCCESS.
>>>>
>>>> d
>>>>
>>>> Sent from my phone with no t9, all spilling mistakes are not intentional.
>>>>
>>>> -----Original Message-----
>>>> From: Jeremy Ramer
>>>> Sent: Monday, March 02, 2009 11:20 AM
>>>> To: Windows System Software Devs Interest List
>>>> Subject: [ntdev] single device, multiple interface
>>>>
>>>>
>>>> Hi,
>>>> I am trying to build a KMDF driver with a single device that has two
>>>> interfaces exposed. One provides exclusive, full read/write access
>>>> while the second interface provides a limited set of ioctls. I’ve
>>>> gathered that the way to do this is with the ReferenceString param of
>>>> WdfDeviceCreateDeviceInterface(). Doron’s blog post seems to verify
>>>> this assumption:
>>>> http://blogs.msdn.com/doronh/archive/2006/08/18/706717.aspx
>>>>
>>>> My question is, do I need to perform the string compare in every
>>>> function my driver exposes or is there some way to do this only in the
>>>> EvtDeviceFileCreate() callback and have an interface-specific object
>>>> to indicate which functions are allowed? I’m guessing that the
>>>> FileObject is unique to each interface, but I am not clear on if/how I
>>>> could manipulate it to add the information I want.
>>>>
>>>> A second question is in regards to the exclusive access. If I
>>>> determine that the device is already in use how would I indicate
>>>> failure to open in EvtDeviceFileCreate() as it returns void?
>>>>
>>>> Thanks!
>>>> Jeremy
>>>>
>>>> —
>>>> 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
>>>
>>
>
—
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