USB port not working for mouse

[Jo-Anne]

My four-year-old Dell Precision M4300 laptop running WinXP has only three
USB ports. I use the one in back for the printer, which leaves two on the
right side--one above the other.

My Contour three-button mouse works fine in the top port but has never been
recognized in the bottom one. Other devices--external hard drives and flash
drives--work normally in the bottom one. I'd prefer to have the mouse
plugged into the bottom port because it's difficult to plug in the other
devices under the mouse connection.

Any suggestions for troubleshooting and fixing the problem?

Thank you!

Jo-Anne

 

[Paul]

My four-year-old Dell Precision M4300 laptop running WinXP has only three
USB ports. I use the one in back for the printer, which leaves two on the
right side--one above the other.

My Contour three-button mouse works fine in the top port but has never been
recognized in the bottom one. Other devices--external hard drives and flash
drives--work normally in the bottom one. I'd prefer to have the mouse
plugged into the bottom port because it's difficult to plug in the other
devices under the mouse connection.

Any suggestions for troubleshooting and fixing the problem?

Thank you!

Jo-Anne

If you go Start : Run : devmgmt.msc and then select View : Show Hidden Devices,
does it show up in there ?

With the mouse plugged into the working port, set up that view, then try
moving the mouse, and see if something shows up in Non Plug and Play Drivers
(hidden devices). If so, you could try deleting the item from the Hidden
Devices. The entry might mention "mouse" or "HID" or the like. HID
stands for Human Interface Device.

If you had a copy of UVCView or USBView, you could watch what happens
when the device is plugged into the non-working port, but because
you've verified the port with a USB hard drive, I don't see a lot
of value in such a move right now. This is probably something
recorded in the registry, which is not right, rather than something
being physically wrong with the mouse.

You could check the very end of the setupapi.log file, for new
entries recording what happened when you plugged the mouse in.
The entries in the file should be date-stamped, so you can
see what your attempt today did.

The Microsoft utility "devcon" can be used to work on this. But it
has roughly the same functions, as working on Device Manager directly.
If you run out of things to try, you can work with that from the
command line. Part of the fun of using this, is learning how to
use it (like, how do you figure out the "instance name"). But if the
GUI way doesn't work, this is another way to get the job done. Note
that there is no 64 bit version (x86-64) on this page, and the
one usable version is 32 bit. The IA64 is for Itanium servers.
To get a 64 bit version (like, to run on Windows 7 64 bit),
you have to do a 700MB download and pull the file off the
resultant download. Let's hope it doesn't come to that...
You likely just need the 32 bit version.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q311272

devcon driverfiles usb*
devcon find usb*
devcon remove <the_specific_instance_name>

Maybe you can get some instance names from the "find" option. The
problem I had, was when testing a specific instance (my mouse),
some of the characters in the instance name, need to be "escaped",
and I couldn't get the command to accept just one instance.
When I did something like this...

devcon status <the_specific_instance_name>

the <the_specific_instance_name> part was getting mis-interpreted
because it had "&" characters in the name. The name of my mouse is:

USB\VID_046D&PID_C01A\5&39258CB2&0&2 : USB Human Interface Device

If you look here, as a reference, you can see 046D C01A is a Logitech mouse.

http://www.linux-usb.org/usb.ids

046d Logitech, Inc.
c01a M-BQ85 Optical Wheel Mouse

HTH,
Paul

 

[Jo-Anne]

If you go Start : Run : devmgmt.msc and then select View : Show Hidden
Devices,
does it show up in there ?

With the mouse plugged into the working port, set up that view, then try
moving the mouse, and see if something shows up in Non Plug and Play
Drivers
(hidden devices). If so, you could try deleting the item from the Hidden
Devices. The entry might mention "mouse" or "HID" or the like. HID
stands for Human Interface Device.

If you had a copy of UVCView or USBView, you could watch what happens
when the device is plugged into the non-working port, but because
you've verified the port with a USB hard drive, I don't see a lot
of value in such a move right now. This is probably something
recorded in the registry, which is not right, rather than something
being physically wrong with the mouse.

You could check the very end of the setupapi.log file, for new
entries recording what happened when you plugged the mouse in.
The entries in the file should be date-stamped, so you can
see what your attempt today did.

The Microsoft utility "devcon" can be used to work on this. But it
has roughly the same functions, as working on Device Manager directly.
If you run out of things to try, you can work with that from the
command line. Part of the fun of using this, is learning how to
use it (like, how do you figure out the "instance name"). But if the
GUI way doesn't work, this is another way to get the job done. Note
that there is no 64 bit version (x86-64) on this page, and the
one usable version is 32 bit. The IA64 is for Itanium servers.
To get a 64 bit version (like, to run on Windows 7 64 bit),
you have to do a 700MB download and pull the file off the
resultant download. Let's hope it doesn't come to that...
You likely just need the 32 bit version.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q311272

devcon driverfiles usb*
devcon find usb*
devcon remove <the_specific_instance_name>

Maybe you can get some instance names from the "find" option. The
problem I had, was when testing a specific instance (my mouse),
some of the characters in the instance name, need to be "escaped",
and I couldn't get the command to accept just one instance.
When I did something like this...

devcon status <the_specific_instance_name>

the <the_specific_instance_name> part was getting mis-interpreted
because it had "&" characters in the name. The name of my mouse is:

USB\VID_046D&PID_C01A\5&39258CB2&0&2 : USB Human Interface
Device

If you look here, as a reference, you can see 046D C01A is a Logitech
mouse.

http://www.linux-usb.org/usb.ids

046d Logitech, Inc.
c01a M-BQ85 Optical Wheel Mouse

HTH,
Paul

Thank you, Paul! Here's what I've found so far:

* In devmgmt.msc Hidden Devices, the mouse shows up--but so does my Dell
Touchpad.

* I moved the mouse from the working port to the nonworking one, and nothing
related to a mouse or a HID showed up in Non Plug and Play Drivers.

