Device driver issue: Class GUID used for "Eye Tracking Devices" is not unique

[CHRISTER OLSSON]

You might receive the same information from Steelseries support, but I’m starting to think that they don’t even read the information I add to my request so I double post the latest update here:

The driver attempts to add a new device type “Eye Tracking Devices” Class GUID {78a1c341-4539-11d3-b88d-00c04fad5171}. This made the driver installation fail on my computer.

If you search for “{78a1c341-4539-11d3-b88d-00c04fad5171}” in Google you get over 500 hits, most of which are driver code examples from Microsoft, so the ID is highly unsuitable to use unless you want to get installation problems on a lot of end user systems.

In my case the conflict is because one of the services in McAfee Web Advisor is using the same GUID, which prevents installing the driver for the Sentry.

I uninstalled McAfee Web Advisor and had to manually remove the registry key blocking the driver installation before I could reinstall the driver and get my Sentry to work.

I tried to report the problem to Steelseries and McAfee support, but they both seems to think I have a problem that they need to solve for me, instead of just forwarding the reported issue to developers and give me feedback that they’ve done so.

[Jenny [Tobii]]

Hi Christer,

You are right that you will get many hits for that GUID on Google. The reason is that it is the Device Class GUID for a ‘Generic WinUSB device’. This is the correct usage of this GUID. The GUID that has to be generated and unique for each system is the Device GUID.

We are using libusb for our driver and have followed the instruction here, under Driver Installation:
http://www.libusb.org/wiki/windows_backend#DriverInstallation
and, more specifically used the second option to download the supplied WinUSB driver and updated the libusb_device.inf file in it. That file itself contains a detailed description on what should be updated:

; 3. Change “DeviceGUID” to a value that is unique on your system. For more
; information and tools to help you generate your own GUIDs, see
; http://en.wikipedia.org/wiki/Universally_Unique_Identifier.
;
; 4. Change “DeviceClassGUID” to reflect your USB Device Class.
; The following Device Classes are listed for reference:
; {745a17a0-74d3-11d0-b6fe-00a0c90f57da} : HID device
; {78a1c341-4539-11d3-b88d-00c04fad5171} : Generic WinUSB device

I hope that clarifies the mystery of the wellknown GUID.

[CHRISTER OLSSON]

In that case I would assume that the assignment of this GUID for “Generic WinUSB device” is a misstake on the part of the developers of libusb.

The libusb example .inf file does say that you can also define your own GUID, which I would consider a better option. With the default on anyone that like me, that have or previously had McAfee SiteAdvisor/WebAdvisor installed on their computer, is going to have a really hard time to get this driver to work.

Also, even if this was a system defined class for “Generic WinUSB device”. Overwriting it with your own definition “Eye tracking devices” could cause some confusion if you have other WinUSB devices with entirely different purposes. If you want to define your own device type and have the device show up under that category in the device manager, assigning you own unique device type GUID seems like the right thing to do, instead of just overwriting the original definition.

The same GUID was used in an example, which seems to be from 2005 according to the driver version, in “Developing Drivers with the Windows Driver Foundation” that was published early 2007. Which is half a year before the initial version of libusb.
https://books.google.co.uk/books?id=_JxCAwAAQBAJ&pg=PT742&lpg=PT742&dq=%7B78a1c341-4539-11d3-b88d-00c04fad5171%7D&source=bl&ots=o4JNXbbPwz&sig=OLzxbZxqmj32D6tDhF3Sb0Hc_RI&hl=sv&sa=X&redir_esc=y#v=onepage&q=%7B78a1c341-4539-11d3-b88d-00c04fad5171%7D&f=false

This example states that you should change the ClassGUID to one suitable for your device. Either a fresh generated one for your own defined class type or one of the system defined classes.

If this was a system defined device class it should be listed as such in the referenced list but it is not:
https://msdn.microsoft.com/en-us/library/ff553426(v=vs.85).aspx

There are other code examples from Microsoft, where the same GUID is used for drivers and services. In all of these examples, the class name is “Sample”, which to me indicates that it is a fictive class example that is not supposed used in the real world (like the telephone numbers in Hollywod movies):
http://blogs.msdn.com/b/iliast/archive/2009/08/13/wdf-logo-requirements-regarding-coinstallers.aspx

[Jenny [Tobii]]

Hi Christer,

Since I’m actually not part of the team that develop the EyeX Controller driver, I will not try to explain their choices more than I have above. I understand your concerns and I will forward your comments to them.

[Author]

Posts