#3899 Crash in Qt accessibility path (x64gui+0xBD90C / x32gui+0xA40E2)

Operating System

Windows 11 Home China x64.

Local system information:

Get-CimInstance Win32_OperatingSystem reports Version=10.0.26200, BuildNumber=26200.
Windows Error Reporting dynamic signature reports OS Version=10.0.26200.2.
WER OsInfo[29] reports 10.0.26100.8655.amd64fre.ge_release.240331-1435.
Locale ID: 2052.

x64dbg Version

snapshot_2026-05-27_12-11, file version 0.0.2.5.

Matching symbols package symbols-snapshot_2026-05-27_12-11.zip has commithash.txt:

9c8ca1cae0b6d56cc44f31fddcb10e3b02ffbb87

Describe the issue

x64dbg repeatedly crashes in the GUI module with an access violation. The crash happens in the x64 GUI build, and a similar crash was also observed in the x32 GUI build.

Latest x64 WER crash signature:

Faulting application: x64dbg.exe
Application version: 0.0.2.5
Application timestamp: 0x6a16df14
Faulting module: x64gui.dll
Faulting module timestamp: 0x6a16df0f
Exception code: 0xc0000005
Exception offset: 0x00000000000bd90c

Latest x32 WER crash signature:

Faulting application: x32dbg.exe
Application version: 0.0.2.5
Application timestamp: 0x6a16de99
Faulting module: x32gui.dll
Faulting module timestamp: 0x6a16de97
Exception code: 0xc0000005
Exception offset: 0x000a40e2

Both reports loaded Windows accessibility / UI automation modules:

Oleacc.dll
UIAutomationCore.dll

The x64 crash report also had plugins\ScyllaHideX64DBGPlugin.dp64 loaded, but the x32 crash report did not load ScyllaHide and still crashed in x32gui.dll, so ScyllaHide does not appear to be required to hit this crash.

I downloaded the matching symbols package and checked the code around both offsets. The x64 and x32 crashes appear to be in the same Qt accessibility update path.

At x64gui.dll+0xBD90C, the nearby imports/calls include:

QAccessible::isActive()
QAccessible::queryAccessibleInterface(QObject*)
QAccessibleValueChangeEvent::QAccessibleValueChangeEvent(QAccessibleInterface*, QVariant const&)
QAccessible::updateAccessibility(QAccessibleEvent*)

The immediate x64 crash point is an unchecked dereference after an accessibility interface lookup / virtual call:

call    QAccessible::queryAccessibleInterface(QObject*)
...
call    qword ptr [rax+40h]
mov     rsi, rax
mov     rcx, qword ptr [rax]   ; AV at x64gui.dll+0xBD90C when rax is invalid/null

The x32 crash at x32gui.dll+0xA40E2 follows the analogous path:

call    QAccessible::isActive
call    QAccessible::queryAccessibleInterface(QObject*)
...
mov     ecx, ebx
mov     edx, dword ptr [ebx]   ; AV at x32gui.dll+0xA40E2 when ebx is invalid/null

This looks like an x64dbg GUI accessibility bug triggered when Windows UI Automation / accessibility clients query the UI. The expected behavior would be that accessibility notifications do not crash even if queryAccessibleInterface or a child interface lookup returns null/invalid.

Steps to reproduce

I do not have a minimal deterministic repro yet, but this is the observed environment and behavior:

Run snapshot_2026-05-27_12-11 on the Windows 11 system described above.
Launch x64dbg or x32dbg and use it normally. No obvious screen reader is running, but WER shows Oleacc.dll and UIAutomationCore.dll loaded at crash time.
x64dbg eventually crashes by itself with the WER signature above. x32dbg has also crashed in the analogous GUI/accessibility path.

Attachments

No dump is available right now. I can provide the full WER report text if useful. The key WER fields and offset analysis are included above.