* When I moved the mouse to the nonworking port, I first got the error
message "USB device not recognized..." and the mouse wouldn't work at all. I
unplugged it, waited a short time, and plugged it into the same port again.
This time I heard the beep indicating that something has been plugged in and
I got a new message: Found new hardware--problem occurred, might not work.
(I can't remember the exact wording.) When that happened, the mouse started
working--but only as a generic mouse, not my Contour three-button mouse. I
then put the mouse back in its top port so I could use it.

* I checked the end of the setupapi.log file and saw the following (I hope
it's OK to paste it here):
[2012/04/27 23:17:08 1044.3 Driver Install]
#-019 Searching for hardware ID(s): usb\unknown
#-018 Searching for compatible ID(s): usb\unknown
#-198 Command line processed: C:\WINDOWS\system32\services.exe
#I393 Modified INF cache "C:\WINDOWS\inf\INFCACHE.1".
#I022 Found "USB\UNKNOWN" in C:\WINDOWS\inf\usb.inf; Device: "Unknown
Device"; Driver: "Unknown Device"; Provider: "Microsoft"; Mfg: "(Standard
USB Host Controller)"; Section name: "BADDEVICE.Dev".
#I023 Actual install section: [BADDEVICE.Dev.NT]. Rank: 0x00000000.
Effective driver date: 07/01/2001.
#-166 Device install function: DIF_SELECTBESTCOMPATDRV.
#I063 Selected driver installs from section [BADDEVICE.Dev] in
"c:\windows\inf\usb.inf".
#I320 Class GUID of device remains: {36FC9E60-C465-11CF-8056-444553540000}.
#I060 Set selected driver.
#I058 Selected best compatible driver.
#-166 Device install function: DIF_INSTALLDEVICEFILES.
#I124 Doing copy-only install of "USB\VID_0000&PID_0000\5&260C57CF&0&2".
#-166 Device install function: DIF_REGISTER_COINSTALLERS.
#I056 Coinstallers registered.
#-166 Device install function: DIF_INSTALLINTERFACES.
#-011 Installing section [BADDEVICE.Dev.NT.Interfaces] from
"c:\windows\inf\usb.inf".
#I054 Interfaces installed.
#-166 Device install function: DIF_INSTALLDEVICE.
#I123 Doing full install of "USB\VID_0000&PID_0000\5&260C57CF&0&2".
#I121 Device install of "USB\VID_0000&PID_0000\5&260C57CF&0&2" finished
successfully.

Any idea of what I should do next?

Thank you again!

Jo-Anne

 

[Paul]

If you go Start : Run : devmgmt.msc and then select View : Show Hidden
Devices,
does it show up in there ?

With the mouse plugged into the working port, set up that view, then try
moving the mouse, and see if something shows up in Non Plug and Play
Drivers
(hidden devices). If so, you could try deleting the item from the Hidden
Devices. The entry might mention "mouse" or "HID" or the like. HID
stands for Human Interface Device.

If you had a copy of UVCView or USBView, you could watch what happens
when the device is plugged into the non-working port, but because
you've verified the port with a USB hard drive, I don't see a lot
of value in such a move right now. This is probably something
recorded in the registry, which is not right, rather than something
being physically wrong with the mouse.

You could check the very end of the setupapi.log file, for new
entries recording what happened when you plugged the mouse in.
The entries in the file should be date-stamped, so you can
see what your attempt today did.

The Microsoft utility "devcon" can be used to work on this. But it
has roughly the same functions, as working on Device Manager directly.
If you run out of things to try, you can work with that from the
command line. Part of the fun of using this, is learning how to
use it (like, how do you figure out the "instance name"). But if the
GUI way doesn't work, this is another way to get the job done. Note
that there is no 64 bit version (x86-64) on this page, and the
one usable version is 32 bit. The IA64 is for Itanium servers.
To get a 64 bit version (like, to run on Windows 7 64 bit),
you have to do a 700MB download and pull the file off the
resultant download. Let's hope it doesn't come to that...
You likely just need the 32 bit version.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q311272

devcon driverfiles usb*
devcon find usb*
devcon remove <the_specific_instance_name>

Maybe you can get some instance names from the "find" option. The
problem I had, was when testing a specific instance (my mouse),
some of the characters in the instance name, need to be "escaped",
and I couldn't get the command to accept just one instance.
When I did something like this...

devcon status <the_specific_instance_name>

the <the_specific_instance_name> part was getting mis-interpreted
because it had "&" characters in the name. The name of my mouse is:

USB\VID_046D&PID_C01A\5&39258CB2&0&2 : USB Human Interface
Device

If you look here, as a reference, you can see 046D C01A is a Logitech
mouse.

http://www.linux-usb.org/usb.ids

046d Logitech, Inc.
c01a M-BQ85 Optical Wheel Mouse

HTH,
Paul

Thank you, Paul! Here's what I've found so far:

* In devmgmt.msc Hidden Devices, the mouse shows up--but so does my Dell
Touchpad.

* I moved the mouse from the working port to the nonworking one, and nothing
related to a mouse or a HID showed up in Non Plug and Play Drivers.

* When I moved the mouse to the nonworking port, I first got the error
message "USB device not recognized..." and the mouse wouldn't work at all. I
unplugged it, waited a short time, and plugged it into the same port again.
This time I heard the beep indicating that something has been plugged in and
I got a new message: Found new hardware--problem occurred, might not work.
(I can't remember the exact wording.) When that happened, the mouse started
working--but only as a generic mouse, not my Contour three-button mouse. I
then put the mouse back in its top port so I could use it.

* I checked the end of the setupapi.log file and saw the following (I hope
it's OK to paste it here):
[2012/04/27 23:17:08 1044.3 Driver Install]
#-019 Searching for hardware ID(s): usb\unknown
#-018 Searching for compatible ID(s): usb\unknown
#-198 Command line processed: C:\WINDOWS\system32\services.exe
#I393 Modified INF cache "C:\WINDOWS\inf\INFCACHE.1".
#I022 Found "USB\UNKNOWN" in C:\WINDOWS\inf\usb.inf; Device: "Unknown
Device"; Driver: "Unknown Device"; Provider: "Microsoft"; Mfg: "(Standard
USB Host Controller)"; Section name: "BADDEVICE.Dev".
#I023 Actual install section: [BADDEVICE.Dev.NT]. Rank: 0x00000000.
Effective driver date: 07/01/2001.
#-166 Device install function: DIF_SELECTBESTCOMPATDRV.
#I063 Selected driver installs from section [BADDEVICE.Dev] in
"c:\windows\inf\usb.inf".
#I320 Class GUID of device remains: {36FC9E60-C465-11CF-8056-444553540000}.
#I060 Set selected driver.
#I058 Selected best compatible driver.
#-166 Device install function: DIF_INSTALLDEVICEFILES.
#I124 Doing copy-only install of "USB\VID_0000&PID_0000\5&260C57CF&0&2".
#-166 Device install function: DIF_REGISTER_COINSTALLERS.
#I056 Coinstallers registered.
#-166 Device install function: DIF_INSTALLINTERFACES.
#-011 Installing section [BADDEVICE.Dev.NT.Interfaces] from
"c:\windows\inf\usb.inf".
#I054 Interfaces installed.
#-166 Device install function: DIF_INSTALLDEVICE.
#I123 Doing full install of "USB\VID_0000&PID_0000\5&260C57CF&0&2".
#I121 Device install of "USB\VID_0000&PID_0000\5&260C57CF&0&2" finished
successfully.

Any idea of what I should do next?

Thank you again!

Jo-Anne

That's suggestive the problem is physical.

Yet, you say you've had a USB hard drive on that port, and it worked.

I would re-verify the USB hard drive works on that port.

For example, someone here had a VID/PID all zeros, and claims it
was a bad connection. I reviewed a number of other hits for this
search, and nobody managed to fix it!

http://social.technet.microsoft.com...e/thread/bbf4b69d-2bea-4860-9dab-3d27d3d223c4

I don't think that's the whole story, but I'm not finding any "solutions"
for this problem. I don't think it is always a bad connection or a power
problem. It's got to be something else. The thing is, the install shouldn't
even start, if the OS can't read the thing.

Based on your error, the search term I was using is:

copy-only install of USB\VID_0000&PID_0000

The following is some standard boilerplate, for getting a copy of
USBView or UVCView. Such a program, allows viewing the config information
the USB device reports when probed. Now, in your case, we know the
VID and PID are reporting as zeros, and it's possible no endpoints
were formed to the USB device (communications path to the mouse failed).
So there might not be much to see with UVCView.

What we'd be looking for, by using UVCView, is whether
the sneaky mouse "makes a later appearance" after the bad_device driver
installation happens - implying a timing problem of some sort, like
the mouse is connected, disconnected, is connected again, fouling up
the driver installation. Using this tool, isn't a guarantee it can be
fixed, merely a diagnostic that may be able to say "yup, eventually
it appeared" or "nope, it's still dead".

UVCView is a Microsoft program, provided as a programming example.
At one time, it was available for easy download from the Microsoft site.
Then, Microsoft removed it from their web page. I started referring people
to copies stored on web.archive.org, and the bastards at Microsoft
had those removed as well (and likely, because I'd made public references
to the availability of the file, no other reason). In any case, these
are ways to get UVCView today. I don't know if Franc still offers his
copy or not.

***************** Sources of UVCVIEW ************************

This is my standard blurb for the older version of UVCView.

*******
ftp://ftp.efo.ru/pub/ftdichip/Utilities/UVCView.x86.exe
http://www.users.on.net/~fzabkar/USB_IDs/UVCView.x86.exe

File size is 167,232 bytes.
MD5sum is 93244d84d79314898e62d21cecc4ca5e

(You check the MD5sum to see if the copy is unadulterated. MD5sum has been
broken from a security standpoint, so it isn't an absolute "proof of purchase".
You can use the Microsoft program "fciv" to check the MD5sum value, if you don't
already have a copy. You can get fciv here. It's a command line utility.

http://www.microsoft.com/en-us/download/details.aspx?id=11533

)

This is a picture of what the UVCView info looks like. Notice the
idVendor and idProduct are non-zero values.

http://www.die.de/blog/content/binary/usbview.png

Some information on the parameters seen in UVCView.

http://www.beyondlogic.org/usbnutshell/usb5.htm
*******

There is a later version of UVCView, but I doubt it adds anything
to the capabilities. UVCView, is just USBView program with UVC Class
readout added to the analysis of the config info. (UVC is for web cams.)

This is my recipe for the latest version I know of.

*******
Download a copy of Windows Device Kit. Yes, I hate telling people to do this!

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=11800

GRMWDK_EN_7600_1.ISO 649,877,504 bytes

You can use the 7ZIP program, to extract a file from within the downloaded
ISO, without the hassle of installing it. (I don't like filling my computer
with garbage, which is why I do stuff like this instead. The UVCView program
doesn't need to be installed as such. It's standalone, and uses no registry
entries that I'm aware of.)

Using 7ZIP, open the ISO, then navigate to "WDK" and find

avstreamtools_x86fre_cab001.cab

Click on the cab, do an "Open Inside", then select

_UVCview.exe_00006

then extract. Then rename the extracted file to

UVCView2.exe

The file should be 133,632 bytes and have MD5SUM = 213f6e89cc4ab4e7e9e3e2ad394b83cb

We trust Microsoft, and checking the MD5SUM in this case, is more curiosity
than anything else.

The interface works the same way as the other versions.
*******

The device being analyzed, should be connected directly to
a computer USB port. It doesn't help if there is a hub in
the way. You might not "see" the device at all with UVCView
if you did that. Sometimes, a computer uses an "internal hub
chip", and then the device will not appear, and there is nothing
we can do (short of editing the source code to UVCView and
recompiling it etc.).

***************** End of UVCVIEW boilerplate ********************

If UVCView shows a valid device appearing on the bad USB port,
you could try going to Device Manager, and "scan for new hardware".
But I expect that's not going to work, because the "bad.device"
driver installation has "plugged the hole" and the OS thinks it
is already using the "best driver". Still, this is the only
option I can think of.

I doubt removing the entire USB stack would help. All USB devices,
should be rediscovered if you do this. It's just a lot of work,
with no certainty things will be any better later.

http://www.usbman.com/Guides/Cleanup Device Manager Safe Mode.htm

"WinXP and 2000 - Removing USB devices in Safe Mode will force the OS
to refresh the USB driver stack and may cause a shift in IRQ assignment."

Note the "warning" on that page, about what happens to USB keyboard and
mouse, and losing control of the system. In your case, with the laptop,
there really aren't any temporary hardware workarounds, to avoid losing
control of the system. And I'm not convinced at this point, that the
USB\VID_0000&PID_0000 thing is happening, because of something in the
registry. It doesn't look likely at this point. Maybe it has something
to do, with some other thing like your trackpad, sharing the same wiring
as that USB port (i.e. an internal hub chip).

A scripted way of doing this, is offered on this page. RenewUSB.bat
This does the equivalent, of what the usbman.com page is suggesting.

http://www.robvanderwoude.com/devcon.php

The renewusb.bat file, has commands of the form:

DEVCON FindAll =USB
DEVCON Remove
DEVCON ReScan

After the "DEVCON Remove" stage, you'd have no working keyboard and mouse.
But, since the DEVCON ReScan line comes right after that, you sit back
and relax, as the entire USB stack is "rediscovered" again. So Rob's script
may avoid the problem the USBman.com site warns about. It's because the
script has the logic, to repair the damage caused by the "Remove".

If you have a backup of C:, you have nothing to worry about Seriously,
if I simply had to try that, I'd do a backup of C: (using software that
boots on its own when WinXP is broken), then try running renewusb.bat
with a copy of devcon.exe in the same directory.

When you download .bat files off the net, you can review them first, by
changing the file extension. The first time I downloaded renewusb.zip,
I extracted renewusb.bat and changed the extension on the file, to
renewusb.bat.txt, so I could open the file with Wordpad or Notepad.
Take a few moments, to review the code and get a general understanding
of how it works. Sometimes, there are developer notes inside the bat
file, warning about certain things. Once you're happy the .bat file
is safe looking, you can change it back to renewusb.bat again,
before running it. I try to run stuff like that from a Command Prompt
window, so I can review the output while it runs.

Have fun,
Paul

 

[Char Jackson]

When you download .bat files off the net, you can review them first, by
changing the file extension.

I think you meant to say you can review them by opening them in a text
editor, such as Notepad. No need to change the extension, even
temporarily. Right clicking should provide an 'Edit' context menu.

The first time I downloaded renewusb.zip,
I extracted renewusb.bat and changed the extension on the file, to
renewusb.bat.txt, so I could open the file with Wordpad or Notepad.

As above, it's not necessary to change the extension.

Take a few moments, to review the code and get a general understanding
of how it works. Sometimes, there are developer notes inside the bat
file, warning about certain things. Once you're happy the .bat file
is safe looking, you can change it back to renewusb.bat again,
before running it. I try to run stuff like that from a Command Prompt
window, so I can review the output while it runs.

I agree with running them from a command prompt so that any output can
be reviewed.

 

[Jo-Anne]

Jo-Anne wrote:
My four-year-old Dell Precision M4300 laptop running WinXP has only
three
USB ports. I use the one in back for the printer, which leaves two on
the
right side--one above the other.

My Contour three-button mouse works fine in the top port but has never
been
recognized in the bottom one. Other devices--external hard drives and
flash
drives--work normally in the bottom one. I'd prefer to have the mouse
plugged into the bottom port because it's difficult to plug in the
other
devices under the mouse connection.

Any suggestions for troubleshooting and fixing the problem?

Thank you!

Jo-Anne
If you go Start : Run : devmgmt.msc and then select View : Show Hidden
Devices,
does it show up in there ?

With the mouse plugged into the working port, set up that view, then try
moving the mouse, and see if something shows up in Non Plug and Play
Drivers
(hidden devices). If so, you could try deleting the item from the Hidden
Devices. The entry might mention "mouse" or "HID" or the like. HID
stands for Human Interface Device.

If you had a copy of UVCView or USBView, you could watch what happens
when the device is plugged into the non-working port, but because
you've verified the port with a USB hard drive, I don't see a lot
of value in such a move right now. This is probably something
recorded in the registry, which is not right, rather than something
being physically wrong with the mouse.

You could check the very end of the setupapi.log file, for new
entries recording what happened when you plugged the mouse in.
The entries in the file should be date-stamped, so you can
see what your attempt today did.

The Microsoft utility "devcon" can be used to work on this. But it
has roughly the same functions, as working on Device Manager directly.
If you run out of things to try, you can work with that from the
command line. Part of the fun of using this, is learning how to
use it (like, how do you figure out the "instance name"). But if the
GUI way doesn't work, this is another way to get the job done. Note
that there is no 64 bit version (x86-64) on this page, and the
one usable version is 32 bit. The IA64 is for Itanium servers.
To get a 64 bit version (like, to run on Windows 7 64 bit),
you have to do a 700MB download and pull the file off the
resultant download. Let's hope it doesn't come to that...
You likely just need the 32 bit version.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q311272

devcon driverfiles usb*
devcon find usb*
devcon remove <the_specific_instance_name>

Maybe you can get some instance names from the "find" option. The
problem I had, was when testing a specific instance (my mouse),
some of the characters in the instance name, need to be "escaped",
and I couldn't get the command to accept just one instance.
When I did something like this...

devcon status <the_specific_instance_name>

the <the_specific_instance_name> part was getting mis-interpreted
because it had "&" characters in the name. The name of my mouse is:

USB\VID_046D&PID_C01A\5&39258CB2&0&2 : USB Human Interface
Device

If you look here, as a reference, you can see 046D C01A is a Logitech
mouse.

http://www.linux-usb.org/usb.ids

046d Logitech, Inc.
c01a M-BQ85 Optical Wheel Mouse

HTH,
Paul

Thank you, Paul! Here's what I've found so far:

* In devmgmt.msc Hidden Devices, the mouse shows up--but so does my Dell
Touchpad.

* I moved the mouse from the working port to the nonworking one, and
nothing
related to a mouse or a HID showed up in Non Plug and Play Drivers.

* When I moved the mouse to the nonworking port, I first got the error
message "USB device not recognized..." and the mouse wouldn't work at
all. I
unplugged it, waited a short time, and plugged it into the same port
again.
This time I heard the beep indicating that something has been plugged in
and
I got a new message: Found new hardware--problem occurred, might not
work.
(I can't remember the exact wording.) When that happened, the mouse
started
working--but only as a generic mouse, not my Contour three-button mouse.
I
then put the mouse back in its top port so I could use it.

* I checked the end of the setupapi.log file and saw the following (I
hope
it's OK to paste it here):
[2012/04/27 23:17:08 1044.3 Driver Install]
#-019 Searching for hardware ID(s): usb\unknown
#-018 Searching for compatible ID(s): usb\unknown
#-198 Command line processed: C:\WINDOWS\system32\services.exe
#I393 Modified INF cache "C:\WINDOWS\inf\INFCACHE.1".
#I022 Found "USB\UNKNOWN" in C:\WINDOWS\inf\usb.inf; Device: "Unknown
Device"; Driver: "Unknown Device"; Provider: "Microsoft"; Mfg: "(Standard
USB Host Controller)"; Section name: "BADDEVICE.Dev".
#I023 Actual install section: [BADDEVICE.Dev.NT]. Rank: 0x00000000.
Effective driver date: 07/01/2001.
#-166 Device install function: DIF_SELECTBESTCOMPATDRV.
#I063 Selected driver installs from section [BADDEVICE.Dev] in
"c:\windows\inf\usb.inf".
#I320 Class GUID of device remains:
{36FC9E60-C465-11CF-8056-444553540000}.
#I060 Set selected driver.
#I058 Selected best compatible driver.
#-166 Device install function: DIF_INSTALLDEVICEFILES.
#I124 Doing copy-only install of "USB\VID_0000&PID_0000\5&260C57CF&0&2".
#-166 Device install function: DIF_REGISTER_COINSTALLERS.
#I056 Coinstallers registered.
#-166 Device install function: DIF_INSTALLINTERFACES.
#-011 Installing section [BADDEVICE.Dev.NT.Interfaces] from
"c:\windows\inf\usb.inf".
#I054 Interfaces installed.
#-166 Device install function: DIF_INSTALLDEVICE.
#I123 Doing full install of "USB\VID_0000&PID_0000\5&260C57CF&0&2".
#I121 Device install of "USB\VID_0000&PID_0000\5&260C57CF&0&2" finished
successfully.

Any idea of what I should do next?

Thank you again!

Jo-Anne

That's suggestive the problem is physical.

Yet, you say you've had a USB hard drive on that port, and it worked.

I would re-verify the USB hard drive works on that port.

For example, someone here had a VID/PID all zeros, and claims it
was a bad connection. I reviewed a number of other hits for this
search, and nobody managed to fix it!

http://social.technet.microsoft.com...e/thread/bbf4b69d-2bea-4860-9dab-3d27d3d223c4

I don't think that's the whole story, but I'm not finding any "solutions"
for this problem. I don't think it is always a bad connection or a power
problem. It's got to be something else. The thing is, the install
shouldn't
even start, if the OS can't read the thing.

Based on your error, the search term I was using is:

copy-only install of USB\VID_0000&PID_0000

The following is some standard boilerplate, for getting a copy of
USBView or UVCView. Such a program, allows viewing the config information
the USB device reports when probed. Now, in your case, we know the
VID and PID are reporting as zeros, and it's possible no endpoints
were formed to the USB device (communications path to the mouse failed).
So there might not be much to see with UVCView.

What we'd be looking for, by using UVCView, is whether
the sneaky mouse "makes a later appearance" after the bad_device driver
installation happens - implying a timing problem of some sort, like
the mouse is connected, disconnected, is connected again, fouling up
the driver installation. Using this tool, isn't a guarantee it can be
fixed, merely a diagnostic that may be able to say "yup, eventually
it appeared" or "nope, it's still dead".

UVCView is a Microsoft program, provided as a programming example.
At one time, it was available for easy download from the Microsoft site.
Then, Microsoft removed it from their web page. I started referring people
to copies stored on web.archive.org, and the bastards at Microsoft
had those removed as well (and likely, because I'd made public references
to the availability of the file, no other reason). In any case, these
are ways to get UVCView today. I don't know if Franc still offers his
copy or not.

***************** Sources of UVCVIEW ************************

This is my standard blurb for the older version of UVCView.

*******
ftp://ftp.efo.ru/pub/ftdichip/Utilities/UVCView.x86.exe
http://www.users.on.net/~fzabkar/USB_IDs/UVCView.x86.exe

File size is 167,232 bytes.
MD5sum is 93244d84d79314898e62d21cecc4ca5e

(You check the MD5sum to see if the copy is unadulterated. MD5sum has been
broken from a security standpoint, so it isn't an absolute "proof of
purchase".
You can use the Microsoft program "fciv" to check the MD5sum value, if you
don't
already have a copy. You can get fciv here. It's a command line utility.

http://www.microsoft.com/en-us/download/details.aspx?id=11533

)

This is a picture of what the UVCView info looks like. Notice the
idVendor and idProduct are non-zero values.

http://www.die.de/blog/content/binary/usbview.png

Some information on the parameters seen in UVCView.

http://www.beyondlogic.org/usbnutshell/usb5.htm
*******

There is a later version of UVCView, but I doubt it adds anything
to the capabilities. UVCView, is just USBView program with UVC Class
readout added to the analysis of the config info. (UVC is for web cams.)

This is my recipe for the latest version I know of.

*******
Download a copy of Windows Device Kit. Yes, I hate telling people to do
this!

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=11800

GRMWDK_EN_7600_1.ISO 649,877,504 bytes

You can use the 7ZIP program, to extract a file from within the downloaded
ISO, without the hassle of installing it. (I don't like filling my
computer
with garbage, which is why I do stuff like this instead. The UVCView
program
doesn't need to be installed as such. It's standalone, and uses no
registry
entries that I'm aware of.)

Using 7ZIP, open the ISO, then navigate to "WDK" and find

avstreamtools_x86fre_cab001.cab

Click on the cab, do an "Open Inside", then select

_UVCview.exe_00006

then extract. Then rename the extracted file to

UVCView2.exe

The file should be 133,632 bytes and have MD5SUM =
213f6e89cc4ab4e7e9e3e2ad394b83cb

We trust Microsoft, and checking the MD5SUM in this case, is more
curiosity
than anything else.

The interface works the same way as the other versions.
*******

The device being analyzed, should be connected directly to
a computer USB port. It doesn't help if there is a hub in
the way. You might not "see" the device at all with UVCView
if you did that. Sometimes, a computer uses an "internal hub
chip", and then the device will not appear, and there is nothing
we can do (short of editing the source code to UVCView and
recompiling it etc.).

***************** End of UVCVIEW boilerplate ********************

If UVCView shows a valid device appearing on the bad USB port,
you could try going to Device Manager, and "scan for new hardware".
But I expect that's not going to work, because the "bad.device"
driver installation has "plugged the hole" and the OS thinks it
is already using the "best driver". Still, this is the only
option I can think of.

I doubt removing the entire USB stack would help. All USB devices,
should be rediscovered if you do this. It's just a lot of work,
with no certainty things will be any better later.

http://www.usbman.com/Guides/Cleanup Device Manager Safe Mode.htm

"WinXP and 2000 - Removing USB devices in Safe Mode will force the OS
to refresh the USB driver stack and may cause a shift in IRQ
assignment."

Note the "warning" on that page, about what happens to USB keyboard and
mouse, and losing control of the system. In your case, with the laptop,
there really aren't any temporary hardware workarounds, to avoid losing
control of the system. And I'm not convinced at this point, that the
USB\VID_0000&PID_0000 thing is happening, because of something in the
registry. It doesn't look likely at this point. Maybe it has something
to do, with some other thing like your trackpad, sharing the same wiring
as that USB port (i.e. an internal hub chip).

A scripted way of doing this, is offered on this page. RenewUSB.bat
This does the equivalent, of what the usbman.com page is suggesting.

http://www.robvanderwoude.com/devcon.php

The renewusb.bat file, has commands of the form:

DEVCON FindAll =USB
DEVCON Remove
DEVCON ReScan

After the "DEVCON Remove" stage, you'd have no working keyboard and mouse.
But, since the DEVCON ReScan line comes right after that, you sit back
and relax, as the entire USB stack is "rediscovered" again. So Rob's
script
may avoid the problem the USBman.com site warns about. It's because the
script has the logic, to repair the damage caused by the "Remove".

If you have a backup of C:, you have nothing to worry about Seriously,
if I simply had to try that, I'd do a backup of C: (using software that
boots on its own when WinXP is broken), then try running renewusb.bat
with a copy of devcon.exe in the same directory.

When you download .bat files off the net, you can review them first, by
changing the file extension. The first time I downloaded renewusb.zip,
I extracted renewusb.bat and changed the extension on the file, to
renewusb.bat.txt, so I could open the file with Wordpad or Notepad.
Take a few moments, to review the code and get a general understanding
of how it works. Sometimes, there are developer notes inside the bat
file, warning about certain things. Once you're happy the .bat file
is safe looking, you can change it back to renewusb.bat again,
before running it. I try to run stuff like that from a Command Prompt
window, so I can review the output while it runs.

Have fun,
Paul

Thank you again, Paul! Before I attempt anything else, I thought I'd let you
know that my flash drives and my external hard drives still show up properly
and work fine plugged into this port. However, another mouse I tried--a
three-button Logitech mouse--worked only as a generic two-button mouse. For
both the Contour mouse and the Logitech one, when I plug them into the top
USB port and look at Mouse Properties, they show up as what they are; when I
plug them into the bottom USB port, they show up as generic two-button mice.

Jo-Anne

 

[Paul]

Thank you again, Paul! Before I attempt anything else, I thought I'd let you
know that my flash drives and my external hard drives still show up properly
and work fine plugged into this port. However, another mouse I tried--a
three-button Logitech mouse--worked only as a generic two-button mouse. For
both the Contour mouse and the Logitech one, when I plug them into the top
USB port and look at Mouse Properties, they show up as what they are; when I
plug them into the bottom USB port, they show up as generic two-button mice.

Jo-Anne

This is purely a guess at this point, but I think your touchpad software
is doing this. Either it's the touchpad software that is supposed to be
there. Or, during Windows Update, some other touchpad software was installed.

Touchpad software is "interested" in HID devices. Your USB storage devices
are not HID, which is why they're not affected. Keyboards and mice are HID
devices. If you had a defective USB keyboard or a defective USB mouse,
it's the touchpad driver I'd be interested in.

Paul

 

[Jo-Anne]

This is purely a guess at this point, but I think your touchpad software
is doing this. Either it's the touchpad software that is supposed to be
there. Or, during Windows Update, some other touchpad software was
installed.

Touchpad software is "interested" in HID devices. Your USB storage devices
are not HID, which is why they're not affected. Keyboards and mice are HID
devices. If you had a defective USB keyboard or a defective USB mouse,
it's the touchpad driver I'd be interested in.

Paul

But where would the wrong Touchpad software be? When I double-click on the
Dell Touchpad icon in the system tray, it opens correctly no matter which
USB port the mouse is plugged into. But when I click on "External Mouse
Settings" in the Dell Touchpad screen, the top port shows the Contour mouse
and the bottom port shows the generic mouse. I've been wondering if I should
try re-installing the mouse driver while the mouse is plugged into the "bad"
port. Is that likely to screw things up more?

Jo-Anne

 

[Paul]

But where would the wrong Touchpad software be? When I double-click on the
Dell Touchpad icon in the system tray, it opens correctly no matter which
USB port the mouse is plugged into. But when I click on "External Mouse
Settings" in the Dell Touchpad screen, the top port shows the Contour mouse
and the bottom port shows the generic mouse. I've been wondering if I should
try re-installing the mouse driver while the mouse is plugged into the "bad"
port. Is that likely to screw things up more?

Jo-Anne

We have to stop

"Doing copy-only install of "USB\VID_0000&PID_0000"

from happening first. Otherwise, the mouse driver will never get installed
on the "bad port". Some other thing has to be removed first, before the bad
port will behave properly. That's my guess.

As long as the OS is being fooled into thinking the mouse is VID_0000&PID_0000,
the values will never match the values listed in the INF file for the mouse
driver. And then, the mouse driver cannot install. Once the mouse returns real
numeric values during installation, then it's going to work. So the
thing which is hijacking the install, has to be stopped first.

My idea is just a hypothesis at this point, with little to back it up. All
I know is, that touchpad drivers are interested in "HID" or "human interface
device" class things.

Are there any touchpad related items in the "View Hidden" part of
Device Manager ?

Paul

 

[Jo-Anne]

We have to stop

"Doing copy-only install of "USB\VID_0000&PID_0000"

from happening first. Otherwise, the mouse driver will never get installed
on the "bad port". Some other thing has to be removed first, before the
bad
port will behave properly. That's my guess.

As long as the OS is being fooled into thinking the mouse is
VID_0000&PID_0000,
the values will never match the values listed in the INF file for the
mouse
driver. And then, the mouse driver cannot install. Once the mouse returns
real
numeric values during installation, then it's going to work. So the
thing which is hijacking the install, has to be stopped first.

My idea is just a hypothesis at this point, with little to back it up. All
I know is, that touchpad drivers are interested in "HID" or "human
interface
device" class things.

Are there any touchpad related items in the "View Hidden" part of
Device Manager ?

Paul

Yes, both the Dell Touchpad and the Perfit [Contour] Optical Mouse (USB) are
shown in View Hidden Devices.

Jo-Anne

 

[Paul]

We have to stop

"Doing copy-only install of "USB\VID_0000&PID_0000"

from happening first. Otherwise, the mouse driver will never get installed
on the "bad port". Some other thing has to be removed first, before the
bad
port will behave properly. That's my guess.

As long as the OS is being fooled into thinking the mouse is
VID_0000&PID_0000,
the values will never match the values listed in the INF file for the
mouse
driver. And then, the mouse driver cannot install. Once the mouse returns
real
numeric values during installation, then it's going to work. So the
thing which is hijacking the install, has to be stopped first.

My idea is just a hypothesis at this point, with little to back it up. All
I know is, that touchpad drivers are interested in "HID" or "human
interface
device" class things.

Are there any touchpad related items in the "View Hidden" part of
Device Manager ?

Paul

Yes, both the Dell Touchpad and the Perfit [Contour] Optical Mouse (USB) are
shown in View Hidden Devices.

Jo-Anne

But, are they in the "Non-Plug and Play Devices" section ?
The "Non-Plug and Play Devices" section is what I see added to Device Manager,
when selecting "View Hidden Devices".

On my laptop, I have:

Human Interface Devices
USB Input Device <---- Hardware ID VID 03EE (my Mitsumi mouse)

Mice and Other Pointing Devices
HID Compliant Mouse <---- Hardware ID VID 03EE (my Mitsumi mouse)
Synaptics PS/2 Port Touchpad <---- Hardware ID "ACPI\SYN1B17", passed in ACPI table
from the BIOS. A large driver list, from Synaptics.

Non-Plug and Play Devices <---- (Nothing Mouse or Touchpad related in here)

If there were entries related to the problem, in the Non-Plug and Play Devices
section, that would be suspicious. There are a great many items in there
on my laptop and desktop, some of which are used by programs for bypassing
permissions or the like. But at the moment, nothing HID related on my laptop
is in there.

On occasion, on my desktop, I've deleted an item from the Non-Plug
section, which I knew was no longer being used. Like perhaps
"GiveIO" used by MBM5 temperature readout program. If I know for certain,
I won't be using a thing like that again, and there isn't an actual
uninstaller to get rid of it, I may end up deleting it manually.
But I don't do that very often.

I would take finding "interesting things" in the Non-Plug and Play Devices
section, as being a side effect of whatever is wrong.

Paul

 

[Jo-Anne]

Jo-Anne wrote:
Jo-Anne wrote:

Thank you again, Paul! Before I attempt anything else, I thought I'd
let
you
know that my flash drives and my external hard drives still show up
properly
and work fine plugged into this port. However, another mouse I
tried--a
three-button Logitech mouse--worked only as a generic two-button
mouse.
For
both the Contour mouse and the Logitech one, when I plug them into
the
top
USB port and look at Mouse Properties, they show up as what they are;
when I
plug them into the bottom USB port, they show up as generic
two-button
mice.

Jo-Anne
This is purely a guess at this point, but I think your touchpad
software
is doing this. Either it's the touchpad software that is supposed to
be
there. Or, during Windows Update, some other touchpad software was
installed.

Touchpad software is "interested" in HID devices. Your USB storage
devices
are not HID, which is why they're not affected. Keyboards and mice are
HID
devices. If you had a defective USB keyboard or a defective USB mouse,
it's the touchpad driver I'd be interested in.

Paul

But where would the wrong Touchpad software be? When I double-click on
the
Dell Touchpad icon in the system tray, it opens correctly no matter
which
USB port the mouse is plugged into. But when I click on "External Mouse
Settings" in the Dell Touchpad screen, the top port shows the Contour
mouse
and the bottom port shows the generic mouse. I've been wondering if I
should
try re-installing the mouse driver while the mouse is plugged into the
"bad"
port. Is that likely to screw things up more?

Jo-Anne
We have to stop

"Doing copy-only install of "USB\VID_0000&PID_0000"

from happening first. Otherwise, the mouse driver will never get
installed
on the "bad port". Some other thing has to be removed first, before the
bad
port will behave properly. That's my guess.

As long as the OS is being fooled into thinking the mouse is
VID_0000&PID_0000,
the values will never match the values listed in the INF file for the
mouse
driver. And then, the mouse driver cannot install. Once the mouse
returns
real
numeric values during installation, then it's going to work. So the
thing which is hijacking the install, has to be stopped first.

My idea is just a hypothesis at this point, with little to back it up.
All
I know is, that touchpad drivers are interested in "HID" or "human
interface
device" class things.

Are there any touchpad related items in the "View Hidden" part of
Device Manager ?

Paul

Yes, both the Dell Touchpad and the Perfit [Contour] Optical Mouse (USB)
are
shown in View Hidden Devices.

Jo-Anne

But, are they in the "Non-Plug and Play Devices" section ?
The "Non-Plug and Play Devices" section is what I see added to Device
Manager,
when selecting "View Hidden Devices".

On my laptop, I have:

Human Interface Devices
USB Input Device <---- Hardware ID VID 03EE (my Mitsumi
mouse)

Mice and Other Pointing Devices
HID Compliant Mouse <---- Hardware ID VID 03EE (my Mitsumi
mouse)
Synaptics PS/2 Port Touchpad <---- Hardware ID "ACPI\SYN1B17", passed
in ACPI table
from the BIOS. A large driver list,
from Synaptics.

Non-Plug and Play Devices <---- (Nothing Mouse or Touchpad related
in here)

If there were entries related to the problem, in the Non-Plug and Play
Devices
section, that would be suspicious. There are a great many items in there
on my laptop and desktop, some of which are used by programs for bypassing
permissions or the like. But at the moment, nothing HID related on my
laptop
is in there.

On occasion, on my desktop, I've deleted an item from the Non-Plug
section, which I knew was no longer being used. Like perhaps
"GiveIO" used by MBM5 temperature readout program. If I know for certain,
I won't be using a thing like that again, and there isn't an actual
uninstaller to get rid of it, I may end up deleting it manually.
But I don't do that very often.

I would take finding "interesting things" in the Non-Plug and Play Devices
section, as being a side effect of whatever is wrong.

Paul

As far as I can tell, there's nothing mouse or touchpad related in the
Non-Plug and Play Devices section.

Jo-Anne

 

[Paul]

Jo-Anne wrote:
Jo-Anne wrote:

Thank you again, Paul! Before I attempt anything else, I thought I'd
let
you
know that my flash drives and my external hard drives still show up
properly
and work fine plugged into this port. However, another mouse I
tried--a
three-button Logitech mouse--worked only as a generic two-button
mouse.
For
both the Contour mouse and the Logitech one, when I plug them into
the
top
USB port and look at Mouse Properties, they show up as what they are;
when I
plug them into the bottom USB port, they show up as generic
two-button
mice.

Jo-Anne
This is purely a guess at this point, but I think your touchpad
software
is doing this. Either it's the touchpad software that is supposed to
be
there. Or, during Windows Update, some other touchpad software was
installed.

Touchpad software is "interested" in HID devices. Your USB storage
devices
are not HID, which is why they're not affected. Keyboards and mice are
HID
devices. If you had a defective USB keyboard or a defective USB mouse,
it's the touchpad driver I'd be interested in.

Paul
But where would the wrong Touchpad software be? When I double-click on
the
Dell Touchpad icon in the system tray, it opens correctly no matter
which
USB port the mouse is plugged into. But when I click on "External Mouse
Settings" in the Dell Touchpad screen, the top port shows the Contour
mouse
and the bottom port shows the generic mouse. I've been wondering if I
should
try re-installing the mouse driver while the mouse is plugged into the
"bad"
port. Is that likely to screw things up more?

Jo-Anne
We have to stop

"Doing copy-only install of "USB\VID_0000&PID_0000"

from happening first. Otherwise, the mouse driver will never get
installed
on the "bad port". Some other thing has to be removed first, before the
bad
port will behave properly. That's my guess.

As long as the OS is being fooled into thinking the mouse is
VID_0000&PID_0000,
the values will never match the values listed in the INF file for the
mouse
driver. And then, the mouse driver cannot install. Once the mouse
returns
real
numeric values during installation, then it's going to work. So the
thing which is hijacking the install, has to be stopped first.

My idea is just a hypothesis at this point, with little to back it up.
All
I know is, that touchpad drivers are interested in "HID" or "human
interface
device" class things.

Are there any touchpad related items in the "View Hidden" part of
Device Manager ?

Paul

Yes, both the Dell Touchpad and the Perfit [Contour] Optical Mouse (USB)
are
shown in View Hidden Devices.

Jo-Anne

But, are they in the "Non-Plug and Play Devices" section ?
The "Non-Plug and Play Devices" section is what I see added to Device
Manager,
when selecting "View Hidden Devices".

On my laptop, I have:

Human Interface Devices
USB Input Device <---- Hardware ID VID 03EE (my Mitsumi
mouse)

Mice and Other Pointing Devices
HID Compliant Mouse <---- Hardware ID VID 03EE (my Mitsumi
mouse)
Synaptics PS/2 Port Touchpad <---- Hardware ID "ACPI\SYN1B17", passed
in ACPI table
from the BIOS. A large driver list,
from Synaptics.

Non-Plug and Play Devices <---- (Nothing Mouse or Touchpad related
in here)

If there were entries related to the problem, in the Non-Plug and Play
Devices
section, that would be suspicious. There are a great many items in there
on my laptop and desktop, some of which are used by programs for bypassing
permissions or the like. But at the moment, nothing HID related on my
laptop
is in there.

On occasion, on my desktop, I've deleted an item from the Non-Plug
section, which I knew was no longer being used. Like perhaps
"GiveIO" used by MBM5 temperature readout program. If I know for certain,
I won't be using a thing like that again, and there isn't an actual
uninstaller to get rid of it, I may end up deleting it manually.
But I don't do that very often.

I would take finding "interesting things" in the Non-Plug and Play Devices
section, as being a side effect of whatever is wrong.

Paul

As far as I can tell, there's nothing mouse or touchpad related in the
Non-Plug and Play Devices section.

Jo-Anne

Try uninstalling the touchpad software, reinstall the mouse software (if it
used custom software of some sort), then move the mouse to the "bad port" and
see if it works or not.

I'd attempt installation of the mouse software, while it's on the good port - or,
if the software install instructions were to say to leave the mouse disconnected
before installing, you could try that.

If your mouse doesn't have custom software (mine uses only the WinXP
mouhid.sys and mouclass.sys drivers), then all you can do is uninstall
the touchpad software, and see if the mouse works properly or not.
Then, while leaving the mouse in the now-working "bad port", try
reinstalling the touchpad software.

The touchpad software, should have an INF file, containing a match for
the hardware it is intended for. What it should not contain, is say,
an ACPI\mumble type item, one that is the BIOS way of declaring a mouse,
as that would match on everything (would try to interfere with mice
found on any port).

This is what my mouse shows for a hardware_id, on my desktop.

HID\Vid_046d&Pid_c01a&Rev_1900
HID\Vid_046d&Pid_c01a
HID_DEVICE_SYSTEM_MOUSE
HID_DEVICE_UP:0001_U:0002
HID_DEVICE

None of those is an ACPI\device type entry. And if I had a touchpad
on my system, I would expect the INF file to *not* have any entries
that match those.

The reason my mouse shows up that way, is it is a dual personality mouse
(PS/2 or USB) and is currently running on a USB port. USB supports
plug and play, and used VID/PID numbers for identification.

If I look at the "Details : hardware ids" for my PS/2 keyboard, it shows

ACPI\PNP0303
*PNP0303

and that is presumably a standard way for the BIOS to pass the info
that "there is a keyboard" on the system. I think PS/2 still has
some way to get information about devices, but it isn't nearly
as sophisticated as the USB way. For devices lacking sophistication,
the BIOS can identify items by passing them as ACPI objects. The
BIOS passes "tables" when the OS boots, and the OS uses that
information for things that don't have good identification schemes.

Paul

 

[Jo-Anne]

Jo-Anne wrote:
Jo-Anne wrote:
Jo-Anne wrote:

Thank you again, Paul! Before I attempt anything else, I thought
I'd
let
you
know that my flash drives and my external hard drives still show up
properly
and work fine plugged into this port. However, another mouse I
tried--a
three-button Logitech mouse--worked only as a generic two-button
mouse.
For
both the Contour mouse and the Logitech one, when I plug them into
the
top
USB port and look at Mouse Properties, they show up as what they
are;
when I
plug them into the bottom USB port, they show up as generic
two-button
mice.

Jo-Anne
This is purely a guess at this point, but I think your touchpad
software
is doing this. Either it's the touchpad software that is supposed to
be
there. Or, during Windows Update, some other touchpad software was
installed.

Touchpad software is "interested" in HID devices. Your USB storage
devices
are not HID, which is why they're not affected. Keyboards and mice
are
HID
devices. If you had a defective USB keyboard or a defective USB
mouse,
it's the touchpad driver I'd be interested in.

Paul
But where would the wrong Touchpad software be? When I double-click
on
the
Dell Touchpad icon in the system tray, it opens correctly no matter
which
USB port the mouse is plugged into. But when I click on "External
Mouse
Settings" in the Dell Touchpad screen, the top port shows the Contour
mouse
and the bottom port shows the generic mouse. I've been wondering if I
should
try re-installing the mouse driver while the mouse is plugged into
the
"bad"
port. Is that likely to screw things up more?

Jo-Anne
We have to stop

"Doing copy-only install of "USB\VID_0000&PID_0000"

from happening first. Otherwise, the mouse driver will never get
installed
on the "bad port". Some other thing has to be removed first, before
the
bad
port will behave properly. That's my guess.

As long as the OS is being fooled into thinking the mouse is
VID_0000&PID_0000,
the values will never match the values listed in the INF file for the
mouse
driver. And then, the mouse driver cannot install. Once the mouse
returns
real
numeric values during installation, then it's going to work. So the
thing which is hijacking the install, has to be stopped first.

My idea is just a hypothesis at this point, with little to back it up.
All
I know is, that touchpad drivers are interested in "HID" or "human
interface
device" class things.

Are there any touchpad related items in the "View Hidden" part of
Device Manager ?

Paul

Yes, both the Dell Touchpad and the Perfit [Contour] Optical Mouse
(USB)
are
shown in View Hidden Devices.

Jo-Anne


But, are they in the "Non-Plug and Play Devices" section ?
The "Non-Plug and Play Devices" section is what I see added to Device
Manager,
when selecting "View Hidden Devices".

On my laptop, I have:

Human Interface Devices
USB Input Device <---- Hardware ID VID 03EE (my Mitsumi
mouse)

Mice and Other Pointing Devices
HID Compliant Mouse <---- Hardware ID VID 03EE (my Mitsumi
mouse)
Synaptics PS/2 Port Touchpad <---- Hardware ID "ACPI\SYN1B17",
passed
in ACPI table
from the BIOS. A large driver
list,
from Synaptics.

Non-Plug and Play Devices <---- (Nothing Mouse or Touchpad
related
in here)

If there were entries related to the problem, in the Non-Plug and Play
Devices
section, that would be suspicious. There are a great many items in there
on my laptop and desktop, some of which are used by programs for
bypassing
permissions or the like. But at the moment, nothing HID related on my
laptop
is in there.

On occasion, on my desktop, I've deleted an item from the Non-Plug
section, which I knew was no longer being used. Like perhaps
"GiveIO" used by MBM5 temperature readout program. If I know for
certain,
I won't be using a thing like that again, and there isn't an actual
uninstaller to get rid of it, I may end up deleting it manually.
But I don't do that very often.

I would take finding "interesting things" in the Non-Plug and Play
Devices
section, as being a side effect of whatever is wrong.

Paul

As far as I can tell, there's nothing mouse or touchpad related in the
Non-Plug and Play Devices section.

Jo-Anne

Try uninstalling the touchpad software, reinstall the mouse software (if
it
used custom software of some sort), then move the mouse to the "bad port"
and
see if it works or not.

I'd attempt installation of the mouse software, while it's on the good
port - or,
if the software install instructions were to say to leave the mouse
disconnected
before installing, you could try that.

If your mouse doesn't have custom software (mine uses only the WinXP
mouhid.sys and mouclass.sys drivers), then all you can do is uninstall
the touchpad software, and see if the mouse works properly or not.
Then, while leaving the mouse in the now-working "bad port", try
reinstalling the touchpad software.

The touchpad software, should have an INF file, containing a match for
the hardware it is intended for. What it should not contain, is say,
an ACPI\mumble type item, one that is the BIOS way of declaring a mouse,
as that would match on everything (would try to interfere with mice
found on any port).

This is what my mouse shows for a hardware_id, on my desktop.

HID\Vid_046d&Pid_c01a&Rev_1900
HID\Vid_046d&Pid_c01a
HID_DEVICE_SYSTEM_MOUSE
HID_DEVICE_UP:0001_U:0002
HID_DEVICE

None of those is an ACPI\device type entry. And if I had a touchpad
on my system, I would expect the INF file to *not* have any entries
that match those.

The reason my mouse shows up that way, is it is a dual personality mouse
(PS/2 or USB) and is currently running on a USB port. USB supports
plug and play, and used VID/PID numbers for identification.

If I look at the "Details : hardware ids" for my PS/2 keyboard, it shows

ACPI\PNP0303
*PNP0303

and that is presumably a standard way for the BIOS to pass the info
that "there is a keyboard" on the system. I think PS/2 still has
some way to get information about devices, but it isn't nearly
as sophisticated as the USB way. For devices lacking sophistication,
the BIOS can identify items by passing them as ACPI objects. The
BIOS passes "tables" when the OS boots, and the OS uses that
information for things that don't have good identification schemes.

Paul

Where would I find the INF file for the touchpad, Paul? For what it's worth,
there's an entry for the Dell Touchpad in Add/Remove Programs, but there's
nothing at all for the Contour Mouse either there or in Program Files. Yet,
when the mouse is plugged into the working port, the Touchpad Properties
shows it by name.

Jo-Anne

 

[Paul]

Where would I find the INF file for the touchpad, Paul? For what it's worth,
there's an entry for the Dell Touchpad in Add/Remove Programs, but there's
nothing at all for the Contour Mouse either there or in Program Files. Yet,
when the mouse is plugged into the working port, the Touchpad Properties
shows it by name.

Jo-Anne

When this program extracted, it said it was for Precision M4300 and apparently
it's by Alps. The self extracting file puts the stuff in C:\dell\drivers\R153769 .
And this was not in the 64 file M4300 section on the Dell site. I had to do
an external search, discover the file name, then get it from Dell. For some
reason, it isn't in the "input" section of the M4300 downloads.

http://downloads.dell.com/input/R153769.EXE

When you install a custom driver, such as the Alps, the Apfiltr.inf is
copied into C:\WINDOWS\inf, but the file is also renamed. The new file
name assigned to the file content, is of the form "oem25.inf", where
OEM implies a custom driver has been installed, and the two digit value
is a sequential number. As each custom driver is installed, if there is
an INF, the number is bumped by one so there won't be a name collision.
So if I did a "content" search in C:\WINDOWS\inf, for "Apfiltr.inf",
I'm going to find that string, inside an OEM25.inf type file. Now, I
have OEM files stretching up to OEM25.inf, and on your machine, it might
stretch up to a different number. But if you search on Apfiltr.inf as
a text string, using the Windows search, and focus it on the C:\WINDOWS\inf,
you should get a match in an OEMxx.inf type file.

This is the INF of the ALPS driver. And I see some suspicious entries.
The intention would be to match on ACPI\PNP0F13 for example.

*******
; Apfiltr.inf
;
; Alps Pointing-device Driver for Windows 2K/XP/Vista Installation
; Copyright(C) 1999-2007 Alps Electric Co., Ltd.

[CompanyMfg] ; for 2000, XP
%Apoint.DeviceDesc% = MouFilter_Inst.nt,*PNP0F13,*PNP0F03,*PNP0F0E,*PNP0F0b,*PNP0F12
%Apoint.DeviceDesc% = MouFilter_Inst.nt,*AUI0300 ; DELL Comaneci
%Apoint.DeviceDesc% = MouFilter_Inst.nt,*AUI0301 ; DELL Bondi /Benz
*******

Now, I also get interesting entries, in the C:\WINDOWS\inf\msmouse.inf file.
And that file, I expect, is to handle other mice (without custom drivers).
My Logitech mouse would be handled by a file like that. I've extracted these
particular entries, so I can "decode" what the Alps driver is looking for. And
a common theme, is things on "PS/2 ports", not USB.

PNP0F13 ; MS PS/2 mouse
PNP0F03 ; MS PS/2 mouse
PNP0F0E ; Std PS/2 mouse i8042prt
PNP0F0B ; MS PS/2 mouse
PNP0F12 ; Logi PS/2 mouse i8042prt

So the question would be, why is the Alps driver claiming to be the driver
for some PS/2 mice ? It could be, that the touchpad is connected to a PS/2
interface inside the laptop. But then, why would your Contour Mouse be
identified in that way. It should be a USB device ?

If I use the free version of Lavalys Everest (from years ago), the only
HID item in the PNP section, is this, my keyboard. My keyboard is a PS/2
device.

PnP Devices:
PNP0303 101/102-Key or MS Natural Keyboard

My mouse is a USB device (since I don't have a second PS/2 port for the mouse).
This is what Everest shows for it. The mouse does not appear to have a PNP
identifier, as USB has a perfectly good plug and play scheme of its own
(the VID/PID, which in this case is 046D for Logitech, and C01A for the
particular flavor of mouse M-BQ85 optical with scroll wheel).

USB Devices:
046D C01A USB Human Interface Device

So what I don't understand in your case, is how the Alps driver
has concluded the Contour mouse belongs to it. The INF seems to
imply it will glom onto *PNP0F13,*PNP0F03,*PNP0F0E,*PNP0F0b,*PNP0F12
which are PS/2 things ?

From what I'm seeing, I don't know if removing the Alps package is
going to help. I mean, if the INF matching scheme was working properly,
your Contour mouse should never have been involved in the first place.

As far as I know, a "USB port is a USB port". I've never heard of USB
ports being dual personality.

In Everest, you'd use the Report wizard, select "Hardware related"
items, and ask for a plain text output. In there, you'd look for

--------[ Physical Devices ]---------

then

PnP Devices:

and see if the Contour is in there. As far as I know, the Contour should
be appearing with respect to some USB entry.

When I look in the unofficial list of USB devices, I'm not seeing something
I identify as your mouse. But if you use Everest, you'll be able to get the
info for it, and see how the system identifies it.

http://www.linux-usb.org/usb.ids

Everest is here.

http://majorgeeks.com/download4181.html

I use the Report Wizard in there, as it's easier to do a text search
in the report listing, and find the hardware entries I'm looking for.
Using the GUI interface for this purpose, is a lot harder.

*******

Does the Alps control panel, allow "deleting" the Contour entry ?
Is that the purpose of that panel ? I don't have a lot of
experience with touchpads, or how they're controlled.

Paul

 

[Jo-Anne]

Where would I find the INF file for the touchpad, Paul? For what it's
worth,
there's an entry for the Dell Touchpad in Add/Remove Programs, but
there's
nothing at all for the Contour Mouse either there or in Program Files.
Yet,
when the mouse is plugged into the working port, the Touchpad Properties
shows it by name.

Jo-Anne

When this program extracted, it said it was for Precision M4300 and
apparently
it's by Alps. The self extracting file puts the stuff in
C:\dell\drivers\R153769 .
And this was not in the 64 file M4300 section on the Dell site. I had to
do
an external search, discover the file name, then get it from Dell. For
some
reason, it isn't in the "input" section of the M4300 downloads.

http://downloads.dell.com/input/R153769.EXE

When you install a custom driver, such as the Alps, the Apfiltr.inf is
copied into C:\WINDOWS\inf, but the file is also renamed. The new file
name assigned to the file content, is of the form "oem25.inf", where
OEM implies a custom driver has been installed, and the two digit value
is a sequential number. As each custom driver is installed, if there is
an INF, the number is bumped by one so there won't be a name collision.
So if I did a "content" search in C:\WINDOWS\inf, for "Apfiltr.inf",
I'm going to find that string, inside an OEM25.inf type file. Now, I
have OEM files stretching up to OEM25.inf, and on your machine, it might
stretch up to a different number. But if you search on Apfiltr.inf as
a text string, using the Windows search, and focus it on the
C:\WINDOWS\inf,
you should get a match in an OEMxx.inf type file.

This is the INF of the ALPS driver. And I see some suspicious entries.
The intention would be to match on ACPI\PNP0F13 for example.

*******
; Apfiltr.inf
;
; Alps Pointing-device Driver for Windows 2K/XP/Vista Installation
; Copyright(C) 1999-2007 Alps Electric Co., Ltd.

[CompanyMfg] ; for 2000, XP
%Apoint.DeviceDesc% =
MouFilter_Inst.nt,*PNP0F13,*PNP0F03,*PNP0F0E,*PNP0F0b,*PNP0F12
%Apoint.DeviceDesc% = MouFilter_Inst.nt,*AUI0300 ; DELL Comaneci
%Apoint.DeviceDesc% = MouFilter_Inst.nt,*AUI0301 ; DELL Bondi /Benz
*******

Now, I also get interesting entries, in the C:\WINDOWS\inf\msmouse.inf
file.
And that file, I expect, is to handle other mice (without custom drivers).
My Logitech mouse would be handled by a file like that. I've extracted
these
particular entries, so I can "decode" what the Alps driver is looking for.
And
a common theme, is things on "PS/2 ports", not USB.

PNP0F13 ; MS PS/2 mouse
PNP0F03 ; MS PS/2 mouse
PNP0F0E ; Std PS/2 mouse i8042prt
PNP0F0B ; MS PS/2 mouse
PNP0F12 ; Logi PS/2 mouse i8042prt

So the question would be, why is the Alps driver claiming to be the driver
for some PS/2 mice ? It could be, that the touchpad is connected to a PS/2
interface inside the laptop. But then, why would your Contour Mouse be
identified in that way. It should be a USB device ?

If I use the free version of Lavalys Everest (from years ago), the only
HID item in the PNP section, is this, my keyboard. My keyboard is a PS/2
device.

PnP Devices:
PNP0303 101/102-Key or MS Natural Keyboard

My mouse is a USB device (since I don't have a second PS/2 port for the
mouse).
This is what Everest shows for it. The mouse does not appear to have a PNP
identifier, as USB has a perfectly good plug and play scheme of its own
(the VID/PID, which in this case is 046D for Logitech, and C01A for the
particular flavor of mouse M-BQ85 optical with scroll wheel).

USB Devices:
046D C01A USB Human Interface Device

So what I don't understand in your case, is how the Alps driver
has concluded the Contour mouse belongs to it. The INF seems to
imply it will glom onto *PNP0F13,*PNP0F03,*PNP0F0E,*PNP0F0b,*PNP0F12
which are PS/2 things ?

From what I'm seeing, I don't know if removing the Alps package is
going to help. I mean, if the INF matching scheme was working properly,
your Contour mouse should never have been involved in the first place.

As far as I know, a "USB port is a USB port". I've never heard of USB
ports being dual personality.

In Everest, you'd use the Report wizard, select "Hardware related"
items, and ask for a plain text output. In there, you'd look for

--------[ Physical Devices ]---------

then

PnP Devices:

and see if the Contour is in there. As far as I know, the Contour should
be appearing with respect to some USB entry.

When I look in the unofficial list of USB devices, I'm not seeing
something
I identify as your mouse. But if you use Everest, you'll be able to get
the
info for it, and see how the system identifies it.

http://www.linux-usb.org/usb.ids

Everest is here.

http://majorgeeks.com/download4181.html

I use the Report Wizard in there, as it's easier to do a text search
in the report listing, and find the hardware entries I'm looking for.
Using the GUI interface for this purpose, is a lot harder.

*******

Does the Alps control panel, allow "deleting" the Contour entry ?
Is that the purpose of that panel ? I don't have a lot of
experience with touchpads, or how they're controlled.

Paul

I'm getting beyond my depth, Paul. I thank you very much for all your
research, but I'm not sure I can do everything you suggest or whether I'm
capable of ever fixing the problem. Here's what I've found so far:

* I did a search on Apfiltr.inf in the Windows\inf folder and found nothing.
I then searched on just Apfiltr in the Windows folder (not just the inf
subfolder) and found only Apfiltr.sys in Windows\system32\drivers.

* I checked the Properties of the Dell Touchpad again and found that for
both the working and the nonworking port, at Touchpad External Mouse
Settings | Hardware, the Dell Touchpad location is "plugged into PS/2 mouse
port." On the working port, the Perfit Mouse (USB) is at location 0; on the
nonworking port, the mouse is called an HID-compliant mouse manufactured by
Microsoft, and it too is at location 0.

* When I looked at the Driver File Details for the Contour Mouse in the good
port, there were several files in Windows\Contour and two in
Windows\System32\drivers. The two driver files are hidxmse.sys and
mouclass.sys. The one that's checkmarked is mouclass.sys. On the bad port,
the Driver File Details for the HID-compliant mouse are
Windows\System32\drivers\mouclass.sys and mouhid.sys.

Thank you for everything, Paul!

Jo-Anne

 

[Jo-Anne]

The last driver I could find reference to for the Contour Perfit, should
have been here, but is not archived. The last driver might have been
offered
around 2008 or so, and then removed from the Contour web site.

perf206b2u.zip

Would the download at the bottom of this page not work (the one for Contour
Mouse for WinXP, Vista, and Win7)?

http://ergo.contour-design.com/support-and-downloads/drivers

Jo-Anne

 

[Paul]

Would the download at the bottom of this page not work (the one for Contour
Mouse for WinXP, Vista, and Win7)?

http://ergo.contour-design.com/support-and-downloads/drivers

Jo-Anne

That appears to be for some other products, as near as I can determine.

I couldn't examine that file with 7ZIP, and had to install it to have
a look. File is clean on Virustotal, and so I just loaded it into
Ubuntu WINE so I could get to the INF. This is the file I got.

C:\Program Files\Contour Mouse\Drivers\i386\cntmou.inf

DiskId1 = "Contour Design Mouse Driver installation disk"
Company = "Contour Design"
cntmou.SvcDesc = "Contour Design Mouse Driver"
USB\Vid_0b33&Pid_0702.DeviceDesc = "Contour Rollermouse PRO2"
USB\Vid_0b33&Pid_7501.DeviceDesc = "Contour Medimouse"
USB\Vid_0b33&Pid_7500.DeviceDesc = "Contour Unimouse"
USB\Vid_0b33&Pid_01f0.DeviceDesc = "Contour Minipro"
USB\Vid_0b33&Pid_08a0.DeviceDesc = "Contour Mouse"
USB\Vid_0b33&Pid_08a1.DeviceDesc = "Contour Mouse 1200"
USB\Vid_0b33&Pid_0401&Mi_00.DeviceDesc = "Contour Rollermouse Free 2"
USB\Vid_0b33&Pid_0800.DeviceDesc = "Contour Rollermouse Free"
USB\Vid_0b33&Pid_0903.DeviceDesc = "Contour Design Mouse"
USB\Vid_0b33&Pid_0700.DeviceDesc = "Contour Rollermouse PRO"
USB\Vid_0b33&Pid_0602.DeviceDesc = "Contour Rollermouse Classic 2"

I don't see the "Perfit" listed there.

And the way you'd verify, is put the Contour back in the working
port, go to Device Manager, click on the mouse entry, right-click,
select "Properties", then "Details", then select "Hardware Ids" from
the menu, and you should see Vid and Pid values. See if they match the
previous set of four I listed, or match anything in the eleven
in this posting. That'll give you some idea which driver to use.
It could be, they've stopped supporting the Perfit.

I'd give you a link to the infected driver, but I don't know
how exactly you'd clean it. The first level of infection,
was a tool bar. Once I got past that, the actual driver file
still had one item in it that virustotal detected. The only
file I could really trust at that point, was to load the
INF in a text editor I wouldn't actually want to
try to install the thing Bad mojo.

Paul

 

[Jo-Anne]

That appears to be for some other products, as near as I can determine.

I couldn't examine that file with 7ZIP, and had to install it to have
a look. File is clean on Virustotal, and so I just loaded it into
Ubuntu WINE so I could get to the INF. This is the file I got.

C:\Program Files\Contour Mouse\Drivers\i386\cntmou.inf

DiskId1 = "Contour Design Mouse Driver installation disk"
Company = "Contour Design"
cntmou.SvcDesc = "Contour Design Mouse Driver"
USB\Vid_0b33&Pid_0702.DeviceDesc = "Contour Rollermouse PRO2"
USB\Vid_0b33&Pid_7501.DeviceDesc = "Contour Medimouse"
USB\Vid_0b33&Pid_7500.DeviceDesc = "Contour Unimouse"
USB\Vid_0b33&Pid_01f0.DeviceDesc = "Contour Minipro"
USB\Vid_0b33&Pid_08a0.DeviceDesc = "Contour Mouse"
USB\Vid_0b33&Pid_08a1.DeviceDesc = "Contour Mouse 1200"
USB\Vid_0b33&Pid_0401&Mi_00.DeviceDesc = "Contour Rollermouse Free 2"
USB\Vid_0b33&Pid_0800.DeviceDesc = "Contour Rollermouse Free"
USB\Vid_0b33&Pid_0903.DeviceDesc = "Contour Design Mouse"
USB\Vid_0b33&Pid_0700.DeviceDesc = "Contour Rollermouse PRO"
USB\Vid_0b33&Pid_0602.DeviceDesc = "Contour Rollermouse Classic 2"

I don't see the "Perfit" listed there.

And the way you'd verify, is put the Contour back in the working
port, go to Device Manager, click on the mouse entry, right-click,
select "Properties", then "Details", then select "Hardware Ids" from
the menu, and you should see Vid and Pid values. See if they match the
previous set of four I listed, or match anything in the eleven
in this posting. That'll give you some idea which driver to use.
It could be, they've stopped supporting the Perfit.

I'd give you a link to the infected driver, but I don't know
how exactly you'd clean it. The first level of infection,
was a tool bar. Once I got past that, the actual driver file
still had one item in it that virustotal detected. The only
file I could really trust at that point, was to load the
INF in a text editor I wouldn't actually want to
try to install the thing Bad mojo.

Paul

I think the Perfit mouse and the Contour mouse are the same. The company
started with Contour, changed to Perfit, then went back to Contour (as I
recall). I've asked the tech support guy to confirm, and I'll let you know
if he does. In the meantime, here's what I got at Device Manager Hardware
IDs for the Perfit Optical Mouse (USB)--all HID, not USB:

HID\Vid_0b33&Pid_08a0&Rev_0001
HID\Vid_0b33&Pid_08a0
HID_DEVICE_SYSTEM_MOUSE
HID_DEVICE_UP:0001_U:0002
HID_DEVICE

I don't know if it's of any value, but under Device Instance Id, there's

HID\VID_0B33&PID_08A0\6&31329D32&0&0000

What do you think???

Jo-Anne

 

[Paul]

I think the Perfit mouse and the Contour mouse are the same. The company
started with Contour, changed to Perfit, then went back to Contour (as I
recall). I've asked the tech support guy to confirm, and I'll let you know
if he does. In the meantime, here's what I got at Device Manager Hardware
IDs for the Perfit Optical Mouse (USB)--all HID, not USB:

HID\Vid_0b33&Pid_08a0&Rev_0001
HID\Vid_0b33&Pid_08a0
HID_DEVICE_SYSTEM_MOUSE
HID_DEVICE_UP:0001_U:0002
HID_DEVICE

I don't know if it's of any value, but under Device Instance Id, there's

HID\VID_0B33&PID_08A0\6&31329D32&0&0000

What do you think???

Jo-Anne

OK, the latest driver you pointed me to, would be installing "cntmou.sys"
which is apparently listed in the INF as a service.

Yet, you reported you had "HIDXMSE.SYS" and "HIDMOUSE.SYS" in your
system. As if you'd installed the older driver. And the older
driver doesn't match (INF entry doesn't match), so using the
older install should have stopped.

The two driver types are quite different in design. The latest driver
uses "dpinst.exe" and Microsoft describes it as:

"Driver Package Installer (DPInst)

Driver Package Installer (DPInst) version 2.1 is a component of
Driver Install Frameworks (DIFx) version 2.1. DIFx simplifies
and customizes the installation of driver packages for devices
that have not yet been installed in a computer.

This type of installation is commonly known as a software-first
installation."

Not that the distinction is important or anything. I don't know if the
newer style of driver, was supposed to remove the older one. Your
situation might be perfectly valid, if you had two different Contour
mice, an old one and a newer one.

What bothers me a bit, is you have "Vid_0b33&Pid_08a0" using
"HIDXMSE.SYS" and "HIDMOUSE.SYS", when the latest driver is
using something else. The INF files I have, don't give a way
of ending up that way.

I'm thinking maybe the latest driver is designed to be a filter
driver, but I can't really tell that from the driver files. It's
just a hunch.

Notice that the old driver with the "HIDXMSE.SYS" and "HIDMOUSE.SYS",
that was more of a "real" driver, providing a hardware interface to
the mouse. Whereas the latest driver, is probably intended to "shim" into
an existing set of drivers, such as the Microsoft "mouclass.sys" and
"mouhid.sys".

My mouse seems to create two entries:

Human Interface Device
USB Human Interface Device
Driver files = hidclass.sys, hidparse.sys, hidusb.sys, hid.dll

Mice and other pointing devices
HID-compliant mouse
Driver files = mouclass.sys, mouhid.sys

I suspect the first entry, somehow converts USB\Vid_046d&Pid_c01a to
HID\Vid_046d&Pid_c01a . The first part of one of those chunks of
numbers, is the "bus" the device is on. So they made a fake bus
called "HID" for my mouse. Your mouse seems to use that convention
as well, as your entry is HID\VID_0B33&PID_08A0.

Do you have two entries in Add/Remove from ContourDesign ? Perhaps
for the old and the new driver ? If you did have the old driver,
perhaps it should be uninstalled. Seeing as the new driver actually
matches in terms of the INF file and HID\VID_0B33&PID_08A0.

Paul






Paul