Is there a way to detect whether Windows is installing a device driver?

Question

The situation: We have a software suite that interacts with a device we built in-house. The device uses WinUSB for communications, EXCEPT when in boot mode during firmware updates. When in boot mode, the device uses a different VendorID and ProductID and uses HID for communication.

The problem: To update firmware, we send a command across and tell the device to enter boot mode. The device re-enumerates with the new VID and PID. When updating firmware on a new machine that hasn't had a device in boot mode connected before, Windows does the "installing driver" dance when the bootloader shows up. (There's no driver to be installed). Software gets a DEVICE ATTACHED event, and so we begin the firmware update. Once Windows finishes "installing" the driver, it de-enumerates and re-enumerates the device, closing our file handle in the middle of the update.

The question: Is there a way to detect if Windows is installing a driver so that we can wait for the device to be re-enumerated before beginning the update process? Is there something we can do in our install to preempt this behavior? Maybe a way to tell Windows that we don't want to allow driver installation while we're connected to the device?

Patrimony

why don't you check for, say 9 seconds in 3 intervals of 3 seconds if the executable of "installing driver" is running on system? – Falito

Also, I think you can keep record of how many times you've seen this device in your application so you'll know if this is first time and you'll have to wait. – Falito

@r1verside, I've given waiting for a bit a try, but it doesn't seem to be a very clean or effective solution so far. Depending on whether Windows decides to check for a driver online, the user's connection speed, etc, the amount of time waiting could vary drastically. Plus I'd rather not waste the user's time waiting every time they update firmware if I can help it. (There's no need to wait if Windows recognizes the device on a subsequent firmware update). – Patrimony

I have made similar devices before and I never saw the behavior your describe where "it de-enumerates and re-enumerates the device, closing our file handle in the middle of the update". But that could be because my devices either use CDC ACM or WinUSB for their bootloaders. Maybe you should change your bootloader to use one of those types of USB interfaces. – Crenshaw

If you're concerned about the driver installation taking up needless time, why not give it what it wants? Install a dummy driver first with the correct VID/PID. If it's constant you only need to do it once; if dynamic you have to do a little dance yourself. Point is, you're the one dancing so you know when it's done. – Phippen

@DavidGrayson I do agree, I wish we'd been a little more consistent and used the same interface for both, but I was neither the developer of the hardware or firmware. It's a little too late in the game to change it now, being released to the public. I'll definitely see about advocating for this sort of strategy in the future though. – Patrimony

@JeroenMostert, I'll definitely look into finding a way to do this - I wonder if I could just query the registry to see if Windows has finished "installing" the driver, at which point I'd imagine it'd be safe to connect and begin updating. – Patrimony

Duplicate #23926094 – Forth

@Patrimony is the driver installation legitimate, i.e. do you want Windows to complete that driver installation process, at some point? – Faddist

Answer 1

Maybe a way to tell Windows that we don't want to allow driver installation while we're connected to the device?

Microsoft's Developer Network has a section for Hardware Development. They have an article specifically about this issue. Importantly, the document states that your device installation application should "determine whether other installation activities are in progress before performing its installations" (emphasis mine) and - if pending installations are found - "should exit".

This last part of the statement seems to indicate Microsoft gives precedence to already installing or pending device application installations.

If your problem statement is accurate:

When updating firmware on a new machine that hasn't had a device in boot mode connected before, Windows does the "installing driver" dance when the bootloader shows up.

It sounds like you may be out of luck - or breaking a convention - by attempting to preempt the driver installation behavior.

I would utilize the above mentioned CMP_WaitNoPendingInstallEvents function, and then firmware update your device. I think the VID/PID are irrelevant, here, depending upon where your firmware update code is running. It looks like the OSR Online Forum has a question of the same nature and assumes the same precedence (driver installation).

Faddist