Hi all,
I tried to submit a package for attestation signing where only the kernel driver has been rebuilt, but the .inf is unchanged, except for the DriverVer line, which has been updated. While this still worked fine a couple of months ago, I now get an error:
InfVerif failed for Driver. Partial Log:Error 1280 in meinberg.inf, line 107 : Class name and ClassGuid mismatch, expecting Class "Sample" for ClassGuid "{78A1C341-4539-11d3-B88D-00C04FAD5171}".
The “Version” section of the inf file reads:
[Version]
Signature="$Windows NT$"
Class=RadioClock
ClassGuid={78A1C341-4539-11d3-B88D-00C04FAD5171}
Provider=%Provider%
;DriverVer=mm/dd/yyyy[,x.y.v.z]
DriverVer=03/22/2022,3.13.0.0
CatalogFile=meinberg.cat
The package includes a single inf file for 2 kernel drivers for i386 and amd64. The kernel drivers handle some PCI and USB devices like radio clocks, GPS receivers, etc., and the class “Radioclock” as well as the ClassGuid code have been used for more than 20 years now.
As expected, the error code 1280 is not listed on the the Microsoft page
INF Validation Errors and Warnings
https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/inf-validation-errors-and-warnings#syntax-in-the-inf-file-1100-1299
Is there someone who can give me a hint what could have changed, so that the submission is now rejected?
Thanks,
Martin
Whomever originally created your INF copied a WDK sample (https://github.com/microsoft/Windows-driver-samples/blob/1fe4cc42bedfccb97a5b2cc169f9e5306d41d0de/gpio/samples/simdevice/umdf/simdeviceumdf.inx) and when defining a new class (why do you need a new class?) only changed the Class= name, not the ClassGuid= value. The updated InfVerif validates that none of the relevant names and values (guids, service names, etc) from the samples are a part of a third party driver package. It worked for 20 years until this point because it was a silent error that was lurking…what would have happened if another driver package was installed that used the same Sample ClassGuid with a different class name?
I filed a bug on the error table to have it updated.
I have created a pull request with updates to the docs that includes errors 1280 and 1281
It worked for 20 years until this point because it was a silent error that was lurking
OMG, yes.
Between people using the example GUIDs in their INFs and people using the VID/DID from the manufacturers Dev Kits, it’s enough to make a developer insane.
I had a client who was using a very popular dev kit VID/DID for their medical device; When I told them it needed to be changed, the FPGA guy had no idea what I was talking about. I mean… they were perfectly HAPPY to change it, but choosing a VID/DID was entirely NOT on their radar (and not entirely obvious, considering the vendor wasn’t about to join the PCI Sig… but that’s another story for another time).
I had taken a look at the submissions we were getting at some point and we had thousands and thousands that were the same Sample ClassGuid. Most had changed the Class name since that was more obvious, but that is a cosmetic change. Same goes for sample service names. I hate to make samples not build cleanly right away but I don’t have another way to force people to change important things (other than fail at signing, which would be much more annoying imo).
Anyway the above referenced docs have an explanation for 1280 and 1281, live now
@Doron_Holan said:
Whomever originally created your INF copied a WDK sample (https://github.com/microsoft/Windows-driver-samples/blob/1fe4cc42bedfccb97a5b2cc169f9e5306d41d0de/gpio/samples/simdevice/umdf/simdeviceumdf.inx)
Indeed, yes, looks like this is the case.
The oldest reference to this file that I could find is from 01/15/2002, and in fact it looks like the colleague who converted our non-PnP driver for Win NT to the first PnP driver for W2k just copied the GUID from the sample code, instead of creating a new GUID. I wasn’t aware that this was the case.
… and when defining a new class (why do you need a new class?)
When we created the first driver for Windows NT, there was no device class that seemed to be appropriate for PCI or ISA cards that contained a GPS receiver, or a radio clock that decoded the longwave signal from the German timecode transmitter DCF77. Though I haven’t investigated, I doubt that there is an appropriate device class today.
… only changed the Class= name, not the ClassGuid= value. The updated InfVerif validates that none of the relevant names and values (guids, service names, etc) from the samples are a part of a third party driver package. It worked for 20 years until this point because it was a silent error that was lurking…what would have happened if another driver package was installed that used the same Sample ClassGuid with a different class name?
So true.
I wonder what will happen with existing driver installations when we ship a driver update that uses a new, good UUID. Probably the best approach would be to ask customers to uninstall the existing driver with the old GUID before installing the new one with the new GUID.
I filed a bug on the error table to have it updated.
Thanks for that, and for your hint!
@Zac_Lockard said:
I had taken a look at the submissions we were getting at some point and we had thousands and thousands that were the same Sample ClassGuid. Most had changed the Class name since that was more obvious, but that is a cosmetic change. Same goes for sample service names. I hate to make samples not build cleanly right away but I don’t have another way to force people to change important things (other than fail at signing, which would be much more annoying imo).
I fully agree, but unfortunately I wasn’t aware that the GUID had just been copied from some sample code.
It’s the old adage again: every mistake catches up with you at some point. 
I’ve now created a new GUID, but unfortunately, there currently seem to be problems with the submission page, which loads only partially, and very slowly, if not even an error is displayed, saying: “Sorry, something went wrong. Please try again later.”
Anyway the above referenced docs have an explanation for 1280 and 1281, live now
Great, and thanks for helping!
“asking customers” to do anything is almost certainly going to fail. You
should have an installer of some sort, and this installer should uninstall
the old driver if present.
Mark Roddy
I wonder what will happen with existing driver installations when we ship a driver update that uses a new, good UUID. Probably the best approach would be to ask customers to uninstall the existing driver with the old GUID before installing the new one with the new GUID.
The issue is when two different driver packages use the same guid to define a custom class. First one installed wins. At minimum, the display name for the class in device manager will be wrong. At worst, the winner sets attributes on the class (security, filters, etc) that are completely incompatible with your device (assuming it was not the winner). Now when moving to a new device class guid from the old one, you have none of these issues. When your new driver package with the new device class guid is installed, the class is installed and then the driver on the device. the install and move to a new class should be completely transparent and your users should not have additional steps outside of the normal install flow.
@Mark_Roddy said:
“asking customers” to do anything is almost certainly going to fail. You
should have an installer of some sort, and this installer should uninstall
the old driver if present.
Agreed. In the past our installer could always just simply upgrade the driver, but I’d expect that this will fail if the ClassGuid has changed. Just a few moments ago I was able to get a package with the new GUID attestation signed, so I’m going to investigate to find a good upgrade path.
BTW, does anybody know if there is a Windows API call to change the GUID of a registered class? Just asking for a friend …
@Doron_Holan said:
The issue is when two different driver packages use the same guid to define a custom class. First one installed wins. At minimum, the display name for the class in device manager will be wrong. At worst, the winner sets attributes on the class (security, filters, etc) that are completely incompatible with your device (assuming it was not the winner).
Yes, I understand these potential problems, and I’m happy that in the last 20 years where this GUID has been used I’ve never heard of any problems due to the duplicate GUID. This is probably because the chance that someone installs the Meinberg driver package and the example driver with the same GUID is very low.
Anyway, I’m always for clean solutions, and I would have immediately stopped to use the old GUID if I had know that it belongs to a different driver. But in fact I didn’t know that.
Now when moving to a new device class guid from the old one, you have none of these issues. When your new driver package with the new device class guid is installed, the class is installed and then the driver on the device. the install and move to a new class should be completely transparent and your users should not have additional steps outside of the normal install flow.
Yes, that’s what I’d expect, and I’ve already created a new GUID.
The potential problem I see is if an older version of the driver package with the old GUID is already installed, and a new driver with the new package becomes available, you can’t simply upgrade, unless I’m missing something. So as far as I can see now, in order to get a clean solution, the old driver has to be installed first, and then the new driver with the new GUID can be installed.
If there are better ideas, that would be appreciated.
The potential problem I see is if an older version of the driver package with the old GUID is already installed, and a new driver with the new package becomes available, you can’t simply upgrade
Why not? You should be able to simply upgrade in this case as the new class gets installed and then the device upgrade proceeds as normal. The device install logic is independent of the class install logic.
BTW, does anybody know if there is a Windows API call to change the GUID of a registered class? J
There is not. This attribute of a device class is considered immutable once the class has been installed.
@Doron_Holan said:
The potential problem I see is if an older version of the driver package with the old GUID is already installed, and a new driver with the new package becomes available, you can’t simply upgrade
Why not? You should be able to simply upgrade in this case as the new class gets installed and then the device upgrade proceeds as normal. The device install logic is independent of the class install logic.
Thanks, I’m going to try that. In the past we had no case where something like this was necessary.
BTW, does anybody know if there is a Windows API call to change the GUID of a registered class? J
There is not. This attribute of a device class is considered immutable once the class has been installed.
Yes, That’s what I’ve expected.
Thanks for your hints!