Hi Archean
Your situation is another good mystery in the “wonderful-world-of-windows”. I can offer some info and theory but, unfortunately, not a good, solid explanation.
First, a little background on Plug and Play (PnP) devices, drivers, the Windows install process and log files
You might also skim through another post I wrote awhile back. It needs updating ( when I can get to it) but I provide some more details below
==> See [post=755153]Plug and Play Overview: How Windows Finds Drivers for USB Devices[/post]
The firmware on every PnP device is programmed by the manufacturer to include the device's PnP ID strings. These strings include things like the device's
Hardware IDs and
Compatible IDs. The PnP IDs are a fundamental part of how PnP works
When you first connect a PnP device there’s a PnP handshake
Windows <----------------------------------------------->
PnP Device
- Device is plugged/unplugged from a data bus (e.g. PCI or USB)
- Windows detects the electrical change on the bus
> For USB, the change is detected and propagated by each USB hub
- Windows figures out what devices arrived or were just unplugged by broadcasting a “who’s there” on the bus and pinging devices for their PnP ID strings
- Windows uses a DRIVERPATH variable in the registry to search throughout your disk and look at every driver on your disk
- It uses both the device Hardware IDs and Compatible IDs to match the device to possible drivers
- During this search process, Windows builds a list of all possible driver "candidates"
==> Windows often finds multiple different driver choices on your disk given a device's PnP IDs. They all become "candidates"
- After Windows finishes searching the disk and building its candidate list* (see footnote below), Windows goes through the list to numerically rank each candidate using a number of different criteria
- Windows selects and installs the driver it ranks as "best of bunch"
*Note: Windows' search for driver candidates might also include drivers it found by searching the internet using Windows Update
It's important to note: Steps 1 – 4 do
not require a driver. In fact, they're specifically designed to work
without a driver as the PnP ID strings are what allow Windows to find the driver in the first place!
Also note, PnP ID strings convey a minimal amount of info to Windows. Windows doesn’t really understand what the device is until it can locate a suitable driver. It’s the data
contained within the driver that identifies the device, what it can do and how Windows can control and use its functionality. (That;s why devices without drivers typically appear in Device Manager listed under
Other devices as Windows doesn't yet know what it is. So, it doesn't know how to categorize it)
All of this leading to what i can only guess might cause your problem. The problem might be
- Electrical/Firmware. Whether the device is plugged/unplugged during the install is affecting the handshake (which, of course, is much more complicated then my simple overview) OR
- Software. It might be possible that for some reason whether the device is plugged/unplugged during the OS install is affecting how Windows creates its list of candidates so it's actually selecting two different drivers for the two different cases. And one of the two drivers is problematic.
Log files
There may or may not be some footprints left behind. In either case, it can be helpful to know that for Vista and Windows 7 in C:\Windows you'll find Windows log files
>
setuperr.log: Logs errors that occur during the OS installation process
>
setupact.log: Logs (i.e. traces) Device Manager (install/uninstall) events. There are registry values which control how detailed it gets during the trace
For XP: there's a
setupapi.log file to trace Device Manager events
