Microsoft admits that KB 938371 kills USB Devices

Various reports on the Intertubes are reporting that Microsoft has acknowledge that last weeks Vista Update, 938371, has been causing “problems” with USB devices.  The money quote:

“We are aware of concerns that a recent Microsoft update may be causing problems with USB devices. We are investigating the matter, and at this time, do not have any information to share.”

Supposedly this was an update to fix a security hole in Windows Defender.  Read about more people hit by 938371 in MS’s own forums.

This is starting to feel like an endless series of misadventures with 938371.  See Work around for KB938371 disabling HID-compliant input devices , KB 938371 woes continue and the first post, Vista update KB938371 disabled my mouse.

I just want to know when a permanent fix will be available.  Come on Microsoft, there is enough people reporting this problem that you should be able to reach out for more information to help diagnose and fix this problem.

Know your SQL Server version

There are times where you need to know what version of SQL Server is installed.  Usually you want to know which version and which service pack has been applied.  There have been a few isolated cases over the years where we saw bugs go away or significant performance boosts by merely installing the latest service pack.  It’s less of an issue with 2005, but with SQL Server 2000, we wanted to make sure the user installed the latest service packs to block against stuff like the “Slammer” worm.

The following bit of T-SQL will send back the version information in easy to process pieces


SERVERPROPERTY(‘productversion’) AS ProductVersion, SERVERPROPERTY (‘productlevel’) AS ProductLevel, SERVERPROPERTY (‘edition’) AS Edition

For SQL Server 2005, you could get back something like this:

ProductVersion  ProductLevel  Edition
--------------- ------------- ----------------
9.00.2047.00    SP1           Standard Edition

Which indicates the Standard Edition of SQL Server 2005, with Service Pack 1 installed.  You can also get most of that information with



But you would have to parse out the version from a block of text like this:

Microsoft SQL Server 2005 - 9.00.2047.00 (Intel X86)
Apr 14 2006 01:12:25
Copyright (c) 1988-2005 Microsoft Corporation
Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 2)

Using SERVERPROPERTY (2000, 2005 or 2008) is much easier than parsing that block of text.  To determine which version is running based just on the version number, Microsoft has a KB article that lists all of the releases under KB321185.

Work around for KB938371 disabling HID-compliant input devices

After a few days of non-working mice, someone found a work around for KB938371. As I noted here and here, Vista Update 938371 disabled two the three mice I have I on my main home machine. Here’s the work around that actually worked for me:

  • Just go to device manager -> HID-devices -> Unknown Device and search for drivers.
  • When prompted for how to search for driver software, select “Browse my computer for driver software”
  • Enter “C:\windows\winsxs” for the driver location and press the “Next” button.
  • If you get a popup saying “this is an unsigned driver…”, just allow Windows to install the driver.

At this point, Windows should select the appropriate driver and your mouse will start working again.  When I tried this, only had one of the non-working mice plugged in.  When I followed those steps, the mouse started working.  I plugged the other mouse in and Windows enabled it without any prompting.

I went in to Device Manage and both mice were listed as “HID-compliant mouse” under “Mice and other pointing devices”.  Just to be safe, I selected one the mice, right-clicked into “Properties, selected the “Driver” tab on the dialog that opened up.  I clicked the “Driver Details” button and the mouse was using mouclass.sys and mouhid.sys drivers, located in c:\windows\system32\drivers, which is what they were supposed to be using.

This tip was originally posted here and I came across it here.  I’m happy that I have my mouse functionality back, but how did this get past Microsoft’s testing?  I saw too many people reporting this, it’s not an isolated case.  I have a mouse that comes with my Wacom table that wasn’t affected by this snafu, but what about the people who just had regular USB mice?  They were/are pretty much screwed by an update that can’t be uninstalled with running System Restore. 

I still want to know what happened and why 938371 toasted my HID-compliant hardware.  Was there something broken already with my Vista installation and 938371 was just a symptom of the problem, or did 938371 actually break something?

I’m not allowing MS to automatically update my PC anymore.  That requires a certain level of trust that MS is going to push down updates that will be beneficial.  They just blew that trust.  I’ll take the updates, but I’m going to decide if and when they get installed.

I was asked offline why I have three mice.  It’s pretty simple (almost makes sense).  My day to day mouse is a Logitech MX™700.  It’s a cordless mouse that uses rechargeable batteries.  It’s been the best mouse that I have ever used and I continue to use it under Vista even though Logitech never ported the MX700 drivers to Vista.  It has a little dock that charges the batteries.  I almost always forget to put the mouse back in it’s dock and a every few days, the batteries give out.  When that happens, I place it back in it’s dock and use a Dell USB optical mouse while the MX700 is charging.   The third mouse is a digitizer mouse that comes with my Wacom Bamboo Fun tablet.  That mouse works, but only on it’s little pad.  It was OK enough to use while tracking down this problem, but I wouldn’t want it to be my everyday mouse.

