Can the mouse inaccuracy issue be caused by win32k.sys?

[Vocaleyes]

I stumbled upon this old post which highlights the mouse drifting issue and the reasons behind it, but this was on an older version of windows.

Looking through the threads replies, it seems that this is all due to a broken mouse movement code.

Here's the lines i'm particularly interested in;

"The mouse movement code is seriously broken in Windows XP 64-bit.

With Enhanced Pointer Precision OFF and sensitivity set to anything but 1:1 ratio, the cursor moves a lot faster in the negative directions (up & left). The cursor moves at least 1 whole pixel up or left on every update with negative mickeys, which becomes most apparent at the lowest sensitivity.

With help from the leaked Windows 2000 sources (ntos\w32\ntuser\kernel\ntinput.c for the curious) I tracked the problem down to the function GetMouseCoord in win32k.sys (the Win32 subsystem kernel driver)

The code in question takes in dx and dy values (mickeys) and scales them by a precalculated factor so that 256 means 1:1, 128 would be half speed etc:

iNumerator = dx * gMouseSensitivityFactor + idxRemainder;
dx = iNumerator / 256 ;
idxRemainder = iNumerator % 256 ;

However, the C standard doesn't completely specify integer division behavior with negative numbers. E.g. if:
Q = -2 / 5;
R = -2 % 5;
The result could be either
Q == -1 && R == 3 (rounded down) or
Q == 0 && R == -2 (rounded toward zero)
depending on the compiler's implementation, as long as the rule (*1) [ (A/B)*B + A%B = A ] holds.

So if we move 1 mickey left with sensitivity at half:
dx = -1
gMouseSensitivityFactor = 128
idxRemainder = 0

The end result should be either
dx == -1
idxRemainder == 128
or
dx == 0
idxRemainder == -128


The function GetMouseCoord remedies the inspecificity with an additional check:
if ((iNumerator < 0) && (idxRemainder > 0)) {
dx++ ;
idxRemainder -= 256 ;
}

...thus ensuring the rounding is always toward zero."

Is there anyone with the knowledge and capabilities that could check if this is still a prevalent issue in modern versions of windows, as this seems to me like the source of all of our woes...

Source: https://donewmouseaccel.blogspot.com/20 ... on_28.html

[TooManyPixels]

