cefsharp/CefSharp · error · DevToolsClientException

Unable to add MessageId {0} to queuedCommandResults Concurre

Error message

Unable to add MessageId {0} to queuedCommandResults ConcurrentDictionary.

What it means

Thrown by DevToolsClient when ConcurrentDictionary.TryAdd for a freshly allocated messageId returns false. Message ids come from IBrowserHost.GetNextDevToolsMessageId() which is a monotonic native counter, so a collision is essentially impossible in correct operation. The exception exists as a defensive assertion: if it fires, something has corrupted the id generator or the same client is being used concurrently in an unexpected way.

Source

Thrown at CefSharp.Core/DevTools/DevToolsClient.cs:156

                throw new ObjectDisposedException(nameof(IBrowser));
            }

            var taskCompletionSource = new TaskCompletionSource<T>(TaskCreationOptions.RunContinuationsAsynchronously);

            var methodResultContext = new DevToolsMethodResponseContext(
                type: typeof(T),
                setResult: o => taskCompletionSource.TrySetResult((T)o),
                setException: taskCompletionSource.TrySetException,
                syncContext: CaptureSyncContext ? SynchronizationContext.Current : SyncContext
            );

            var browserHost = browser.GetHost();

            var messageId = browserHost.GetNextDevToolsMessageId();

            if (!queuedCommandResults.TryAdd(messageId, methodResultContext))
            {
                throw new DevToolsClientException(string.Format("Unable to add MessageId {0} to queuedCommandResults ConcurrentDictionary.", messageId));
            }

            //Currently on CEF UI Thread we can directly execute
            if (CefThread.CurrentlyOnUiThread)
            {
                ExecuteDevToolsMethod(browserHost, messageId, method, parameters, methodResultContext);
            }
            //ExecuteDevToolsMethod can only be called on the CEF UI Thread
            else if (CefThread.CanExecuteOnUiThread)
            {
                CefThread.ExecuteOnUiThread(() =>
                {
                    ExecuteDevToolsMethod(browserHost, messageId, method, parameters, methodResultContext);
                });
            }
            else
            {
                queuedCommandResults.TryRemove(messageId, out methodResultContext);

View on GitHub (pinned to 16bc6e0711)

Solutions

  1. Confirm you are not wrapping/reusing the same DevToolsClient across multiple concurrently-disposed browsers; obtain a per-browser client via GetDevToolsClient().
  2. Check the CEF log file for native errors; update to the latest CefSharp/CEF patch release in case the id counter bug was fixed.
  3. If reproducible, capture a minimal repro and report it to the CefSharp issue tracker - this guard indicates an internal invariant violation.
  4. As a workaround, retry the DevTools call on a fresh client after disposing and recreating the browser.

Example fix

// No caller-side fix; the id is allocated internally. Retry pattern only mitigates:
async Task<T> InvokeStable<T>(IBrowser browser, string method, IDictionary<string,object> p) where T : DevToolsDomainResponseBase
{
    for (int i = 0; i < 3; i++)
    {
        try { return await browser.GetDevToolsClient().ExecuteDevToolsMethodAsync<T>(method, p); }
        catch (DevToolsClientException) when (i < 2) { await Task.Delay(50); }
    }
    throw;
}
Defensive patterns

Strategy: retry

Validate before calling

// No caller-side precondition; the id is allocated internally. Best validation is a fresh per-browser client.
var client = browser.GetDevToolsClient();

Try / catch

try { return await client.ExecuteDevToolsMethodAsync<T>(method, p); }
catch (DevToolsClientException ex) when (ex.Message.Contains("queuedCommandResults"))
{ /* retry on a fresh client or surface as internal CefSharp bug */ throw; }

Prevention

When it happens

Trigger: An integer overflow/wrap of the native message id counter; reuse of one DevToolsClient across browsers in a way that shares the counter incorrectly; a build of CEF/Chromium returning duplicate ids due to a native bug. In normal single-browser usage this is effectively unreachable.

Common situations: Should not occur in supported usage. If it does, it points to a CEF native regression or a threading bug where the same id space is shared. Almost always a sign to file a CefSharp issue rather than an application bug.

Related errors

AI-assisted analysis of cefsharp/CefSharp@16bc6e0711 (2026-08-13). Data as JSON: /api/errors/d9e1b0f01f2d9907. Report an issue: GitHub.