Logitech mouse scrolling causes exception

[jobrow-msft]

Hi, we've had multiple customers using a Logitech mouse report crashes lately with this stack:

OverflowException: Arithmetic operation resulted in an overflow.
   at System.Windows.Shell.WindowChromeWorker._HandleNCHitTest(WM uMsg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at System.Windows.Shell.WindowChromeWorker._WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)

It sounds like it is a Logitech driver bug that isn't well handled by .NET.
https://stackoverflow.com/questions/50282355/why-does-my-wpf-application-crash-when-i-bump-my-mousewheel
https://developercommunity.visualstudio.com/t/overflow-exception-in-windowchrome/167357

“WPF applications which are built for x64 and use the WindowChrome class throw an OverflowException when receiving a horizontal scroll command from a Logitech mouse configured with SetPoint.”
“It seems like a bad assumption is made in Standard.Utility that lParams always fit in 32 bits, and some mouse drivers violate that on 64-bit systems by writing there.”

The developer community issue was closed long ago, but we recently updated to .NET 6 and started getting customer reports (although we have not been able to determine how to repro it locally). The developer community post has a suggested workaround, but it's a fairly ugly workaround to add so we'd like to see about getting a fix in .NET.

Thanks!

[hoyosjs]

@jobrow-msft This feels like a dupe of #6777 which was fixed in #6779. This means that this is only available in the 8.0 previews. I leave it up to the maintainers of WPF to assess risk of a backport to .NET 6 and 7.

[jobrow-msft]

@hoyosjs good to know, thanks! Is there anyone specific we should discuss it with for getting a fix ported back?

[hoyosjs]

I am not very familiar with the process for WPF, but perhaps @pchaurasia14 or @dipeshmsft could help here.

[singhashish-wpf]

@jobrow-msft could you please confirm if the latest .NET8 preview is fixing this for you. If yes, we can discuss the risk and then port it back to .NET6 and 7.

[jobrow-msft]

@singhashish-wpf we haven't been able to repro locally (we don't have specific steps from customers, just that it happens while scrolling). Do you have a repro that was used to implement the fix in the .NET8 preview? I would assume that whoever fixed it verified it in the preview?

Is the suggestion here (https://developercommunity.visualstudio.com/t/overflow-exception-in-windowchrome/167357) overriding OnSourceInitialized the suggested workaround in the meantime, or is there any other workaround? Thanks!

[jobrow-msft]

Bumping this - we're hesitant to implement such a targeted workaround so we're wondering if that is the suggested approach, if there is any other workaround, or if this will be ported back at any point. Thanks!

[lindexi]

@jobrow-msft Can I know it be fixed in the .NET8 preview?

[miloush]

@lindexi your fix seems to already be in current .NET 8 previews

@jobrow-msft it looks like your options are either upgrade to .NET 8, stop using WindowChrome or go with a targeted workaround. You can probably do better than catching an exception though.

I might be wrong but I doubt the fix was tested with actual hardware. You could probably test it by sending a message to the window.

@singhashish-wpf I think this is safe to backport and I would support doing so. All values that worked before remain unchanged and those that were throwing will now work. Since the X and Y values are shorts, no new values can be returned from the API that couldn't be returned before.

[jobrow-msft]

Thanks @miloush, I appreciate it. We'll discuss our options to decide how to deal with it. If it were ported back, is there a bug we could use to track when that happens?

[lindexi]

@jobrow-msft After the release of dotnet 8, it seems that this issue has been fixed. Can we close this issues?

[thejonathanbrown]

Sounds like a "won't backport" result? In the months since filing this we've had many people report this issue, so even if we update to .NET 8 it might be worth backporting for other apps that aren't in a position to update .NET. Maybe you have telemetry to inform that, but anyhow, sure it can be closed