GUIDs

NTDEV
1

Hi again,

So I’ve been looking through the UMDF skeleton sample and the fx2 sample drivers, and am getting a fair way towards understanding what they are doing now.

I’m a little confused about all the GUIDs used and was hoping someone could clarify what each one is for.

In the fx2 driver I see 4 unique GUIDs referenced in 5 places:

Internal.h

WudfOsrUsbFx2TraceGuid da5fbdfd,1eae,4ecf,b426,a3818f325ddb
I assume this is only used by the trace controller to select just the traces from this driver

MYDRIVER_CLASS_ID { 0x0865b2b0, 0x6b73, 0x428f, {0xa3, 0xea, 0x21, 0x72, 0x83, 0x2d, 0x6b, 0xfc} }
This has to be the same as the DriverCLSID field in the inx. It is a way to link the inf to the driver?

WUDFOsrUsbFx2.inx

ClassGuid 78A1C341-4539-11d3-B88D-00C04FAD5171
This is paired with the class type, but not related to the MYDRIVER_CLASS_ID or DriverCLSID, and is just used to decide where to place the device in device manager

DriverCLSID 0865b2b0-6b73-428f-a3ea-2172832d6bfc
This has to be the same as the MYDRIVER_CLASS_ID from internal.h

WUDFOsrUsbPublic.h

(I realise this is from a different project to the above ones, but I’m trying to change the skeleton code so that I can access the driver from my application)
DEFINE_GUID(GUID_DEVINTERFACE_OSRUSBFX2, 0x573e8c73, 0xcb4, 0x4471, 0xa1, 0xbf, 0xfa, 0xb2, 0x6c, 0x31, 0xd3, 0x84);
This is used to expose the device’s interface to applications, so they can open the driver using CreateFile, although we tend to use symbolic links to make the string simpler?

I feel like I’m making progress porting the skeleton driver to my own hardware, but I can see myself getting stuck sometime soon because these GUIDs are wrong.

In my code I have replaced all the above GUIDs with ones generated using the uuidgen tool, can I assume that’s correct?

Thanks again,
Andrew Parlane

2

xxxxx@carallon.com wrote:

I’m a little confused about all the GUIDs used and was hoping someone could clarify what each one is for.

In the fx2 driver I see 4 unique GUIDs referenced in 5 places:

Internal.h

WudfOsrUsbFx2TraceGuid da5fbdfd,1eae,4ecf,b426,a3818f325ddb
I assume this is only used by the trace controller to select just the traces from this driver

Correct.

MYDRIVER_CLASS_ID { 0x0865b2b0, 0x6b73, 0x428f, {0xa3, 0xea, 0x21, 0x72, 0x83, 0x2d, 0x6b, 0xfc} }
This has to be the same as the DriverCLSID field in the inx. It is a way to link the inf to the driver?

Sort of. UMDF drivers are COM objects. This is the COM CLSID for your
UMDF driver. UMDF loads your driver using this CLSID.

WUDFOsrUsbFx2.inx

ClassGuid 78A1C341-4539-11d3-B88D-00C04FAD5171
This is paired with the class type, but not related to the MYDRIVER_CLASS_ID or DriverCLSID, and is just used to decide where to place the device in device manager

Correct.

DriverCLSID 0865b2b0-6b73-428f-a3ea-2172832d6bfc
This has to be the same as the MYDRIVER_CLASS_ID from internal.h

Correct.

WUDFOsrUsbPublic.h

(I realise this is from a different project to the above ones, but I’m trying to change the skeleton code so that I can access the driver from my application)
DEFINE_GUID(GUID_DEVINTERFACE_OSRUSBFX2, 0x573e8c73, 0xcb4, 0x4471, 0xa1, 0xbf, 0xfa, 0xb2, 0x6c, 0x31, 0xd3, 0x84);
This is used to expose the device’s interface to applications, so they can open the driver using CreateFile, although we tend to use symbolic links to make the string simpler?

Yes. Device interfaces make it easier to support multiple drivers,
because you can use the SetupDi APIs to enumerate through all of the
devices supporting a particular device interface. The symbolic link
mechanism is somewhat error prone.

In my code I have replaced all the above GUIDs with ones generated using the uuidgen tool, can I assume that’s correct?

Yes.

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

3

Thanks, good to know I was not far off :slight_smile: