I've been tasked with creating an installation program that handles installing some drivers in anticipation that a certain piece of hardware will be connected to the computer. The objective is to automate as much of the driver installation and subsequent driver selection as possible, with the ideal goal being that the user doesn't have to do anything other than run the program and then connect the device.
Should be pretty simple. But given that I'm not versed in the Windows Installer technology, and InstallShield is as foreign as Baklava to me... Let's just say that I'm learning a lot. The initial cut of drivers (from a 3rd party, also responsible for the device) wasn't signed so there wasn't much I could do on XP / Server 2003 to make the process totally automated. But I got things as streamlined as possible. Then, out of the blue, and kind of in a fit of irony, we "magically" got signed drivers. The changes to the installation procedures were moderate (new files, new file names, fewer drivers, etc). But the recommended installation steps (provided by the 3rd party) were more tedious. After much trial and error, I've got things to the point again that there is nothing that the user needs to do other than run the program and plug the device in. The only problem is that the results are inconsistent - sometimes the driver appears to be associated with the device successfully, sometimes Windows says that I HAVE to reboot to get the driver / device working... and sometimes Windows says that there _may_ be a problem with the device. So it could be goofy drivers, or it could be a faulty device, or it could be...
All this led me down a path where I needed to know far more about the driver installation process than I suspected I would have to. But I found a great document at Microsoft's web site - "Troubleshooting Device Installation with the SetupAPI Log File". It's chock full of vitamins and information. I didn't have time to digest the full document, but I immediately noted the section "Appendix A: Setting the SetupAPI Logging Level". I skimmed and found that I could set [HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\LogLevel] to 0x2000FFFF. This will specify "that everything should be logged and that the log file should not be flushed to disk after each message is written" (to %windir%\setupapi.log). So I set the registry value and ran the installation program, and plugged the device in. Windows detected the device, found the driver, did it's magic... and reported that Windows needed to be rebooted (desipte the fact that I could begin using the device immediately). I opened setupapi.log and indeed all kinds of stuff was logged, including an entry toward the end that indicated the system would need to be rebooted because of an "unknown reason". The following excerpt is from the setupapi.log:
@ 15:40:40.775 #V282 Add Service: Modified existing service "SERVICENAME".
@ 15:40:40.785 #T214 Install Device: Writing driver descriptive registry settings.
@ 15:40:40.785 #T216 Install Device: Restarting device.
@ 15:40:40.955 #T217 Install Device: Restarting device completed.
@ 15:40:40.985 #W165 Device "USB\VID_XXXX&PID_XXXX\XXXXXXXXXXXXX" required reboot: Device not started (unknown reason).
@ 15:40:40.985 #T222 Install Device: Calling 'RUNONCE'/'GRPCONV' items.
@ 15:40:40.995 #I121 Device install of "USB\VID_XXXX&PID_XXXX\XXXXXXXXXXXXX" finished successfully.
@ 15:40:40.995 #T201 Install Device: End.
@ 15:40:40.995 #V156 Completed default installer.
@ 15:40:40.995 #V166 Device install function: DIF_NEWDEVICEWIZARD_FINISHINSTALL.
@ 15:40:41.005 #V155 Executing default installer.
@ 15:40:41.005 #V156 Completed default installer.
So either the driver's goofy or the device has issues. We don't really have control over either of them (3rd party), so there's not much that can be done in this particular case. But at least it seems I'm able to accomplish the ideal scenario if the device and the drivers behave properly.
Another interesting tidbit from the "Troubleshooting Device Installation with the SetupAPI Log File" document, again relating the the "LogLevel" registry setting:
Do not use 0xFFFFFFFF. This level turns on all logging, which results in an unreadable log file and some very slow installations.