Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
  • 哪里不对？
#1,247 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
22/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
electron, typescript
领域
desktop

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
TypeScript
星标
3.7k
派生
231
平均合并
16 小时 25 分钟
30 天内合并 PR
331

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

getopenscreen/openscreen 的其他 Issue

查看 getopenscreen/openscreen 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。