Update: 2/22/2010
I repaved this machine with Windows 7 about 6 months ago and replaced the MX700 with a Logitech mouse that is supported under Windows 7.  For anyone that is still having this problem, consider Windows 7.  It’s much nicer than Vista.

KB 938371 woes continue

I still haven’t been able to fix the problem that I reported yesterday.  After blogging about how Vista update KB 938371 disabled the mouse on my PC, I have found other people reporting the same problem.  The mouse shows up in the Device Manage as “unknown device”.  If I try to install a device driver for it, it fails with the error dialog “Found New Hardware – Unknown Device) and displaying the following text:

Windows encountered a problem installing the driver software for your device

Windows found driver software for your device but encountered an error while attempting to install it.

     HID-compliant device

An error occurred during the installation of the device

The driver installation file for this device is missing a necessary entry.  This may because the INF was written for Windows 95 or later.  Contact your hardware vendor.

This occurs with any USB port on my machine and with both of my mice.  I have a Logitech wireless mouse and a basic Dell USB Optical mouse.  I have a mouse with my Wacom tablet that still works.  It has it’s own drivers and MS didn’t touch them.  I even took the Microsoft Optical mouse off my wife’s Vista machine (which is working fine with 938371) and plugged into my machine.  It didn’t work either.

If I do a System Restore and rollback to the point just before 938371 was installed, the mice work.  As soon as I install 938371, I lose the mice. This is really frustrating as 938371 is a prerequisite for SP1.

I’ve been posting this tale on a new message boards and blogs.  I’m not the only person having the problem, but we have yet to identify what we have in common that is triggering this.  My machine is running Vista Home Premium, 32-bit, on an ASUS M2N-SLI Deluxe motherboard. The M2N is NVidia NForce based and I have an AMD Athlon X2 processor in it.  You can read about other peoples symptoms in this MSDN Forum thread,  this message that I posed in the Windows Vista Blog.

Vista update KB938371 disabled my mouse

Windows Update just pushed down an update, KB938371 on to my main home PC, as a prerequisite for Vista Service Pack 1.  After that update was installed and Vista rebooted, I lost all mouse functionality.  The only way I could get mouse functionality back was to run System Restore and restore the OS to the point to just before 938371 was installed.  For me, selecting the recommended restore point was as far back as I needed to go.

I have installed 938371 twice now by itself, each time I lose mouse function.  My machine was custom built for Visa Home Premium, but it uses a pretty standard motherboard, an ASUS M2N-SLI Deluxe, which uses the NVidia NForce chipset.  I have a Logitech MX™700, which uses the Vista input drivers and mouse that comes with the Wacom Bamboo Fun tablet, which has it’s own Vista drivers.  I also have Dell USB mouse which I use when I’m recharging the batteries in the MX700.  None of them worked after 938371 was installed.  I think it would be a fair assumption that other features are broken, but I didn’t bother to check.  The machine was unusable without a working pointing device, I concentrated my efforts on rolling back 938371.

938371 is an non-removable update.  It wont show up in the “Uninstall or change a program” list under “Control Panel\Programs and Features”.  System Restore is the only way that I know to yank it out.  I don’t think I’m only one having this problem.  I reply on this blog as a comment to a non-related post.

Service Pack 1 for Vista is out now and it requires 938371 as a  prerequisite.  Which means I can’t install SP1 without running a mouse killing update.  I’m trying to decide if I can install SP1 and hope for the best.  If it fails, I’m without a pointing device and makes Windows somewhat less than usuable.  I would prefer to resolve 938371 before installing anything else.  The advantage of trying SP1 would be that Microsoft is providing free support for SP1 and this is definitely a SP1 support issue.

This could be the final straw that pushes me back Windows XP.  After using Vista for nearly a year, I’m tempted to repave with XP.  I have another Vista box at home that the family shares.  It’s a Dell and while it has less functionality (my box has RAID 5), it has had any of the weird Vista problems that this machine has had.  I do wonder how many other people have had their mice disabled by this update.  If we can discover what we have in common, we get closer to determining what the root cause is and what fix there may be.

[Updated on 4/17/08]
If this is your first visit to my blog, please read this post for a work around that may work for you.

Fun with CoInitialize

I was tracking down a error in one of the command line apps that I use to save web.config settings over upgrades.  It was a strange error, If I stepped through the code, everything executed correctly, but I would get an access violation when I left a specific method call.  The fun part was that all of the code in that method call executed normally.  The app is written in Delphi 2007 and is Win32 unmanaged code.  The code looked something like this:

function TSaveConfig.UpdateWebConfig(const srcfile, destfile: string): boolean;
fsrcDoc, fDestDoc: IXMLDocument;

result := true;

fsrcDoc := LoadXMLDocument(srcFile);
fDestDoc := LoadXMLDocument(DestFile);

UpdateNode(fsrcDoc, fDestDoc, 'configuration\system.web\httpRuntime', 'executionTimeout', '', '');
UpdateNode(fsrcDoc, fDestDoc, 'configuration\system.web\sessionState', 'timeout', '', '');

