Repository navigation
Chromium 153 (IA2 / ChromeVBuf): RPC null context handle (WinError 1775) leads to unhandled exception and Windows PostMessage queue exhaustion (WinError 1816) #20846
Description
Brief summary
In Chromium 153, accessing dynamic single-page web applications (such as WhatsApp Web) with NVDA configured to use default IAccessible2 (allowInChromium = 0 / Default) triggers RPC null context handle errors (OSError: [WinError 1775]) and virtual buffer lookup errors. This blocks the main thread, causing background threads to exhaust the Windows PostMessage queue (10,000 message threshold) resulting in OSError: [WinError 1816] Not enough quota is available to process this command and completely freezing NVDA.
Steps to reproduce
- Ensure NVDA Advanced setting "Use UI Automation to access Chromium based browsers" is set to Default (
allowInChromium = 0/ IAccessible2). - Open a Chromium 153 browser (e.g. Brave 153.1.95.101 or Microsoft Edge 153.0.4234.32).
- Open WhatsApp Web and navigate into an active chat with long message history.
- Navigate through messages or open the Elements List dialog (
NVDA + F7).
Actual behavior
ChromeVBuffails withOSError: [WinError 1775] Bir uzaktan yordam çağrısı sırasında istemciden sunucuya boş bir bağlam işleci geçildi(RPC_X_NULL_REF_POINTER).- When attempting to populate element lists or retrieve attributes,
virtualBuffersthrowsLookupErrorat_getControlFieldAttribs. - NVDA's main thread enters freeze recovery (
watchdog.waitForFreezeRecovery). - While the main thread is blocked, background threads (synthesizer, hooks, timers) continue posting via
wx.CallAfter/core.queueRequest. - The Windows message queue exceeds the
USERPostMessageLimit(10,000 messages), triggering cascade failures ofOSError: [WinError 1816] Bu komutu işlemek için kullanılabilecek yeterli açıklama yok.inwinUser.PostMessage. - Once WinError 1816 begins, NVDA stops speaking, stops responding to keyboard input, and becomes completely unresponsive.
Setting "Use UI Automation to access Chromium based browsers" to "Yes" (allowInChromium = 2) completely bypasses the crash.
Expected behavior
NVDA should gracefully handle RPC null context handles and COM errors from Chromium IAccessible2 without freezing the main loop, and should safeguard or throttle message posting when the Windows message queue approaches the 10,000 quota limit.
NVDA logs, crash dumps and other attachments
Traceback from nvda.log:
ERROR - scriptHandler.executeScript - MainThread:
error executing script: <bound method CursorManager.script_topOfDocument of <NVDAObjects.IAccessible.chromium.ChromeVBuf object at 0x000001DB08D47A80>> with gesture 'kontrol+home'
Traceback (most recent call last):
File "scriptHandler.pyc", line 300, in executeScript
File "cursorManager.pyc", line 395, in script_topOfDocument
File "documentBase.pyc", line 81, in _get_selection
File "documentBase.pyc", line 76, in makeTextInfo
File "virtualBuffers\__init__.pyc", line 254, in __init__
File "textInfos\offsets.pyc", line 502, in __init__
File "virtualBuffers\__init__.pyc", line 259, in _getSelectionOffsets
OSError: [WinError 1775] Bir uzaktan yordam çağrısı sırasında istemciden sunucuya boş bir bağlam işleci geçildi
ERROR - unhandled exception - MainThread:
Traceback (most recent call last):
File "wx\core.pyc", line 3425, in <lambda>
File "core.pyc", line 1012, in processRequest
File "core.pyc", line 1047, in Notify
File "core.pyc", line 1004, in queueRequest
File "monkeyPatches\wxMonkeyPatches.pyc", line 26, in wx_CallAfter_wrapper
File "winUser.pyc", line 728, in PostMessage
OSError: [WinError 1816] Bu komutu işlemek için kullanılabilecek yeterli açıklama yok.
INFO - watchdog.waitForFreezeRecovery - watchdog:
Starting freeze recovery after 0.5002538999979151 seconds.
NVDA type
installed copy
NVDA version
2026.2
Have you tried any other versions of NVDA? If so, please report their behaviors.
No
Windows version
Windows 11 Version 25H2 (OS Build 26200.0)
Name and version of other software in use when reproducing the issue
Brave 153.1.95.101 (Chromium 153.0.7049.95) / Microsoft Edge 153.0.4234.32
Other information about your system
The issue started immediately after Chromium 153 was released and applied on September 10-11, 2026.
Does the issue still occur after restarting your computer?
I have restarted my computer and the issue still occurs
If NVDA add-ons are disabled, is your problem still occurring?
I have restarted NVDA with add-ons disabled and the issue still occurs
Does the issue still occur after you run the System Accessibility Repair Tool?
I have run the System Accessibility Repair Tool and the issue still occurs
Activity
selcukucar commentedon Sep 18, 2026
Hi,
I wanted to add some additional findings from my testing.
I initially experienced the issue with NVDA 2026.2 AMD64 on Windows 11 25H2 (build 26200.9457). When the problem occurs, NVDA stops speaking and eventually becomes unresponsive. Restarting NVDA normally restores speech.
The important part of the log is the repeated:
OSError: [WinError 1816] Not enough quota is available to process this command.The errors occur in several different paths, including:
virtualBuffers.changeNotifykeyboardHandler.internal_keyDownEventscriptHandler.executeScriptIAccessibleHandler.internalWinEventHandlerIUIAutomationPropertyChangedEventHandlerIn all of these cases, the error eventually occurs at:
winUser.PostMessageI also noticed that after the problem occurred, attempting to restart NVDA sometimes produced:
Couldn't terminate existing NVDA process, abandoning start: Exception: [WinError 1816] Not enough quota is available to process this command.This made me suspect that the problem is not related to speech synthesis itself, but rather to NVDA's Windows message queue becoming exhausted.
I then tested the workaround mentioned in this issue:
NVDA Settings → Advanced → "Use UI Automation to access Microsoft Edge and other Chromium-based browsers when available" → Yes
With UI Automation forced on, I have not been able to reproduce the problem so far. However, browser behavior changes somewhat when UIA is forced on.
As an additional test, I downgraded NVDA to an earlier version. Unfortunately, I encountered the same
WinError 1816there as well. This suggests that the problem may not be specific to NVDA 2026.2.One other observation: Microsoft Edge is currently on Chromium 153, while Google Chrome is still in the Chromium 152 series. I have also experienced the issue in Spotify Desktop, which is Chromium/CEF-based.
So far, the strongest pattern I have found is:
PostMessagerepeatedly fails withWinError 1816I hope these additional findings are useful. Please let me know if you need the full NVDA log or any other information from my system.
Thank you for investigating this issue.
cary-rowen commentedon Sep 19, 2026
Is there another way to reproduce this without WhatsApp? A minimal code example would be great. I'd like to see if I can help figure this out.
m-enes-senovali commentedon Sep 22, 2026
Hi Cary,
To help reproduce this issue, I created a standalone test page in this Gist that mirrors the structure of heavy SPAs like YouTube:
https://gist.github.com/m-enes-senovali/106705d36cbbe44cdd535134d58cd9a9
The test creates 1500+ DOM nodes wrapped in custom elements (Shadow DOM), performs aggressive 40ms batch node recycling (removing and appending 10 cards per tick), and runs an active Web Audio session.
Observations from testing on Chromium 153:
With allowInChromium=1 (IAccessible2 / ChromeVBuf), navigating this dynamic feed produces noticeable virtual buffer lag and sluggishness, with NVDA's watchdog logging recovery pauses:
INFO - watchdog.waitForFreezeRecovery - Starting freeze recovery after 0.500s... Recovered after 0.550s.While Chromium can still barely recover within a local single-process tab, on real-world applications like YouTube (with thousands of live DOM nodes, iframes, and active media playback), this buffer stall completely freezes NVDA's main thread during navigation or search (e.g. pressing quick find / script_findNext), rapidly exhausting the Windows USERPostMessageLimit (10,000 messages). Here is the traceback from my nvda.log when YouTube froze yesterday:
ERROR - scriptHandler.executeScript - MainThread:
error executing script: <bound method CursorManager.script_findNext of <NVDAObjects.IAccessible.chromium.ChromeVBuf object>> with gesture 'ö'
Traceback (most recent call last):
...
File "winUser.pyc", line 728, in PostMessage
OSError: [WinError 1816] Not enough quota is available to process this command
It looks like Chromium 153's IA2 bridge has performance bottlenecks or sync issues when handling high-frequency node lifecycle recycling across Shadow DOM boundaries, causing ChromeVBuf to stall under heavy load.
cary-rowen commentedon Sep 22, 2026
Hi @m-enes-senovali
Thank you very much for the detailed information, I will definitely take a look. If this is a regression in Chromium, we had better file a bug in the Chromium bug tracker.
seanbudd commentedon Oct 15, 2026
Did this get filed with chromium? Is this still an issue on chrome canary and NVDA alpha?