>No, you’re confusing setup class and device interface class (again). The GUID in the INF controls into which device class (i.e. in Device Manager) a device installed. The device interface class GUID uniquely identifies your contract with the owner of the device interface.
I am sorry I confused again 
Let me take it step by step:
a) I will define a class GUID in the inf file. This GUID is setup class GUID. If I successfully installed the device with this inf, I can see the same GUID in HKLM\System\CurrentControlSet\Control\Class\xxx (GUID), is this correct?
b) The GUID in inf is setup class GUID. I guess this GUID can be used beyond the inf. I checked msdn and found one parameter of SetupdiGetClassDevs is defined as “LPGUID ClassGuid”. The msdn indicates it could be a device setup class or a device interface class. So if I use GUID defined in inf as parameter for SetupdiGetClassDevs, I will get a handle. The handle points to a device information set, this information set contains all installed devices with the same setup class GUID. For example, if I use GUID_DEVCLASS_USB as GUID in inf and as a parameter to SetupdiGetClassDevs, the return handle indicates to a information set which contains all USB devices. Is this correct?
c) I checked msdn for SetupDiEnumDeviceInterfaces. It has a parameter as “LPGUID InterfaceClassGuid”. This InterfaceClassGuid isn’t a setup class GUID, it is a pointer to device interface, I guess this is what you called device interface class GUID. I should not use the same value, for example, GUID_DEVCLASS_USB for both SetupdiGetClassDevs and SetupDiEnumDeviceInterfaces. Is this correct?
Thanks very much.
On Thu, Apr 24, 2008 at 10:44:15PM -0400, xxxxx@hotmail.com wrote:
xxxxx@probo.com wrote:
> No. A device class GUID is specified in an INF file. Every device
> INF file has a class in its [Version] header, and every device belongs
> to one device class. That class determines where it gets listed in
> Device Manager, and it determines which class GUID you need to use in
> SetupDiGetClassDevs to find the device.
Does this mean if I use SetupdiGetClassDevs and
SetupDiEnumDeviceInterfaces with this GUID (used in INF) then I can found
all devices listed in HKLM\System\CurrentControlSet\Control\Class\xxxx
(GUID) ?
The GUIDs in Control\Class are install classes. SetupDiGetClassDevs
will enumerate those.
SetupDiEnumDeviceInterfaces cannot be used with install class GUIDs.
Well, it CAN be used, but it won’t find anything, because that’s not a
GUID that drivers register.
Tim Roberts, xxxxx@probo.com
Providenza & Boeklheide, Inc.
xxxxx@probo.com wrote:
If you are really just trying to open a stock Cypress driver, skip all of the SetupDi magic and use their name: hDriver = CreateFile( “\\.\EzUsb-0”, … );
My purpose is to develop API with driver. Because I am a new comer to driver, I take Cypress USB as examples. I guess if I need to communicate API with driver, I need to create a handle points to driver, for example, use MyDriverHandle = CreateFile(MyHandle). The MyDriverHandle will be the bridge between API and driver.
In order to get MyDriverHandle, I need to use SetupdiGetClassDevs to find a handle FirstHandle. I will use FirstHandle as parameter to SetupDiEnumDeviceInterfaces to find a handle (SecondHandle) which indicates to my device. Then I will use SecondHandle as parameter to SetupDiGetDeviceInterfaceDetail to get MyHandle. So at last I can use MyHandle to bridge between API and driver. Is my understanding right?
Thanks very much.
On Fri, Apr 25, 2008 at 01:59:48AM -0400, xxxxx@hotmail.com wrote:
I am sorry I confused again
Let me take it step by step:
a) I will define a class GUID in the inf file. This GUID is setup class
GUID. If I successfully installed the device with this inf, I can see
the same GUID in HKLM\System\CurrentControlSet\Control\Class\xxx (GUID),
is this correct?
Yes.
b) The GUID in inf is setup class GUID. I guess this GUID can
be used beyond the inf. I checked msdn and found one parameter of
SetupdiGetClassDevs is defined as “LPGUID ClassGuid”. The msdn indicates
it could be a device setup class or a device interface class. So if I use
GUID defined in inf as parameter for SetupdiGetClassDevs, I will get a
handle. The handle points to a device information set, this information
set contains all installed devices with the same setup class GUID. For
example, if I use GUID_DEVCLASS_USB as GUID in inf and as a parameter
to SetupdiGetClassDevs, the return handle indicates to a information
set which contains all USB devices. Is this correct?
Yes. Specifically, SetupDiGetClassDevs assumes you are giving it a
setup class GUID, unless you specify the DIGCF_DEVICEINTERFACE flag.
Only then does it know that you gave it a device interface GUID.
They aren’t interchangable.
c) I checked msdn for SetupDiEnumDeviceInterfaces. It has a parameter
as “LPGUID InterfaceClassGuid”. This InterfaceClassGuid isn’t a setup
class GUID, it is a pointer to device interface, I guess this is what
you called device interface class GUID. I should not use the same
value, for example, GUID_DEVCLASS_USB for both SetupdiGetClassDevs and
SetupDiEnumDeviceInterfaces. Is this correct?
Yes. I think you now have things straight!
Tim Roberts, xxxxx@probo.com
Providenza & Boeklheide, Inc.
xxxxx@probo.com wrote:
c) I checked msdn for SetupDiEnumDeviceInterfaces. It has a parameter > as “LPGUID InterfaceClassGuid”. This InterfaceClassGuid isn’t a setup > class GUID, it is a pointer to device interface, I guess this is what > you called device interface class GUID. I should not use the same > value, for example, GUID_DEVCLASS_USB for both SetupdiGetClassDevs and > SetupDiEnumDeviceInterfaces. Is this correct?
> Yes. I think you now have things straight!
Thanks for your reply. Then if I want to develop API associate with driver, I need to use device interface class GUID as parameter to SetupDiEnumDeviceInterfaces, which will find a handle to device. This device interface class GUID is generated by IoRegisterDeviceInterface, which is part of driver. So if I don’t have source code of driver and don’t know this device interface class GUID, I can’t associate API with driver. Is this correct?
Thanks very much.
xxxxx@hotmail.com wrote:
Thanks for your reply. Then if I want to develop API associate with driver, I need to use device interface class GUID as parameter to SetupDiEnumDeviceInterfaces, which will find a handle to device. This device interface class GUID is generated by IoRegisterDeviceInterface, which is part of driver. So if I don’t have source code of driver and don’t know this device interface class GUID, I can’t associate API with driver. Is this correct?
Yes. Well, as Anton said, it is possible to go reverse engineering
through the entire list of symbolic links to figure out which GUIDs are
associated with which devices, but there is a larger problem here.
If you don’t have enough control over the driver to know whether it
exports a device interface, then you don’t have any idea what ioctls it
supports. How can you possibly create an API for a driver, when you
don’t know what it does?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
xxxxx@probo.com wrote:
If you don’t have enough control over the driver to know whether it exports a device interface, then you don’t have any idea what ioctls it supports. How can you possibly create an API for a driver, when you don’t know what it does?
Thanks for your reply. What confused me is that: I have a usb camera plugged into computer and my msn/skype or other IM could use this camera easily. How did these tools find my camera? Is there anything different from events we mention above? Thanks very much.
skyworld wrote:
What confused me is that: I have a usb camera plugged into
computer and my msn/skype or other IM could use this camera
easily. How did these tools find my camera?
Well, the well-known device classes, of which USB cameras are certainly one, expose well-known interfaces (and GUIDs). When the driver advertises GUID X, implicit in that advertisement is the contract of I/O that it will understand.
Your situation is different. You’re developing a custom device (say, the Cypress board) and so you need to create your own, unique GUID and interface/contract.
>Your situation is different. You’re developing a custom device (say, the Cypress board) and so you need to create your own, unique GUID and interface/contract.
Thanks very much for your help.
Hi,
I wrote a test driver for this Cypress USB. This time I use inf to load the driver and installed it successfully. In the inf file, I set such parameters:
[Version]
Signature = “$CHICAGO$”
Class=USB
ClassGUID={36fc9e60-c465-11cf-8056-444553540000}
…
[CY_USB_Model_Inst.ntx86.Interfaces]
AddInterface ={feca14b8-9796-452c-ac3b-878c9ebd542b},CY’s usb guid,CY_USB_Modelntx86Interface0
At last I found this {feca14b8-9796-452c-ac3b-878c9ebd542b} within registery at HKLM\system\CurrentControlSet\DeviceClasses and I got its SymbolicLink as “\?\USB#VID_04B4&PID_8613#5&1925CE3C&0&3#{feca14b8-9796-452c-ac3b-878c9ebd542b}\CY’s usb guid”.
I guess the GUID {36fc9e60-c465-11cf-8056-444553540000} is what called setup GUID and GUID {feca14b8-9796-452c-ac3b-878c9ebd542b} is device interface GUID. Is this correct?
But unforunately when I use {feca14b8-9796-452c-ac3b-878c9ebd542b} as GUID to SetupDiEnumDeviceInterfaces, I failed again. Did I misunderstand something again? Does this mean I have to use this SymbolicLink as parameter to CreateFile and use this to access driver? Thanks very much.
Even when you use the AddInterface directive in an INF you still need to register and set the device interface state in your driver.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Tuesday, April 29, 2008 11:44 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to find device through GUID
Hi,
I wrote a test driver for this Cypress USB. This time I use inf to load the driver and installed it successfully. In the inf file, I set such parameters:
[Version]
Signature = “$CHICAGO$”
Class=USB
ClassGUID={36fc9e60-c465-11cf-8056-444553540000}
…
[CY_USB_Model_Inst.ntx86.Interfaces]
AddInterface ={feca14b8-9796-452c-ac3b-878c9ebd542b},CY’s usb guid,CY_USB_Modelntx86Interface0
At last I found this {feca14b8-9796-452c-ac3b-878c9ebd542b} within registery at HKLM\system\CurrentControlSet\DeviceClasses and I got its SymbolicLink as “\?\USB#VID_04B4&PID_8613#5&1925CE3C&0&3#{feca14b8-9796-452c-ac3b-878c9ebd542b}\CY’s usb guid”.
I guess the GUID {36fc9e60-c465-11cf-8056-444553540000} is what called setup GUID and GUID {feca14b8-9796-452c-ac3b-878c9ebd542b} is device interface GUID. Is this correct?
But unforunately when I use {feca14b8-9796-452c-ac3b-878c9ebd542b} as GUID to SetupDiEnumDeviceInterfaces, I failed again. Did I misunderstand something again? Does this mean I have to use this SymbolicLink as parameter to CreateFile and use this to access driver? Thanks very much.
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
xxxxx@hotmail.com wrote:
I wrote a test driver for this Cypress USB.
So, this is a driver you wrote? That makes things easier. 
This time I use inf to load the driver and installed it successfully. In the inf file, I set such parameters:
[Version]
Signature = “$CHICAGO$”
Class=USB
ClassGUID={36fc9e60-c465-11cf-8056-444553540000}
…
[CY_USB_Model_Inst.ntx86.Interfaces]
AddInterface ={feca14b8-9796-452c-ac3b-878c9ebd542b},CY’s usb guid,CY_USB_Modelntx86Interface0
At last I found this {feca14b8-9796-452c-ac3b-878c9ebd542b} within registery at HKLM\system\CurrentControlSet\DeviceClasses and I got its SymbolicLink as “\?\USB#VID_04B4&PID_8613#5&1925CE3C&0&3#{feca14b8-9796-452c-ac3b-878c9ebd542b}\CY’s usb guid”.
I guess the GUID {36fc9e60-c465-11cf-8056-444553540000} is what called setup GUID and GUID {feca14b8-9796-452c-ac3b-878c9ebd542b} is device interface GUID. Is this correct?
That is correct.
But unforunately when I use {feca14b8-9796-452c-ac3b-878c9ebd542b} as GUID to SetupDiEnumDeviceInterfaces, I failed again. Did I misunderstand something again? Does this mean I have to use this SymbolicLink as parameter to CreateFile and use this to access driver? Thanks very much.
The AddInterface directive merely advertises the device interface for
applications. The driver still has to call IoSetDeviceInterfaceState to
signal that it is ready to handle that interface. Are you calling
IoSetDeviceInterfaceState? Is your driver actually handling IRP_MJ_CREATE?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
xxxxx@microsoft.com wrote:
Even when you use the AddInterface directive in an INF you still need to register and set the device interface state in your driver.
Thank you very much.
xxxxx@probo.com wrote:
The AddInterface directive merely advertises the device interface for applications. The driver still has to call IoSetDeviceInterfaceState to signal that it is ready to handle that interface. Are you calling IoSetDeviceInterfaceState? Is your driver actually handling IRP_MJ_CREATE?
In fact I didn’t finish IRP_MJ_CREATE. I hope I can do things step by step, so my idea is to test if I can find and enum device first – I only finished DriverEntry and AddDevice routine. I left other routines empty. In AddDevice I finished IoCreateDevice/IoRegisterDeviceInterface routine. Do you mean I have to finish all routines for a driver then can I call it in a test program? Thanks very much.
>Do you mean I have to finish all routines for a driver then can I call it in a
test
program?
Yes
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
I would just like to point out that if you had started with KMDF, it would have been as simple as DriverEntry+AddDevice+DeviceInterface registration w/out any additional code to be able to find and open a handle in user mode.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, May 01, 2008 4:50 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to find device through GUID
xxxxx@probo.com wrote:
The AddInterface directive merely advertises the device interface for applications. The driver still has to call IoSetDeviceInterfaceState to signal that it is ready to handle that interface. Are you calling IoSetDeviceInterfaceState? Is your driver actually handling IRP_MJ_CREATE?
In fact I didn’t finish IRP_MJ_CREATE. I hope I can do things step by step, so my idea is to test if I can find and enum device first – I only finished DriverEntry and AddDevice routine. I left other routines empty. In AddDevice I finished IoCreateDevice/IoRegisterDeviceInterface routine. Do you mean I have to finish all routines for a driver then can I call it in a test program? Thanks very much.
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
What fun would that be?
On Thu, May 1, 2008 at 10:43 AM, Doron Holan
wrote:
> I would just like to point out that if you had started with KMDF, it would
> have been as simple as DriverEntry+AddDevice+DeviceInterface registration
> w/out any additional code to be able to find and open a handle in user mode.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
> Sent: Thursday, May 01, 2008 4:50 AM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] How to find device through GUID
>
> xxxxx@probo.com wrote:
>
> >The AddInterface directive merely advertises the device interface for
> applications. The driver still has to call IoSetDeviceInterfaceState to
> signal that it is ready to handle that interface. Are you calling
> IoSetDeviceInterfaceState? Is your driver actually handling IRP_MJ_CREATE?
>
> In fact I didn’t finish IRP_MJ_CREATE. I hope I can do things step by
> step, so my idea is to test if I can find and enum device first – I only
> finished DriverEntry and AddDevice routine. I left other routines empty. In
> AddDevice I finished IoCreateDevice/IoRegisterDeviceInterface routine. Do
> you mean I have to finish all routines for a driver then can I call it in a
> test program? Thanks very much.
>
> —
> 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
>
–
Mark Roddy
The large bruise on his head would have been forgone
d
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Thursday, May 01, 2008 2:33 PM
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] How to find device through GUID
What fun would that be?
On Thu, May 1, 2008 at 10:43 AM, Doron Holan > wrote:
I would just like to point out that if you had started with KMDF, it would have been as simple as DriverEntry+AddDevice+DeviceInterface registration w/out any additional code to be able to find and open a handle in user mode.
d
-----Original Message-----
From: xxxxx@lists.osr.commailto:xxxxx [mailto:xxxxx@lists.osr.commailto:xxxxx] On Behalf Of xxxxx@hotmail.commailto:xxxxx
Sent: Thursday, May 01, 2008 4:50 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to find device through GUID
xxxxx@probo.commailto:xxxxx wrote:
>The AddInterface directive merely advertises the device interface for applications. The driver still has to call IoSetDeviceInterfaceState to signal that it is ready to handle that interface. Are you calling IoSetDeviceInterfaceState? Is your driver actually handling IRP_MJ_CREATE?
In fact I didn’t finish IRP_MJ_CREATE. I hope I can do things step by step, so my idea is to test if I can find and enum device first – I only finished DriverEntry and AddDevice routine. I left other routines empty. In AddDevice I finished IoCreateDevice/IoRegisterDeviceInterface routine. Do you mean I have to finish all routines for a driver then can I call it in a test program? Thanks very much.
—
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
–
Mark Roddy — 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></mailto:xxxxx>
xxxxx@hotmail.com wrote:
xxxxx@probo.com wrote:
> The AddInterface directive merely advertises the device interface for applications. The driver still has to call IoSetDeviceInterfaceState to signal that it is ready to handle that interface. Are you calling IoSetDeviceInterfaceState? Is your driver actually handling IRP_MJ_CREATE?
>
In fact I didn’t finish IRP_MJ_CREATE. I hope I can do things step by step, so my idea is to test if I can find and enum device first – I only finished DriverEntry and AddDevice routine. I left other routines empty. In AddDevice I finished IoCreateDevice/IoRegisterDeviceInterface routine. Do you mean I have to finish all routines for a driver then can I call it in a test program? Thanks very much.
Well, hell, yes. I’m amazed that you could come to any other
conclusion. When you open a device file from user mode, the system
sends an IRP_MJ_CREATE request to your driver. If your driver isn’t
handling IRP_MJ_CREATE requests, how in the world do you expect the
creation to succeed?
The I/O system doesn’t handle any requests for you. If your driver
doesn’t handle read requests, then user apps can’t call ReadFile. If
your driver doesn’t handle create requests, then user apps can’t call
CreateFile.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks for all of your help. I will then finish all routines of a driver and check its results. Thanks very much.