if fDestdoc.Modified then begin


Not much to it.  My Spidey sense started tingling at the calls to CoInitialize/CoUninitialize.  CoInitialize is needed to initialize the COM library on the current thread.  And COM is needed because I am using MS XML COM objects to work with the web.config files.  I was initializing COM, using COM, then uninitializing COM.  The problem was that I was using interfaces to the COM objects and Delphi is managing the lifetime of interfaces.  At the end of the method call, those objects go out of scope and Delphi calls their cleanup code.  In my case this happens after the the call to CoUninitialize.  My IXMLDocument interfaces were being garbage collected by the Delphi runtime and they were referencing a COM library that had been already closed.

In this case, the fix was easy.  I just moved the calls to CoInitialize/CoUninitialize to the code that calls UpdateWebConfig.  Once I did that, my odd little access violation was fixed.  That’s one of those bugs that seems obvious after you fix it.  What clued me in to what was going on was a post by Chris Bensen that explained it all.  Thanks Chris!

Wireshark reaches 1.0

Image:Wireshark Icon.svg

It looks like Wireshark has made it to version 1.0.  Wireshark has been my favorite tool for diagnosing TCP problems in the socket code that I have worked on.  I’ve been using it since it used to be called Ethereal®.  Wireshark is a free an open source packet sniffer.  If you are trying to see what is coming over the wire, you want this tool whether you are running Windows, Unix, Linux. or Mac.

Saving application settings over installs

We have been using Windows Installer (WI) based setups for all of our newer applications.  I used to use Wise, but I have migrated our installers to InstallAware.  Why I made that change will be another blog post, but needless to say I had very good reasons to make the switch.  When we release a new version or upgrade for one of our applications, we do full installs.  We don’t do patches.

WI technology supports the distribution of patch files.  If you are only updating one or two files, the patch file will only contain what has changed, greatly reducing the size of the installable bits needed to be distributed.  I did use patch files when I first started doing WI based setups, but I abandoned the practice early on.  Patches were hard to automate as part of the build process and they had to account for cumulative changes.  The other drawback was that they could add files, but not remove them.  Another drawback was that it yet another file extension, .msp instead of .msi, to explain to the users.

I decide to have the installers upgrade in place. When a new version was installed over a previous version, the previous version would be silently uninstalled, then the new version would be installed.  This basically gives you a clean slate per install, which is great because you only install the files that are needed and the dependant objects will be up to date.  The bad part is that the user settings will be removed as part of the previous versions uninstall.

What I needed to do was to persist the user defined settings.  Consider a web application, if all of the settings are in the web.config file, then you just need to keep that web.config file around.  The simple solution is to tell the installer not to delete that file on the uninstall.  There’s a couple of problems with that approach.  The first one is that the new install is a full install and the user gets to pick the destination.  They may want to put the web application in a different folder or drive and I didn’t want to take that option away just to make my job easier.

The other drawback was far more serious.  I could keep the web.config around between installs, but what if the new version added content to the web.config file?  You don’t want to save the old settings and lose the new settings.  That could cause hard to diagnose bad things to happen.   What was needed was the ability to merge selected content from the old web.confile and into the new web.config.  You can do many things with WI technology and InstallAware provides powerful functions, but this is a task best left outside the installer code.

I decided to write a Win32 command line app that would be able to save the old web.config and merge selected values from that file into the new one.  The installer would be include that file and be able to run it without permanently installing it.  I could have used C# with .NET (and I even had most of the code already written), but I didn’t want to deal with .NET security issues or make the .NET Framework a prerequisite for non .NET based installs.  Delphi 2007 provided everything that I needed.

From the installer, I call this app just before the previous version is uninstalled with a command line parameter to designate which app is being installed.  It will locate the current web.config file for that application and copy it to a folder in the user’s temp directory.  I always have our installers write the location of the install folder to the registry, it makes tasks like this much simpler.  After the new version has been installed, I run the app one more time, with a “-restore” command line parameter.  It locates the cached copy of the old web.config and the new web.config and updates the new web.config file with the settings that need to be persisted across installs.  Once that task is complete, it removes that temporary folder.

The app knows what settings to use from rules encoded into the source code.  I could have used a file to store a list of settings to persist, but that would have made the installer a bit more complicated.  It’s fairly easy to run an app from the installer without actually installing it, but if you want it to have it read an external file, then you need to make sure that file is in a place where it can be read from.  That comes one more part of the installer to be tested and the mechanism for handling that would be specific to installer tool used.  By making the app contain the rules it needed to follow, running it from the installer becomes a trivial task.

The other advantage of having a separate app to handle to the saving of the user settings is that the code is much easier to test and debug.   It becomes a modular piece of the install and can even be unit tested in a scriptable manner.  This type of code can be easily adapted to the types of application.  I use a similar type of program to persist settings and current run start for some of our Win32 service applications.