Windows Update causing problems with Cypress FX2 development board

[Aaron Rossetto]

Hi all,

I would like to warn the Windows Cypress FX2 USB development community about
and bring to Microsoft's attention a very annoying problem that I had this
morning.

I plugged in my Cypress FX2 development board (CY3681) and Windows went
searching for drivers for it, because between today and the last time I used
the board I had uninstalled the USB 2.0 host controller in order to force
renumeration of previously-installed USB devices on my system the next time I
plug them in. (This is something I do from time to time during development
to make sure that my development devices enumerate properly.)

Anyway, Windows found the proper .INF file and installed the correct
driver... then promptly went ahead and installed a DIFFERENT driver, one for
a 'Sperling USB HDTV' device! I assure you I have never installed any USB
HDTV drivers on my system. Ever.

I went looking through the .INF files and found an entry in one of the
oem##.inf files (in my case oem18.inf) there was an entry with the SAME VID
and PID as the development board! It looks like some hardware developer was
building a prototype with the FX2 sans EEPROM and let the development board's
VID and PID slip into the .INF file.

I removed the offending entry from the .INF file, did the aforementioned
uninstall trick on the USB Host Controller, plugged in my development board,
and got the SAME RESULTS. This time, however, the offending entry had been
written to a brand-new .INF file. I tried removing the .INF file altogether
the second time and the same thing happened. Many different combinations
caused the same thing to happen. Whatever I tried to do to force that entry
to be gone was undone.

I had a colleague look at it and he suggested that it might be picking up
the information from Windows Update. So I unplugged my network cable,
uninstalled the USB Host Controller again, and plugged in my FX2 board, and
it worked.

I am not really familiar with what happens with Windows Update behind the
scenes. I would first of all like to know what was happening, if in fact the
.INF file entry was getting picked up from Windows Update, and, if so, if
there's a way to prevent this in the future. (I have auto-updates turned
off, but I know my company pushes periodic updates to my machine.) Secondly,
it seems very bad to me thata vendor is shipping an .INF file with the same
VID and PID as another device from another vendor.

For reference, the entry appeared on my machine in oem18.inf. The first few
lines of the file mention USBHDTV.INF and 'This file contins installation
information for OnAir USB HDTV, An MPEG2 WDM capture driver that requires
hardware'.

Aaron

[M Taha Masood]

i have seen same behvaiour as well recently .
if you look into %windir%\setupapi.log , there should be an entry in it
telling you from what location was this driver installed and what
component installed it ( with the command line invoked )

well the main problem here is that these guys shipped their driver with
the PID VID combo of Cypress that they must have been experimenting
with the test board. ( a slip definitely , they would definitely not
have wanted it this way )
and the other problem is that they managed to get through Windows HCT
and Microsoft's HCT tests for WHQL certification did not cacth this
problem . Hence Microsoft signed this driver and it managed to get upto
Windows Update website from where drivers are also downloaded.
What happends with Windows Update is that the CDM ( Code Download
Manager ) component of Windows Update also is involved during plug n
play installation of drivers . There is what we call "server side"
installation of drivers , what that means
is that if we plug in a device then the PnP manager of windows does not
recognize this device through all of its methods ( not previously
installed , not in the oem* INF cache , not available inbox ) then PnP
component asks CDM to try and see if an updated driver for tihs device
is available on Windows Update website . From wherever in the above
mentioned methods if windows can get a suitable ranked signed driver ,
it SEAMLESSLY installs the driver for it ( without asking you since it
is so kind to you ) . This is what is meant by server side installation
of driver thru PnP subsystem.

The main problem here is just a single problem:
how did this driver manage to slip thru HCT tests onto public windows
update website
i am sure someone from Microsoft HCT and/or windows update team would
like to look into that , and in the meantime would pull this driver out
from Windows Update site.