Existence of co-installer fails attestation?

We have a driver with a minor modification we’re trying to run through attestation. We haven’t made changes to the .inf for a very long time. The last time we attestation signed was last Feb (2022). Now the validation process of attestation fails with an error indicating “Found legacy AddReg operation defining co-installers (CoInstallers32)”.

Has this enforcement changed since last Feb?
What’s the preferred path forward for a device that requires this coinstaller?
I was under the impression this was only an issue when the Target Platform is Universal. Our target platform is “Desktop”.

If you must know, the need for the coinstaller is because this particular device has multiple serial ports. The enumeration happens in an arbitrary order, but for our closed system I’d like to ensure COM numbers are associated with their corresponding physical location. My coinstaller cycles through the claimed com ports, releases them, then claims them in the appropriate order for each device.

We stopped signing drivers with a coinstaller this year. Could you correct any enumeration issue with an accompanying program?

@Zac_Lockard said:
We stopped signing drivers with a coinstaller this year. Could you correct any enumeration issue with an accompanying program?

Oof. Did I miss some communication of some sort?

I mean anything is possible, but that would probably require something that runs every time the system boots to account for devices being added after installation. Maybe we could create a new startup service that runs every boot and checks for the need to reenumerate? A lot less elegant, requires more work, maintenance, and testing. We made a firmware change to the device that required a single line of code change we were planning to release for general availability ASAP. This little surprise puts me in a precarious spot.

How can I avoid something like this in the future? Impromptu changes that result in a redesign pretty much suck. I mean it’s not rocket science or anything, but for closed systems in critical infrastructure our processes have a lot of regulatory implications that make seemingly small changes take considerable time to filter through respective design, spec, implementation, and various levels of acceptance tests.

Oof. Did I miss some communication of some sort?

The WHCP requirements for Win11 indicated this would be happen but we didn’t indicate an exact timeline. Attestation is aligned with the latest requirements so it also had this policy enforced.

I mean anything is possible, but that would probably require something that runs every time the system boots to account for devices being added after installation. Maybe we could create a new startup service that runs every boot and checks for the need to reenumerate? A lot less elegant, requires more work, maintenance, and testing. We made a firmware change to the device that required a single line of code change we were planning to release for general availability ASAP. This little surprise puts me in a precarious spot.

Understood, let me see if I can find some alternative suggestions.

How can I avoid something like this in the future? Impromptu changes that result in a redesign pretty much suck. I mean it’s not rocket science or anything, but for closed systems in critical infrastructure our processes have a lot of regulatory implications that make seemingly small changes take considerable time to filter through respective design, spec, implementation, and various levels of acceptance tests.

It’s a fair point. I suppose staying up to date on the WHCP requirements is generally the best way to avoid something like this. The nearish future is going to have more requirement changes than long-term since we’re doing quite a bit of work to wind down legacy install behavior (like coinstallers) that have caused problems in the ecosystem. Using the HLK also locks in your requirements for as long as that HLK version is supported, while attestation is always the latest requirement set.

I appreciate your response and willingness to help. My department has a wide spread of responsibilities and it’s sometimes difficult to keep up with where we should be looking to stay up-to-date on changes to requirements such as these. I previously understood (perhaps mistakenly) that legacy install behavior may get deprecated for Universal targets. Could you point me to the most appropriate place to stay up-to-date with WHCP requirements as of today?

You mentioned possible alternate suggestions. I’d love to evaluate those for our needs too! We try really hard to avoid the need for a coinstaller, but for this particular interaction with the ComDB it was the simplest solution I could come up with at the time.

Here are the latest, Win11 22H2. I am also working on an accompanying page in the InfVerif docs that will likely prove easier to digest for developers.

Universal (in terms of a set of requirements) is sort of a checkpoint in a process of modernizing driver behavior. The overall requirements to get a WHQL signature will be approaching the universal requirements over time until they are aligned. We’re currently working on improving the docs to explain this better

If you must know, the need for the coinstaller is because this particular device has multiple serial ports. The enumeration happens in an arbitrary order, but for our closed system I’d like to ensure COM numbers are associated with their corresponding physical location. My coinstaller cycles through the claimed com ports, releases them, then claims them in the appropriate order for each device.

Can you elaborate on this and what has a dependency on the ordering of the ports?

[Mods: Apologies Mr @Zac_Lockard - your simple reply got stuck in the spam filters. I marked your account so this will not happen again.]

@Zac_Lockard said:

If you must know, the need for the coinstaller is because this particular device has multiple serial ports. The enumeration happens in an arbitrary order, but for our closed system I’d like to ensure COM numbers are associated with their corresponding physical location. My coinstaller cycles through the claimed com ports, releases them, then claims them in the appropriate order for each device.

Can you elaborate on this and what has a dependency on the ordering of the ports?

[Mods: Apologies Mr @Zac_Lockard - your simple reply got stuck in the spam filters. I marked your account so this will not happen again.]

I think I understand your question. Basically, “why do we care what the COM port order is?” We have a few devices that have a bunch of serial ports. One example is a card with 6 ports, but our customers typically put 4 cards in one of our industrial computers we design/manufacture. When you have 24 ports it’s difficult to know where COM18 is. Since this is a system we design I know PCI bus order and can use Bus Dev Fun to identify which card is in which slot and sort all the COM ports so they are presented to the system in ascending order. We have another computer that supports 48 ports, 16 onboard and another 32 with an expansion card. Same problem. Same solution.

1 Like

Did anyone find a solution to this? For example registering xml schemas to enable ETW tracing in a driver. We were doing this through a coinstaller. But this isnt available anymore. What is the suggested solution?

IIRC a UM script / program / service that queries / modifies the registry and forces a reboot if necessary.