Почему происходит сбой моего приложения WPF при ударе колесом мыши?

Question

Когда я сталкиваюсь с колесом мыши, мое приложение WPF иногда завершается с ошибкой OverflowException.Вот начало трассировки стека:

at System.Windows.Shell.WindowChromeWorker._HandleNCHitTest(WM uMsg, IntPtr wParam, IntPtr lParam, Boolean& handled)

После этого я отследил его до WindowChrome - я могу даже воспроизвести его только с помощью WindowChrome.Но похоже, что оно должно быть полноэкранным.Что тут происходит?Есть ли обходной путь?

Answer 1

На самом деле это проблема в классе, на который указывает трассировка стека. В Microsoft есть ошибка в WindowChromeWorker, которая проявляется в OverflowException.

Я наблюдал это только у мышей Logitech, но из того, что я видел в других местах, это может случиться с другими мышами.

Единственные доступные обходные пути - запрещение полноэкранного режима и запрет на отправку пользователем сообщения, содержащего информацию о боковой прокрутке.

То, что я думаю, происходит так:

//Overflow gets inlined to here. (In System.Windows.Shell.WindowChromeWorker.cs)
var mousePosScreen = new Point(Utility.GET_X_LPARAM(lParam), Utility.GET_Y_LPARAM(lParam));

//Which calls this (In Standard.Utility)
public static int GET_X_LPARAM(IntPtr lParam)
{
    return LOWORD(lParam.ToInt32());
}

//Unsafe cast and overflow happens here (In System.IntPtr)
public unsafe int ToInt32() {
    #if WIN32
        return (int)m_value;
    #else
        long l = (long)m_value;
        return checked((int)l); //Overflow actually occurs and is thrown from here.
    #endif
}

Кажется, что в Standard.Utility делается неверное предположение, что lParam всегда умещаются в 32 битах, и некоторые драйверы мыши нарушают это в 64-битных системах, записывая их там.

Исходным источником для WindowChromeWorker является здесь .