Win10, since long time (and maybe a bit related to this topic): In fact, the current drivers don’t even have the custom control panel extension! In the time since I originally did this investigation, it appears that people finally got their act together and upgraded their video drivers, because there has been only one recorded occurrence of this crash worldwide in the past 30 days.īonus reading: The difference between a junior and senior position at a video card company. It turns out that all the machines that are hitting this bug are running drivers that are over ten years old. Patch the second byte from 63 to 8b: // rbx = (LONG_PTR)g_originalWndProcĤ88b1d33540300 mov rbx,qword ptr rbx = (LONG)g_originalWndProcĤ8631d33540300 movsxd rbx,dword ptr I went for style points and came up with a one-byte patch to fix the bug. When porting to 64-bit, the SetWindowLong becomes SetWindowLongPtr to expand the value to 64 bits, and the name of the index changes from GWL_ WNDPROC to GWLP_ WNDPROC, with the extra P emphasizing that the value should be passed to Get/ SetWindowLongPtr.īut they forgot to upgrade their cast from (LONG) to (LONG_PTR), so they were accidentally truncating their 64-bit value to a sign-extended 32-bit value as part of the restoration. I suspect this code was originally written as 32-bit code, and the line was SetWindowLong(GetDlgItem(m_dlg, IDC_SOME_BUTTON), SetWindowLongPtr(GetDlgItem(m_dlg, IDC_SOME_BUTTON), Return self ? self->RealDialogProc(hdlg, uMsg, wParam, lParam)Īnd here is the “real” DLGPROC: INT_PTR CALLBACK M圜lass:RealDialogProc( M圜lass* self = (M圜lass*)GetWindowLongPtr( HWND hdlg, UINT uMsg, WPARAM wParam, LPARAM lParam) Here is the reverse-engineered dialog procedure: INT_PTR CALLBACK DialogProc( The custom property sheet that comes with one particular video card has a bug in its WM_ DESTROY handler: It casts a WNDPROC to a 32-bit value, causing the upper 32 bits to be lost. Since this was a Display control panel, I focused on the video card information, since video card drivers can provide a custom Display control panel plug-in to show off their driver-specific features. To debug this problem, I had to do some triangulation of the crash dumps to look for a third party component that was common to all (or at least most) of the crashes. Not everybody who uses a computer speaks English. It’s (checks watch) 2023, get with the program. Bonus insult: Their button is ANSI, not Unicode. This tells me that somebody subclassed a button, and then tried to restore the original window procedure, but they messed up and truncated the 64-bit pointer value to a 32-bit signed integer. Close study shows that this value is suspiciously similar to 00007fff`924bbde0, which is the address of ntdll!ButtonWndProc_A. For example, in one dump, it was at address ffffffff`924bbde0. The crash was due to the instruction pointer being in the middle of nowhere. Since these crashes are coming via telemetry and the Windows Error Reporting service, there is no information about what steps are required to reproduce the problem. Windows reliability telemetry reported that there were a large number of crashes in the Display control panel.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |