Rescan device tree for hardware changes during Driver installation

Question

I'm using InstallShield to install my application, a driver and a service. I need to install the plug-N-play driver only if it's hardware ID was found in the device manager. The driver installation is done using DPInst.exe. My problem, is that a user can sometimes manually uninstall the driver (After it was installed or even uninstall the "Unknown driver" under "Other devices") and then I can't find the hardware ID in the device tree, although the device is plugged. If I rescan the device tree during installation using CM_Reenumerate_DevNode_Ex (The code equivalent of "Scan for new hardware"), I can find the hardware ID but this brings up the "Found new hardware wizard".

Is there anyway to rescan the device tree but suppress the "Found new hardware wizard" or to avoid rescanning but still making sure my device hardware ID is present in the system?

Cottier

Answer 1

I'm writing a new answer since we already have too many comments on my older one, and its content was based on a small misunderstanding of the situation.

The actual problem, as I understand it now, is the "Add new hardware" wizard that pops-up when rescanning for devices, before installing your driver. Unfortunately, this wizard pops-up whenever no suitable driver is found to handle a new device in the system, so in order to overcome it, the only option is to make sure that such a driver exists in the system. This leads to two possible solutions that I can see:

1. Go for a software first installation, and make sure that your driver is suitable for the device (the inf is well formed, and you have WHQL signing). As far I understand, this is not an option, because you do not want to install the driver on machines that don't have the device connected (I would love to hear why).
2. Make sure that some other driver in the system is suitable to handle it. In that case you need to choose one of the built-in drivers (one that wouldn't wreak havoc if it were to act as a function driver for your device), and give your device a matching compatible ID - one that would cause the built-in driver to be found suitable. This way you will not have to wait for the user after re-scanning for devices, but depending on your device, finding a fitting built-in driver might be impossible.

Curren

First of all, I really appreciate your help. My device is an embedded controller which is not really something you plug and unplug. therefor, if the device hardware ID is not present on the system, it can mean either there is no such controller on the machine or the bios was configured incorrectly. I think that in both cases, the installation should fail and alert the user. Your second solution sounds interesting but I think that eventually I would stay with a message to the user that the installation failed, and he should try to restart the computer before trying to install again. – Cottier

Why would users try to install your driver unless they have your device? How do you distribute your installation? – Curren

There's really no reason why this should happen, but this is (AGAIN) a requirement by our customer. I can think of a scenario: A user tries to run a setup for a different device but accidentally runs wrong installation. – Cottier

In that case I think that the message solution you described above is best. – Curren

Answer 2

It sounds like you're going about it the wrong way. If you have an MSI based installation, why not use DIFxApp instead of DPInst? As for the "Found new hardware" wizard, you'll need two things here:

1. Make sure that your inf file is correct (so that your driver is associated with the hardware id)
2. Get a WHQL signature from MS. This step is needed for XP, as untrusted drivers will not be automatically assigned to devices. With Vista and 7 you can digitally sign the driver yourself, but you'll get a warning during installation, asking the user whether he/she wishes to trust this publisher (you).

Curren

WHQL is in progress. I'm checking for the hardware ID before actually calling DPInst, so I can't understand how the .inf content could be relevant... Am I missing something here? Regarding DiFxApp: We have 2 drivers- one for x32 and the other for x64. I tried to include 2 different DifxApp versions but there are some functions that are called from within other functions in the Difx dll, and I can't control which dll would be called for this functions. I can include 2 different DPInst.exe versions and call the right one conditionally. – Cottier

Even if you check for the existence of the device, the inf is still relevant as it determines what driver will be in charge of the device (and you want it to be yours :)). Additionally, it is necessary in the scenario where the user deleted the device and you're scanning for new hardware. As for x32 vs. x64, as I wrote to you on a different thread, you shouldn't be using a single MSI to handle both x32 and x64 installations. – Curren

As for x32 and x64, I read your answer before, but it's still a requirement by our customer. I know the inf file is important. I just can't understand how Windows knows about my inf before I install it (I don't want to install the driver before making sure I can, so I'm scanning for new Hardware before I install the driver). – Cottier

What do you mean "making sure you can"? You can always pre-install your driver, and Windows will take care to associate it with relevant devices. Windows doesn't know anything about the inf before you install your driver, but the actual installation consists of two parts - a pre-installation after which Windows knows your inf, and actual device installation, at which point your driver is chosen according to the information in the inf. Regarding 64 bits, I think your should explain to your customer that this is a technical limitation of MSI, and give him the option to use a non-MSI solution. – Curren

Making sure I can= If a user doesn't have my device (Which means No hardware ID in the device tree), I want to abort installation. Running DPInst will copy the inf files but would not install the driver and will return with x100. x100 can mean 1 of 2 things: The device is not present on the client's PC OR The device is present but not on the device tree (Therefor a rescan of the device tree will reveal it). I would be happy to know if I have mistaken this scenario. – Cottier

I'm not sure I understand your question, but I believe that you can't use the return code to distinguish between the case where the device is physically connected but removed from the tree, from the case where the device is not physically connected. – Curren

See msdn.microsoft.com/en-us/library/ms791066.aspx. Specifically: 0x00000100 : One driver package was present and was copied to the DIFx driver store, but it was not installed on a device. – Cottier

That means that a pre-install was carried out successfully, but no device was found (either because it's not physically connected, or because it was removed from the device tree - the two are almost identical). However, when a matching device will connect to the machine, assuming your inf is well defined, your driver will be assigned to handle it. As mentioned before, if your driver is not WHQL signed, this will require user interaction on XP. – Curren

My device is embedded within the PC (Although of type "Plug-N-Play"). Therefor, I can't plug it to the computer on a later time. The only way to get Windows to know this device, is by rescanning the device tree or by restarting the PC. 0x100 means the drivers are installed regardless if I have a device plugged or not and I don't want to install my drivers on a machine which lacks my device. – Cottier

Ok, but if the device is connected before the driver is installed (which is kind of contrary to the normal Windows model), you'll encounter the "add new hardware wizard" in any case (since no other driver in the system will handle it). If you're willing to live with it, you can have a custom action to trigger a rescan of the device tree, before the custom action that decides whether to install the driver. If you can't live with it, you might want to give your device a compatible id that is recognized by a driver that is already installed on the machine (one that will know how to handle it). – Curren

But rescanning brings the "Add new hardware". If the custom action is synchronized, it won't return until the user exit the wizard. If it is asynchronous, then I might check for my hardware id before the rescan ended and the device was found. – Cottier