WARNING: More compatibility issues with KB908531 that KB918165 fails to note

[Bill Drake]

Yesterday, I spent several hours tracking down an intermittent shutdown
problem on a Client's machine - where the machine would stall and several
items loaded automatically at startup required manually ending their tasks
before Windows would shut down.

The final task to be ended before Windows would shut down normally was
always Windows Explorer.


Eventually, I tracked this to the Kensington Mouseware software. If I
disabled the "kmw_run.exe" item in the startup list using MSConfig, the
machine would shut down normally.

I experimented with both the latest Kensington Mouseware software
(Version 6.20) and the immediately-previous release (Version 6.11).
Both software releases exhibited the same problem and the same
solution.


Eventually, I removed the Kensington Mouseware Software and reverted
to the standard Microsoft Mouse driver. The machine was completely
stable with the standard Windows-XP Microsoft Mouse driver in place
and I left the Client's machine in this configuration while I investigate
the
situation in more detail.


Things to note:

1. Opening the Mouse Control Panel applet (which loads Kensington's
customized Control Panel applet) and then closing the applet again
causes the machine to shutdown normally - as long as no other
popups interfere with the shutdown process.

2. The Version 6.11 software seems to be more stable than the 6.20
software. I noticed the machine was more cranky during shutdown
with the 6.20 software than the 6.11 software.

3. Changing the order of items in the startup allowed *one* restart to
occur normally after the change. On subsequent restarts, the
problem would recur.

4. Changes to the mouse driver configuration would allow *one* or
possibly *two* restarts to occur normally after the change. On
the third or fourth restart, the problem would recur.


Yes, quite the weird one. My guess is that this is similar to the HP
issue - where previously-working software has been impacted by the
updated security model imposed by the latest Microsoft Software
updates.

I know the Kensington Mouseware software on this Client's machine
did work properly when first installed. (I tested it extensively when
originally installed to ensure proper operation). This problem has
surfaced in the last 2 weeks.

Regardless, it looks like both Kensington and Microsoft are going to
have to investigate this situation and resolve whatever incompatibility
is present.


Best I can do for now. <tm>


Bill

 

[John R Weiss]

Eventually, I tracked this to the Kensington Mouseware software. If I
disabled the "kmw_run.exe" item in the startup list using MSConfig, the
machine would shut down normally.

I experimented with both the latest Kensington Mouseware software
(Version 6.20) and the immediately-previous release (Version 6.11).
Both software releases exhibited the same problem and the same
solution.

I'm using Mouseware 6.03, and it works fine with the latest updates. If the
client's mouse is supported by the older software, try it.

 

[motor man]

I'm using Mouseware 6.03, and it works fine with the latest updates. If the
client's mouse is supported by the older software, try it.

Is the Kmouse connected via serial port or USB? I ntoice that
Kensington offer 6.2 for non-serial port only. I presume that means a
USB connection. I just started to experience a similar problem on one
of our machines but in the past the problem has ALWAYSX been the vidoe
drivers NOT the Kmouse software. Sounds screwy but I check the bootlog
and found the problem quickly. It is also important for bothe vieo
drivers and mouse softwrae that all virus software and the BIOS
anti-virus be disabled BEFORE trying to doa reinstall. I assume that
you have really uninstalled all the Kmouse software and not just ran
the uninstall prgm. I use Regcleaner by Juoni Vuorino for cleaning the
reg files and the startup and also removing bits of prgms left after a
cleanup.