Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#1,247 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
22/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
electron, typescript
Domaine
desktop

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
TypeScript
Étoiles
3.7k
Forks
231
Merge moyen
16 h 38 min
PR mergées (30 j)
327

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de getopenscreen/openscreen

Toutes les issues de getopenscreen/openscreen

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.