Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

record: native WGC capture fails on Windows 10 22H2 — CreateForMonitor returns E_ACCESSDENIED (0x80070005)

Abierto
  • ¿Algo no está bien?
#1,247 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
22/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
electron, typescript
Área
desktop

Línea de trabajo

Start at the fallback routing in electron/ipc/handlers.ts (around lines 2457-2466, where a missing helper returns missing-helper) and the renderer branches in src/hooks/useScreenRecorder.ts (around lines 1227-1230 and 1849-1861). The failure itself is inside the closed-source-to-you native wgc-capture.exe, which the reporter cannot be expected to debug from the repo. Done would mean a clearly reasoned decision on whether a CreateForMonitor failure should fall back to browser capture with a warning, which needs maintainer input first.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

   
OpenScreen 2.0.0 (Windows x64; native binaries are byte-identical to the official installer — see note at the end)
Electron 41.2.1 (bundled)
OS Windows 10 Pro 22H2, build 19045.6466
CPU 12th Gen Intel Core i7-12700K (SSE3, SSE4.1, SSE4.2, AVX, AVX2, AVX512F all present)
GPU NVIDIA GeForce RTX 3060, driver 32.0.16.1656 (2026-08-20)
Displays 2 × AOC2402, extended desktop; the failing source is the secondary display at physical origin x=2560 (2560×1440 @ 125%)
Session SESSIONNAME=Console, local interactive; not RDP; OpenInputDesktop succeeds
Chrome / Edge 155.0.8059.41 / 155.0.4283.45 — both run and capture normally on this machine
Virtual display drivers none (single NVIDIA adapter)
Virtualisation none (ASUS/AMI BIOS, physical machine)
Third-party AV/security none installed; Microsoft Defender running with default settings

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.
Image

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.

Lenguaje dominante
TypeScript
Estrellas
3.7k
Forks
231
Merge medio
16 h 38 min
PR fusionados (30 d)
327

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de getopenscreen/openscreen

Todos los issues de getopenscreen/openscreen

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.