dotnet/wpf · error · Win32Exception

The operation completed successfully.

Error message

The operation completed successfully.

What it means

Dispatcher throws Win32Exception when a Win32 API call it made returns -1, meaning the underlying OS call failed. The exception has no specific error code set by this code path, so the default message 'The operation completed successfully.' appears because Win32Exception formats HRESULT/Win32 error 0 (S_OK) when no error code is provided. This makes the message misleading - the operation actually failed at the Win32 level.

Solutions

  1. Inspect the inner state/logs of the failing Win32 call; if possible, capture GetLastError immediately at the failure point via diagnostics or a debugger
  2. Ensure the app is running in an interactive desktop session with a valid message queue (not a service without a desktop)
  3. Check for handle/GDI object leaks that exhaust window-station resources
  4. Update .NET/WPF to the latest patch - several Dispatcher Win32 interop failure modes have been fixed

Example fix

// before
if (intResult == -1)
{
    throw new Win32Exception();
}
// after
if (intResult == -1)
{
    int error = Marshal.GetLastWin32Error();
    throw new Win32Exception(error, $"Win32 call failed with error {error}");
}
Defensive patterns

Strategy: try-catch

Validate before calling

// No pre-call validation possible; ensure an interactive desktop session
bool hasDesktop = Environment.UserInteractive;

Try / catch

try
{
    dispatcher.Invoke(() => work());
}
catch (Win32Exception ex)
{
    logger.LogError(ex, "Dispatcher Win32 call failed (error {Code})", ex.ErrorCode);
    // surface a retry or fallback UI path
}

Prevention

When it happens

Trigger: A Win32 API invoked by Dispatcher (with an out int result) returns -1, e.g. during message-pump or timer-related native interop in the WndProc/dispatch pipeline; the code then throws new Win32Exception() with no error code.

Common situations: Native OS resource exhaustion (e.g. too many window handles), running in unusual desktop/session contexts (services, session 0), or OS-level failures during window message processing in WPF apps.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

AI-assisted analysis of dotnet/wpf@81131a70a4 (2026-09-14). Data as JSON: /api/errors/71876311df402148. Report an issue: GitHub.

Appendix: source

Thrown at src/Microsoft.DotNet.Wpf/src/WindowsBase/System/Windows/Threading/Dispatcher.cs:2129

                    result = UnsafeNativeMethods.GetMessageW(ref msg,
                                                             new HandleRef(this, hwnd),
                                                             minMessage,
                                                             maxMessage);
                }
                else
                {
                    int intResult;

                    messagePump.GetMessageW(
                        ref msg,
                        hwnd,
                        minMessage,
                        maxMessage,
                        out intResult);

                    if (intResult == -1)
                    {
                        throw new Win32Exception();
                    }
                    else if (intResult == 0)
                    {
                        result = false;
                    }
                    else
                    {
                        result = true;
                    }
                }
            }
            finally
            {
                if (messagePump != null) Marshal.ReleaseComObject(messagePump);
            }

            return result;
        }

View on GitHub (pinned to 81131a70a4)