Native Windows capture fails on Windows 10 22H2: CreateForMonitor returns E_ACCESSDENIED (0x80070005)

Copy the whole of this file into the GitHub issue body. Attach wgc-capture-error-dialog.png (in this folder) as the screenshot.

Summary

On a stock Windows 10 Pro 22H2 (build 19045.6466) machine, recording never starts: the native capture helper reports it cannot create a WGC capture item for the selected monitor. Every attempt to record ends with the dialog in the attached screenshot.

Error: WARNING: Could not opt out of power throttling (error 87)
{"event":"ready","schemaVersion":2} ERROR: CreateForMonitor failed (hr=0x80070005)
ERROR: Failed to initialize WGC display session

The machine is well above the documented minimum requirements, and other Chromium-based software on it captures the screen without any problem, so I do not think this is a hardware or OS-capability limitation. I could not find any policy, privacy setting, remote session or display driver on this machine that would explain the refusal — details of what I ruled out are below, in case it saves you time.

Environment

So Chromium's sandbox appears unable to initialise for the Electron main process on this machine, while Chromium 155 in Chrome/Edge is unaffected. I am reporting it because it may be the same underlying condition, and because the silent exit 0 with no diagnostic output made the original problem very hard to see. Happy to run whatever collection steps you want (Procmon, WER dumps, sandbox logs) if it helps.

Workaround I tried

is-native-windows-capture-available returns missing-helper when the helper file is absent (electron/ipc/handlers.ts:2457-2466), and the renderer then falls through to Chromium's own getDisplayMedia pipeline (src/hooks/useScreenRecorder.ts:1227-1230, then :1849-1861). Renaming resources/electron/native/bin/win32-x64/wgc-capture.exe therefore switches the app onto the browser pipeline by design. On this machine that still did not produce a usable recording, so I am not offering it as a fix — only as evidence that the app's own fallback routing behaves as documented.

Ask

1. Is there any additional diagnostic the helper could print at the point CreateForMonitor fails (the HMONITOR value, the monitor rect, the process token/integrity, GraphicsCaptureSession::IsSupported())? Right now E_ACCESSDENIED is the only signal, and nothing in the app logs distinguishes "monitor rejected" from "capture refused for this process".
2. Would you consider reporting CreateForMonitor failure as missing-helper-style unavailable (falling through to browser capture with a warning) rather than throwing and blocking the recording entirely? On a machine like this one the browser pipeline is the only path that could still work.
3. If it is useful, I can collect full WER dumps or a Procmon trace around the CreateForMonitor call.

Note on the build used for these logs: it is OpenScreen 2.0.0 built from the v2.0.0 tag, with one upstream post-2.0.0 Windows fix ported in (the CONTENT_PROTECTION_BREAKS_CLICK_THROUGH gate from electron/windows.ts, needed because 2.0.0's click-through HUD is unusable on Windows 10). wgc-capture.exe, compositor_view.node and every other native binary are taken unmodified from the official Openscreen.Setup.2.0.0.exe payload — so the capture failure above is produced by your shipped helper, not by anything I changed. The screenshot and the two logs in this report were produced by that build running on the machine described.