Desktop app: UI thread hangs (AppHangB1) and Windows force-closes github.exe after repeated browser canvas use

從 github_app::browser_preview 日誌和回報的 browser tool 逾時開始，接著追蹤失效的本機連接埠、WebView2 執行個體和暫存設定檔清理是如何處理的。判斷哪個操作可能會阻塞 UI thread，以及重複使用的 preview instance IDs 是否會留下程序或設定檔。完成的標準是：失效或無回應的 preview 能夠獨立失敗，同時桌面應用程式仍保持回應，且卡住的情境可以重現，或其原因已被隔離。

Describe the bug

The GitHub Copilot desktop app (github.exe 1.1.21.0) stopped responding and was force-closed by Windows. The evidence points at the browser preview / WebView2 subsystem blocking the UI thread, after repeatedly opening, navigating and reading browser canvases pointed at local HTTP servers.

This is a hang, not a crash — no access violation, no panic. Windows recorded:

Application Hang (Event ID 1002)
  The program github.exe version 1.1.21.0 stopped interacting with Windows and was closed.

Windows Error Reporting (Event ID 1001)
  Event Name:      AppHangB1
  P1: github.exe
  P2: 1.1.21.0
  P3: 6aa8d523
  Hang Signature:  6db1
  Hang Type:       134217728  (0x8000000)
  IsFatal:         1

The Rust backend was healthy right up to the moment it was killed. ~/.copilot/logs/github-app.<pid>.log (40 MB) ends ~5 seconds before the force-close, mid-way through entirely routine traffic:

11:18:33.703  DEBUG ws_handle_client_message kind="get_workspace_changes"
11:18:33.908  INFO  github_api_external_created_pr_lookup
11:18:33.909  DEBUG ...

No error, no panic, and no shutdown sequence — consistent with the process being killed from outside while the backend was still working normally. That pattern points at the UI thread specifically rather than at the backend.

Affected version

GitHub Copilot app 1.1.21.0 (build 2026/09/15:05:18:27!15938018)
Bundled CLI: copilot 0.0.395 (commit 4b4fe6e)

Steps to reproduce the behavior

Not reduced to a reliable repro, but the conditions present were:

1. Open several browser canvases pointed at local servers (http://127.0.0.1:<port>/) started by a canvas extension.
2. Repeatedly navigate_page / read_page / re-open_canvas against the same instance ids, with ~6 webviews live simultaneously.
3. Reload the extension host, which replaces those local servers — the previously-opened canvases are now pointed at dead ports.
4. Continue reading/navigating those canvases. Browser tool calls begin timing out.
5. Shortly afterwards the UI stops responding entirely and Windows force-closes the app.

Step 3→4 (driving a browser canvas whose target port is no longer listening) looks like the most suspicious ingredient, since that is exactly when the failures started appearing.

Expected behavior

A browser preview pointed at a dead or unresponsive local port should fail that individual tool call and leave the application responsive. No preview operation should be able to block the UI thread to the point that Windows declares the process hung.

Additional context

Repeated profile cleanup failures preceded the hang:

Signal	Count
WARN github_app::browser_preview: Failed to remove browser preview ephemeral profile directory	15
Orphaned profile dirs left in %TEMP%\github-app-browser-previews	3
Browser tool request timed out (in the ~2 min before the hang)	2
Webview ... was not found	1

The repeated cleanup failures suggest WebView2 processes lingering and holding file locks on their profile directories. A blocking WebView2/COM call on the UI thread would fit hang type 0x8000000 and matches the observed ordering: browser tool calls time out → a webview goes missing → UI stops responding.

Ruled out — websocket message volume. I checked whether a message storm was responsible. subscribe_workspace_changes per minute: 93 at 11:06, 66 at 11:09, 28 at 11:15, 17 at 11:16, and 26 in the final minute. Traffic at the end was below the earlier peak, so volume was not the trigger.

Ruled out — the canvas extension in use. A locally-developed canvas extension was under active development at the time, but it was not involved: every extension host reached === ready === with no exception, the host in use had no exit line at all (still running when the app died), it runs out-of-process under Node and cannot block the app's UI thread directly, and its one newly-added privileged code path was never invoked (zero log hits).

Not memory exhaustion. 13.7 GB free of 55.7 GB at the time. There was general pressure on the machine (Memory Compression at 4.8 GB, an unrelated WSL VM at 16 GB), but the app was not starved.

Suggested mitigations:

• Bound browser preview tool calls with a timeout that cannot block the UI thread.
• Tear down the WebView2 process and its ephemeral profile deterministically when a preview is replaced or its instance id is reused, rather than leaving both to a cleanup that is observably failing.
• Treat repeated Failed to remove browser preview ephemeral profile directory as a signal to stop reusing the profile root.

Diagnostic artifacts available on request: the WER report (AppHang_github.exe_...), and the 40 MB backend log covering the hang.

Environment:

• OS: Windows 11 Enterprise 10.0.26200
• CPU architecture: AMD64
• Memory: 55.7 GB total, 13.7 GB free at time of analysis