On Fri, 8/28/2026 12:37 PM, NY wrote:
On 28/08/2026 17:18, Alan K. wrote:
On 8/28/26 11:39 AM, NY wrote:
My Windows 10 laptop has just started exhibiting "wild mouse pointer"
syndrome - the mouse pointer occasionally jumps horizontally or
vertically on the screen by an inch or so (rarely in both directions at
the same time), even when the mouse is kept perfectly still.
Occasionally I've seen windows change position, as if I'd clicked on a
window's title bar to bring it to the foreground. It happens at
irregular intervals ranging from once every few seconds to once every
five minutes. Each shift is a permanent one: it's not that the pointer
moves somewhere else and then returns to its original position.
It's a USB mouse, and I've tried two different mice of the same type, in >>> all three USB ports. It happens both when the laptop is running on
battery and on mains power.
It is reliably cured by rebooting the PC, and then it's fine for a few
hours.
I can't see any common factor which provokes it: I just do standard
things like reading or replying to emails in Thunderbird, browsing the
web in Firefox, running LibreOffice Writer. I'm not aware of having
installed any software that has started it happening. The laptop is
about 5 years old and the problem has only just started.
Somewhere in the mouse settings, on most operating systems, there is a setting to disable the touch pad.ÿ Some software even goes a bit further and has a check box to disable the touch pad when an external mouse is plugged.ÿ The latter is the best option since all you have to do to activate the touch pad is pull the mouse out.
Sadly its not that. I turned my touchpad off long ago because I was finding that I was getting spurious touches. Not sure how I turned it off, because there's nothing obvious in the OS to turn it back on, and there's Fn-F11 which toggles it but neither setting makes the touchpad move the pointer or respond to its left/right clock buttons. I remember even before I disabled the whole touchpad, I turned off "Tapping" because if I moved my finger several times across the pad to get the pointer from one side of the screen to the other, I often got a spurious left-click.
I also found reference to the "Enhance pointer position" option in the Mouse applet of Control Panel and turned it off. I really thought that would work.
It's very odd. It's only just started happening. And it's very irregular: it happens a few times in rapid succession and then behaves fine for tens of minutes.
Check for Upperfilter and Lowerfilter drivers that don't belong.
Generally, things like kits, you no longer have to download the whole thing, but you do have to figure out which single tick box to tick, to get
the utilities installed. Right now, I don't have a devcon, and I do have
at least one kit (partially) installed (Win10, the other disk on this machine).
https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/devcon
"Where to download DevCon
DevCon (Devcon.exe) is included when you install the WDK, Visual Studio,
and the Windows SDK for desktop apps. For information about downloading the kits, see
https://learn.microsoft.com/en-us/windows-hardware/drivers/download-the-wdk
Windows Driver Kit (WDK) 10 version (installation path)
%WdkDir%\10\Tools\X.Y\x64\devcon.exe
%WdkDir%\10\Tools\X.Y\x86\devcon.exe
%WdkDir%\10\Tools\X.Y\arm64\devcon.exe
The %WdkDir% represents the directory where you installed the WDK and X.Y refers
to the version of the Windows Driver Kit. For example, if you have a recent WDK,
the DevCon tool is located in the directory path
C:\Program Files (x86)\Windows Kits\10\Tools\10.0.26100.0\x64\devcon.exe for 64-bit systems.
https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/devcon-examples
devcon stack * # could dump everything...
https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/devcon-stack
"Recommended replacement" [um, Hah, not quite the same]
pnputil /enum-devices /stack
Microsoft has, on occasion, released filter drivers where the INF
caused the driver to "bind to all HID devices". An affected individual
could have started with one OS, got some filter driver installed, and
it only became an issue when upgrading to some other OS. This could be
a filter driver intended for a touchpad, that binds to the mouse as
well. The driver could then be attempting to interpret "virtual buttons"
on the (non-existent) touchpad, based on X-Y coordinates.
Generally, optical mice, the array sensor on the bottom is very
good regarding dirt and obscuration. When you flip the mouse over
and have a look, generally there is nothing to note in that area,
no "fuzz" collects there. Whereas the "fuzz" does collect internally
and can cause scroll wheel issues or mouse button issues. I actually
swapped scroll wheel assemblies between two mice, in an effort to keep
one of the mice "going". The bearing seemed to be going in one of them.
Could not visually make out the defect.
Some devices always have Filter drivers. A trackpad has a physical layer driver, plus it has a Filter driver to implement "virtual buttons"
or "gestures". And these are sensitive to the current cursor X-Y coordinates. The filter driver then, watches the "stream" and "reacts" to certain things
it sees in the stream. Mice don't generally have features like that,
having physical buttons and plain X-Y coordinates.
https://networchestration.wordpress.com/2016/07/11/how-to-obtain-device-console-utility-devcon-exe-without-downloading-and-installing-the-entire-windows-driver-kit-100-working-method/
https://download.microsoft.com/download/B/5/8/B58D625D-17D6-47A8-B3D3-668670B6D1EB/wdk/Installers/787bee96dbd26371076b37b13c405890.cab
File filbad6e2cce5ebc45a401e19c613d0a28f is devcon64.exe # I examined the cab with 7ZIP
# Identity check with Agent Ransack and then HxD.
https://download.microsoft.com/download/B/5/8/B58D625D-17D6-47A8-B3D3-668670B6D1EB/wdk/Installers/82c1721cd310c73968861674ffc209c9.cab
File fil5a9177f816435063f779ebbbd2c1a1d2 is devcon.exe # I examined the cab with 7ZIP
D:\devcon64>.\devcon64 stack HID*
HID\VID_1462&PID_7C56\7&2319A9A&0&0000 <=== Some kinda motherboard (7C56) device ?
Name: HID-compliant device
Setup Class: {745a17a0-74d3-11d0-b6fe-00a0c90f57da} HIDClass
Controlling service:
(none)
HID\VID_046D&PID_C01A\7&2F4CFF84&0&0000 <=== My logitech USB mouse. This system has no trackpad.
Name: HID-compliant mouse
Setup Class: {4d36e96f-e325-11ce-bfc1-08002be10318} Mouse
Upper class filters:
mouclass
Controlling service:
mouhid
2 matching device(s) found.
D:\devcon32>.\devcon stack HID* <=== Maybe I'd have to try this on a Win10 32-bit installation...
Access is denied.
*******
And yes, a check on Linux is a good verification step.
In the history of computing, there have not been a lot of actual good
hardware test programs. The Sparc computer, it could have a switch on it,
to go into Test Mode, and their test program for their computer was excellent. They would test things that mattered. That comes with the computer.
I have purchased programs for other ecosystems, only to be entirely dissatisfied with the "Hello World" style crap I was given. The only testing they did, was to make "stuff" appear on the screen, with no thought to
what an actual hardware test should have. Like a snake-oil program that
tells you it "detected 8000 problems" or "fixed 8000 problems", and it
does the same thing, the next day. So so educational. I cannot recommend
the average hardware test, as this is the level of material you get.
In Linux, something like "Xev" can display what kind of event that clicking
a mouse button might produce. Taking hands off keyboard and mouse, and
just watching for your "glitch", Xev might even label what kind of event
this was... that's if hardware reproduces issue on Linux, which it won't.
This is a Windows problem.
Paul
--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)