The mouse input code in Win32kBase.sys has changed a lot since XP. I spelunk through the code in Ghidra a lot thesedays and when I compared it to the leaked XP SP1 code, I saw the same fundamental calculations and algorithms being used, but in different places (e.g. the default acceleration curves aren’t stored in a session-space global anymore; and the definition of the MONITORINFO struct has changed wildly too.

There’s nothing incorrect or “wrong” with XP’s mouse code - nor Windows 10’s either - excepting the weird movement behaviour we’re seeing with certain hardware combinations. It’s still an area of active research - and no-one has found real a root cause or solution yet - only placebo cures.

[Vocaleyes]

I’m glad someone has browsed the code, as my understanding was that w10 was developed off XP? I may be wrong as I only read that in passing.
Reading more into that post, it’s just strange that the symptoms match exactly. Especially when the following is said.

“ With Enhanced Pointer Precision OFF and sensitivity set to anything but 1:1 ratio, the cursor moves a lot faster in the negative directions (up & left). The cursor moves at least 1 whole pixel up or left on every update with negative mickeys, which becomes most apparent at the lowest sensitivity.”

That is the exact issue I have been experiencing.

[TooManyPixels]

I’m glad someone has browsed the code, as my understanding was that w10 was developed off XP? I may be wrong as I only read that in passing.

That is correct: Windows 10 is a direct descendant of Windows XP.

(The history of Windows has a few complications around the failed Longhorn project (between XP and Vista), and how the process of combining the 9x and NT editions took a while too). But I digress.

Architectually, Windows 11 and Windows 10 are still very similar to Windows XP - and despite the major changes since XP, like the DWM and security changes in Vista, and the new process models added in WIndows 10, XP is far more similar to 10 and 11 than they're different.

With Enhanced Pointer Precision OFF and sensitivity set to anything but 1:1 ratio, the cursor moves a lot faster in the negative directions (up & left).

What you're describing certainly sounds like a problem, but it isn't exactly the same the problem that I've been experiencing, but I'll be happy to try to investigate just-in-case it shares the same root cause. DM me if you'd like to get in touch - I'll probably do a screen-share session with you and ask you to run an ETL trace and grab some data with WinDbg while you reproduce the problem (and you can reproduce the problem reliably and consistently, right?)

The cursor moves at least 1 whole pixel up or left on every update with negative mickeys, which becomes most apparent at the lowest sensitivity

Assuming you're accurately recounting the problem, then this should be straightforward to diagnose because we're now able to isolate individual components and processing steps (i.e.: individual drivers and even individual kernel-mode functions within Windows), so then it's just a matter of looking at the actual data before-and-after it goes through each component to and that tells us what is misbehaving - then we can hopefully identify the root-cause.

And yes, it _really is that simple_ - but the reason why I haven't been able to pin anything down yet is because none of my computers consistently reproduce the problem - furthermore, you need a way to reproduce the physical mouse movements identically in order to do a meaningful comparison of the data, and doing that right is surprisingly difficult and seems like an impossibility for a human test subject - you'd need a USB peripheral that can re-play a USB HID input back identically to how the mouse did, right down to the sub-millisecond level, and that's a hard problem.

(No, you can't fake it by calling the Win32 API's SendInput or SendMessage functions: mouse messages sent that way go through a completely different code-path that never goes through Windows' acceleration logic in Win32k.sys).

[Vocaleyes]

Sounds like a plan, and yes I can consistently replicate this issue 100/100 times.

My timezone is GMT so let me know whenever you’re available and we’ll get to work!

[TooManyPixels]

Sounds like a plan, and yes I can consistently replicate this issue 100/100 times.

My timezone is GMT so let me know whenever you’re available and we’ll get to work!

In order to do this properly, we'll need to re-play USB input messages - I've written an Arduino program that does this (and I'm always tweaking and improving it too) - so the only thing you need to do is get your own Arduino board that you can load my program into and run it (while you'd then run another couple of programs on your computer to collect the data that the Arduino generated).

(Okay, technically it's not an Ardunio, but actually a SparkFun Pro Micro C - it needs to be that specific model because normal Arduinos don't have the necessary hardware to allow them to act as a USB input device - but these do - fortunately they're cheap-as-chips, only $20: https://www.sparkfun.com/products/15795 - though you'll also need a $4 button to trigger it ( https://www.sparkfun.com/products/15932 ) - and a $1.50 cable ( https://www.sparkfun.com/products/14427 ) - and you'll also need a USB-C cable, but I assume you already have a bunch of those already.

So assuming you're okay with dropping $26 in the name of science, then lemme know when the kit arrives at your place and I can send you the program to run and to tell you how to run an ETL trace.

...I'm also very aware that all this sounds exactly like how an online-bank-password-stealing scam would go, lol - but at least the programs are all in source-code form so you can tweak/edit/improve/ruin it at your pleasure.

-----------------

Also, if you're interested in helping out further - and if you have at least two computers with exposed USB 3.0 Debug-capable ports (see
https://www.kernel.org/doc/html/v4.14/d ... -port.html) - and if you're okay with buying a $7 "A-to-A" USB-Debug-cable (https://www.amazon.com/SIIG-SuperSpeed- ... ANCBO?th=1) then it'd help my research if you could set-up a machine-to-machine WinDbg session, so we can see the actual internal values deep within WIndows' Win32k.sys in real-time.

[Vocaleyes]

Sounds like a plan, and yes I can consistently replicate this issue 100/100 times.

My timezone is GMT so let me know whenever you’re available and we’ll get to work!

In order to do this properly, we'll need to re-play USB input messages - I've written an Arduino program that does this (and I'm always tweaking and improving it too) - so the only thing you need to do is get your own Arduino board that you can load my program into and run it (while you'd then run another couple of programs on your computer to collect the data that the Arduino generated).

(Okay, technically it's not an Ardunio, but actually a SparkFun Pro Micro C - it needs to be that specific model because normal Arduinos don't have the necessary hardware to allow them to act as a USB input device - but these do - fortunately they're cheap-as-chips, only $20: https://www.sparkfun.com/products/15795 - though you'll also need a $4 button to trigger it ( https://www.sparkfun.com/products/15932 ) - and a $1.50 cable ( https://www.sparkfun.com/products/14427 ) - and you'll also need a USB-C cable, but I assume you already have a bunch of those already.

So assuming you're okay with dropping $26 in the name of science, then lemme know when the kit arrives at your place and I can send you the program to run and to tell you how to run an ETL trace.

...I'm also very aware that all this sounds exactly like how an online-bank-password-stealing scam would go, lol - but at least the programs are all in source-code form so you can tweak/edit/improve/ruin it at your pleasure.

-----------------

Also, if you're interested in helping out further - and if you have at least two computers with exposed USB 3.0 Debug-capable ports (see
https://www.kernel.org/doc/html/v4.14/d ... -port.html) - and if you're okay with buying a $7 "A-to-A" USB-Debug-cable (https://www.amazon.com/SIIG-SuperSpeed- ... ANCBO?th=1) then it'd help my research if you could set-up a machine-to-machine WinDbg session, so we can see the actual internal values deep within WIndows' Win32k.sys in real-time.

I've no problem spending money if it helps resolve this issue once and for all, as let's face it, none of us are getting any younger and soon the expected decline in cognitive function and co-ordination will begin creeping in.

"...I'm also very aware that all this sounds exactly like how an online-bank-password-stealing scam would go, lol - but at least the programs are all in source-code form so you can tweak/edit/improve/ruin it at your pleasure."
This can be tested on my end with a formatted and completely fresh install of windows, so there won't be much risk to myself.

I'd like to double check that all the components you suggested are compatible with my build before ordering if that's ok? Also what did you name your program if you're happy to divulge that info?

But nonetheless, there is very little out there in terms of similarity to the issue I've been experiencing for several years, and seeing as how these new OS builds are heavily based off of XP, I wouldn't count out this issue being completely forgotten about and transferred to a majority of modern systems. Then if it does happen to be the case, we can clearly see how the issue operates, i.e. is the issue on ALL configs, or if it's hardware/ software dependent for e.g. 22H2 vs 23H2 etc.

I appreciate the help, specs are as follows;

MSI z390-A pro,
i9900kf 3.6,
4070ti windforce OC,
1 x toshiba nvme 500gb (yoinked from another system)
1 x sata samsung evo 860 500gb,
4 x 8gb corsair vengeance RGB pro 3600mhz.

I checked the link you sent but all seemed to be out of stock, possibly due to international limitations, luckily I found a local vendor with the same (i think) hardware, as attached.

[Vocaleyes]

Awaiting further instruction.

[TooManyPixels]

Awaiting further instruction.

Heya,

Did the parts arrive already? If so, that was quick.

Are you on Slack, Teams, Signal, Telegram (anything except WhatsApp)? Methinks it'd be easier to chat in real-time (and feel free to post any chalogs we have to here if you feel we discussed anything worth getting more eyes on)

[Vocaleyes]

Awaiting further instruction.

Heya,

Did the parts arrive already? If so, that was quick.

Are you on Slack, Teams, Signal, Telegram (anything except WhatsApp)? Methinks it'd be easier to chat in real-time (and feel free to post any chalogs we have to here if you feel we discussed anything worth getting more eyes on)

Hi,

I haven't ordered the parts, please refer to my prior reply as before I order anything I had multiple questions. Once those have been answered I'll be happy to purchase. Thanks.