Hi all,
Is there a way to list all the device interfaces and their reference strings via windbg?
thanks,
Venkat
I think that this can be done by listing some object directory, which is IIRC done by !object.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> Hi all,
>
> Is there a way to list all the device interfaces and their reference strings via windbg?
>
> thanks,
> Venkat
>
>
You can do that using Powershell and a script that includes the following line:
Get-WMIObject -class “Win32_DiskDrive” -namespace “root\CIMV2” -computername
A little bit of time spent with Google and/or Bing will provide classes that will permit listing most anything you want.
Gary G. Little
----- Original Message -----
From: xxxxx@yahoo.com
To: “Windows System Software Devs Interest List”
Sent: Thursday, August 4, 2011 1:18:01 AM
Subject: [ntdev] Device Interface ReferenceStrings list in Windbg
Hi all,
Is there a way to list all the device interfaces and their reference strings via windbg?
thanks,
Venkat
—
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
Why? If a reference string is provided, it is a part of the dev interface string as a unit, it is all one opaque string. It is not dev interface string + reference string
d
debt from my phone
-----Original Message-----
From: xxxxx@yahoo.com
Sent: Wednesday, August 03, 2011 11:19 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Device Interface ReferenceStrings list in Windbg
Hi all,
Is there a way to list all the device interfaces and their reference strings via windbg?
thanks,
Venkat
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
Thanks for the pointers folks, will check them out…
Doron,
[quote] Why? If a reference string is provided, it is a part of the dev interface string
as a unit, it is all one opaque string. It is not dev interface string +
reference string [/quote]
I have a device that has multiple slots appearing as separate devices. I want them to be controlled by one driver, and wanted to register their interfaces with a reference string to differentiate them.
Now, on the client side, I wanted to see if I can avoid using the cryptic symbolic link the interfaces get, and instead simply use the reference string instead (which is defined by me). Looks like that is not do-able. In order to enable a way of accessing the interface in a constant fashion, should I be creating symbolic links to the device and then call query interface based on that symbolic link?
thanks,
Venkat
xxxxx@yahoo.com wrote:
I have a device that has multiple slots appearing as separate devices. I want them to be controlled by one driver, and wanted to register their interfaces with a reference string to differentiate them.
Now, on the client side, I wanted to see if I can avoid using the cryptic symbolic link the interfaces get, and instead simply use the reference string instead (which is defined by me). Looks like that is not do-able.
The reference string becomes part of the “cryptic symbolic link”.
In order to enable a way of accessing the interface in a constant fashion, should I be creating symbolic links to the device and then call query interface based on that symbolic link?
If you want friendly names for your device, you need to create your own
symbolic links. It’s then up to you to deal with disambiguating
multiple instances, which is the problem device interfaces were intended
to solve.
Are your clients user-mode or kernel-mode?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Why reinvent the wheel? Why do you need to differentiate between the instances?
d
debt from my phone
-----Original Message-----
From: Tim Roberts
Sent: Thursday, August 04, 2011 12:09 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Device Interface ReferenceStrings list in Windbg
xxxxx@yahoo.com wrote:
I have a device that has multiple slots appearing as separate devices. I want them to be controlled by one driver, and wanted to register their interfaces with a reference string to differentiate them.
Now, on the client side, I wanted to see if I can avoid using the cryptic symbolic link the interfaces get, and instead simply use the reference string instead (which is defined by me). Looks like that is not do-able.
The reference string becomes part of the “cryptic symbolic link”.
In order to enable a way of accessing the interface in a constant fashion, should I be creating symbolic links to the device and then call query interface based on that symbolic link?
If you want friendly names for your device, you need to create your own
symbolic links. It’s then up to you to deal with disambiguating
multiple instances, which is the problem device interfaces were intended
to solve.
Are your clients user-mode or kernel-mode?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
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
hi Tim,
“The reference string becomes part of the “cryptic symbolic link”.”
I want to avoid using this cryptic link since it isn’t easy for clients to know apriori (and requires some string manipulation) and my clients are mostly in kernel mode and so wanted to publish a query interface as well.
Doron,
“Why reinvent the wheel? Why do you need to differentiate between the instances?”
They are physically distinct devices with different memory mapped IO. And clients will be interested in particular slots, and they need a way to procure the interface to a device in a deterministic way. So names like slot0, slot1 etc that i use to assign to the devices upon add, are ambiguous and requires further qualification to resolve that ambiguity. Are there concerns in using Friendly names (via Symbolic link ) to get the device and then use the QueryInterface API?
thanks,
Venkat
You can store properties for a device interface+ref string symlink, see http://msdn.microsoft.com/en-us/library/ff549433(v=VS.85).aspx, IoOpenDeviceInterfaceRegistryKey. Basically, the driver can write “SlotNumber” : REG_DWORD : in there that the client can query for when they get notified that the slot has shown up.
> They are physically distinct devices with different memory mapped IO.
Why would the client care? Are they going to use the memory mapped io themselves? Wouldn’t that be taken care of by your driver? If by friendly names, you mean fixed symbolic link names, yes, that would be a problem if your device can be surprise removed and reinserted.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Thursday, August 04, 2011 12:32 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Device Interface ReferenceStrings list in Windbg
hi Tim,
“The reference string becomes part of the “cryptic symbolic link”.”
I want to avoid using this cryptic link since it isn’t easy for clients to know apriori (and requires some string manipulation) and my clients are mostly in kernel mode and so wanted to publish a query interface as well.
Doron,
“Why reinvent the wheel? Why do you need to differentiate between the instances?”
They are physically distinct devices with different memory mapped IO. And clients will be interested in particular slots, and they need a way to procure the interface to a device in a deterministic way. So names like slot0, slot1 etc that i use to assign to the devices upon add, are ambiguous and requires further qualification to resolve that ambiguity. Are there concerns in using Friendly names (via Symbolic link ) to get the device and then use the QueryInterface API?
thanks,
Venkat
—
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
hi Doron,
Why would the client care? Are they going to use the memory mapped io themselves? Wouldn’t that be taken care of by your driver? If by friendly names, you mean fixed symbolic link names, yes, that would be a problem if your device can be surprise removed and reinserted.
They arent going to use the io directly, but via the device they are getting the interface with. Also the devices are ACPI enumerated, and cannot be surprise removed. In that scenario, will the friendly names work?
You can still have a software surprise removal even if the underlying bus will never report the device as missing. Fixed names do not give the client notification of arrival or removal which means they have to poll or use some other non std way to know when the slots arrive .
d
debt from my phone
-----Original Message-----
From: xxxxx@yahoo.com
Sent: Thursday, August 04, 2011 1:28 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Device Interface ReferenceStrings list in Windbg
hi Doron,
Why would the client care? Are they going to use the memory mapped io themselves? Wouldn’t that be taken care of by your driver? If by friendly names, you mean fixed symbolic link names, yes, that would be a problem if your device can be surprise removed and reinserted.
They arent going to use the io directly, but via the device they are getting the interface with. Also the devices are ACPI enumerated, and cannot be surprise removed. In that scenario, will the friendly names work?
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
ah.ok. So if I were to go the CreateDeviceInterface route with reference strings, is it OK for the client to query the interfaces via?IoGetDeviceInterfaces and then do some string manipulation with the reference string to determine which symbolic link to use?
Or is there a better way for the client to get a handle to the interface to the device the client is interested in? There will be multiple devices registering with the same GUID for the interface as they arrive and currently the only way i can distinguish is through reference strings. I am relatively new to Windows drivers and as such dont have a feel for the right approach.?
thanks,
Venkat
From: Doron Holan
To: Windows System Software Devs Interest List
Sent: Thursday, August 4, 2011 1:33 PM
Subject: RE: RE:[ntdev] Device Interface ReferenceStrings list in Windbg
You can still have a software surprise removal even if the underlying bus will never report the device as missing. Fixed names do not give the client notification of arrival or removal which means they have to poll or use some other non std way to know when the slots arrive .
d
debt from my phone
-----Original Message-----
From: xxxxx@yahoo.com
Sent: Thursday, August 04, 2011 1:28 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Device Interface ReferenceStrings list in Windbg
hi Doron,
> Why would the client care? Are they going to use the memory mapped io themselves? Wouldn’t that be taken care of by your driver?? If by friendly names, you mean fixed symbolic link names, yes, that would be a problem if your device can be surprise removed and reinserted.
They arent going to use the io directly, but via the device they are getting the interface with. Also the devices are ACPI enumerated, and cannot be surprise removed. In that scenario, will the friendly names work?
—
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
No, the clients do not parse the string for the ref string. The whole string is opaque. I already gave you what you need, the clients can use the entire string and open the reg key with the API I gave earlier.
Also, your clients should use ioregisterplugplaynotification to find the interface, that way they will be notified later if it arrives after they initially load .
d
debt from my phone
From: Venkat Narain
Sent: Thursday, August 04, 2011 1:55 PM
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] Device Interface ReferenceStrings list in Windbg
ah.ok. So if I were to go the CreateDeviceInterface route with reference strings, is it OK for the client to query the interfaces via IoGetDeviceInterfaces and then do some string manipulation with the reference string to determine which symbolic link to use?
Or is there a better way for the client to get a handle to the interface to the device the client is interested in? There will be multiple devices registering with the same GUID for the interface as they arrive and currently the only way i can distinguish is through reference strings. I am relatively new to Windows drivers and as such dont have a feel for the right approach.
thanks,
Venkat
From: Doron Holan
To: Windows System Software Devs Interest List
Sent: Thursday, August 4, 2011 1:33 PM
Subject: RE: RE:[ntdev] Device Interface ReferenceStrings list in Windbg
You can still have a software surprise removal even if the underlying bus will never report the device as missing. Fixed names do not give the client notification of arrival or removal which means they have to poll or use some other non std way to know when the slots arrive .
d
debt from my phone
-----Original Message-----
From: xxxxx@yahoo.commailto:xxxxx
Sent: Thursday, August 04, 2011 1:28 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Device Interface ReferenceStrings list in Windbg
hi Doron,
> Why would the client care? Are they going to use the memory mapped io themselves? Wouldn’t that be taken care of by your driver? If by friendly names, you mean fixed symbolic link names, yes, that would be a problem if your device can be surprise removed and reinserted.
They arent going to use the io directly, but via the device they are getting the interface with. Also the devices are ACPI enumerated, and cannot be surprise removed. In that scenario, will the friendly names work?
—
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>
Venkat Narain wrote:
ah.ok. So if I were to go the CreateDeviceInterface route with
reference strings, is it OK for the client to query the interfaces
via IoGetDeviceInterfaces and then do some string manipulation with
the reference string to determine which symbolic link to use?Or is there a better way for the client to get a handle to the
interface to the device the client is interested in? There will be
multiple devices registering with the same GUID for the interface as
they arrive and currently the only way i can distinguish is through
reference strings. I am relatively new to Windows drivers and as such
dont have a feel for the right approach.
Remember, please, that there is no connection between a “device
interface” and the “query interface” API. Despite the similarity of the
names, the concepts are completely unrelated. “Device interface” is a
setup thing. It lets your device object be found and opened as a file.
“Query interface” is a type of IRP for exchanging function pointers.
It might be simpler if you just had everyone use the same path to open
the driver, then used an ioctl to ask “what kind of a device are you?”
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
hi Tim,
I understand the difference between device interface and query interface. Idea is to get the device object via device interface and then query the interface the device object supports.
"It might be simpler if you just had everyone use the same path to open
the driver, then used an ioctl to ask “what kind of a device are you?”
I thought if we register for the same GUID again, we get a new symbolic link. If that is the case how can i have one path for all the devices that create the device interface? Based on what Doron suggested, I am thinking of implementing a ping IOCTL that basically tells the client which device it is, and then let the client enumerate all the instances supporting the given device interface guid to detect the device it needs. Anything wrong with this approach?
thanks,
xxxxx@yahoo.com wrote:
I understand the difference between device interface and query interface. Idea is to get the device object via device interface and then query the interface the device object supports.
"It might be simpler if you just had everyone use the same path to open
the driver, then used an ioctl to ask “what kind of a device are you?”I thought if we register for the same GUID again, we get a new symbolic link. If that is the case how can i have one path for all the devices that create the device interface? Based on what Doron suggested, I am thinking of implementing a ping IOCTL that basically tells the client which device it is, and then let the client enumerate all the instances supporting the given device interface guid to detect the device it needs. Anything wrong with this approach?
Yes, I only gave you half of an implementation. I’m distracted today.
If you have multiple device instances, and its sounds like you do, then
in my opinion, device interfaces are the only good method for handling
them. They work from user mode (using SetupDi) and from kernel mode
(using IoGetDeviceInterfaces). In each case, you’ll get a list of all
devices implementing the interface.
I’m still a bit confused about your architecture. You intend to have a
number of different devices, all being driven by a single driver.
Clients might need some particular device to solve some particular
problem. Right? If each of the clients needs some particularly device,
then it can open each one and do an ioctl to query the capabilities,
then keep the one it likes. On the other hand, GUIDs are free, so why
not just have a different GUID for each type of device? Doesn’t that
solve the problem as well?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Actually having multiple GUIDs simplifies this problem on the client side. Is there a recommended way to maintain an array of GUIDs? Can I have a look up table in the driver?
thanks,
Venkat?
From: Tim Roberts
To: Windows System Software Devs Interest List
Sent: Thursday, August 4, 2011 5:21 PM
Subject: Re: [ntdev] Device Interface ReferenceStrings list in Windbg
xxxxx@yahoo.com wrote:
> I understand the difference between device interface and query interface. Idea is to get the device object via device interface and then query the interface the device object supports.
>
> "It might be simpler if you just had everyone use the same path to open
> the driver, then used an ioctl to ask “what kind of a device are you?”
>
> I thought if we register for the same GUID again, we get a new symbolic link. If that is the case how can i have one path for all the devices that create the device interface? Based on what Doron suggested, I am thinking of implementing a ping IOCTL that basically tells the client which device it is, and then let the client enumerate all the instances supporting the given device interface guid to detect the device it needs. Anything wrong with this approach?
Yes, I only gave you half of an implementation.? I’m distracted today.
If you have multiple device instances, and its sounds like you do, then
in my opinion, device interfaces are the only good method for handling
them.? They work from user mode (using SetupDi) and from kernel mode
(using IoGetDeviceInterfaces).? In each case, you’ll get a list of all
devices implementing the interface.
I’m still a bit confused about your architecture.? You intend to have a
number of different devices, all being driven by a single driver.
Clients might need some particular device to solve some particular
problem.? Right?? If each of the clients needs some particularly device,
then it can open each one and do an ioctl to query the capabilities,
then keep the one it likes.? On the other hand, GUIDs are free, so why
not just have a different GUID for each type of device?? Doesn’t that
solve the problem as well?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
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
>Or is there a better way for the client to get a handle to the interface to the device the client is interested in?
Yes.
Either IoOpenDeviceInterfaceRegistryKey and put some data there, or implement IOCTL_GET_ID which will return this data, and call this IOCTL from user mode.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
I *still* don’t understand why the OP doesn’t love the solution Doron provided yesterday: Using IoOpenDeviceInterfaceRegistryKey. This allows an totally unlimited mechanism to provide custom information about a particular interface instance. And, if you’re worried about making the client driver too complex, you can bury it all in a kernel-mode DLL that’s shared by your clients. They can then call “GetMeTheRightDeviceLink” or whatever in the DLL and it’ll hand them back whatever they need.
Or, if you have an unreasonable fear of the Registry, use the Device Interface to receive notification of the arrival/departure of individual devices… and then open the devices by pre-defined friendly name. Nobody says you have to USE the Device Interface when you’re told it arrives, right? So, let’s say you’re client driver is looking for the lathe device, among a series of machine tools… Each time he gets informed of a Device Interface arrival, he attempts to open Lathe0. If that device has arrived, you’re good. If, say, the device representing some OTHER machine tool was the one that arrived, don’t do anything and try again on the next interface arrival.
And, yes… you COULD use entirely unique GUIDs for each type of device. It depends, architecturally, on what you’re trying to achieve. If these devices export different interfaces, then different interface GUIDs make sense. If, OTOH, you merely have multiple instances of the same device – that export what is effectively the same interface – then using a separate GUID for each strikes me as a sloppy solution.
In any case, I don’t see why this is sooo difficult. Am I missing something, OP?
Peter
OSR
Hi Peter,
It isnt difficult, just that I am not sure what is the best approach since I am new to the KMDF world. Also you gave a perfect example of what I am trying to achieve.
Now to your questions:
-
Registry: I am not exactly apprehensive of this solution, but was looking for a programmatic way of getting this done. Also if i were to store the symbolic link, will I be getting the exact same symlink for the device every time i boot or should i clear the registry upon driverentry?
-
Friendly names: Per Dolan surprise removal can cause problems with surprise removal and reinsert. So didnt take that approach
-
So that left me with using unique IDs or IOCTL_GET_ID. I am leaning towards the IOCTL_GET_ID since this can keep the driver platform independent.
Hope I’ve answered all the questions. Thanks Maxim. I am also leaning towards the IOCTL approach.
thanks,
Venkat