microsoft / microsoft/vscode-python-debugger

Attach process picker still hangs without WMIC because windows-process-tree loader misses node_modules.asar

未關閉
#1,095 1 則留言 1 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

triage-needed
主要語言
TypeScript
星號
181
分支
126
平均合併
2 天 3 小時
30 天內合併 PR
3

描述

Environment

  • Python Debugger: 2026.7.12401012 (pre-release)
  • VS Code: 1.135.0 (08d4889f9ec4a1685d257b9b95de036c8e1ce1e5, x64)
  • OS: Windows 11 Pro x64, 10.0.26200
  • WMIC: not installed

Reproduction

Use the generated attach configuration:

{
    "name": "Python Debugger: Attach using Process Id",
    "type": "debugpy",
    "request": "attach",
    "processId": "${command:pickProcess}"
}

Start debugging and wait for the process picker.

Expected behavior

A Quick Pick containing the running processes is displayed.

Actual behavior

The progress indicator keeps running, but the process picker never appears. The extension host log contains:

Error: spawn wmic ENOENT
    at ChildProcess._handle.onexit (node:internal/child_process:287:19)
    at onErrorNT (node:internal/child_process:508:16)
    at process.processTicksAndRejections (node:internal/process/task_queues:90:21)

Using a literal PID works.

Cause found locally

The current implementation added in #1030 loads the native module from this path:

const wpcPath = path.join(env.appRoot, 'node_modules', '@vscode', 'windows-process-tree');
const nodeRequire = eval('require') as NodeJS.Require;
return nodeRequire(wpcPath);

In the packaged VS Code 1.135.0 installation, @vscode/windows-process-tree is not present under the physical node_modules directory. It is packaged at:

<env.appRoot>/node_modules.asar/@vscode/windows-process-tree

with its native files under node_modules.asar.unpacked.

Loading both paths with VS Code's Electron/Node runtime produces:

<env.appRoot>/node_modules/@vscode/windows-process-tree
  -> MODULE_NOT_FOUND

<env.appRoot>/node_modules.asar/@vscode/windows-process-tree
  -> loads successfully
  -> exports ProcessDataFlag, getAllProcesses, getProcessList, etc.

The native loader exception is swallowed by the broad catch, so the provider silently falls back to WMIC. WMIC is no longer installed by default on current Windows builds, and that second failure leaves the picker waiting indefinitely.

Suggested direction

  • Resolve the packaged ASAR location as well as development/older layouts.
  • Avoid falling back exclusively to deprecated WMIC; PowerShell/CIM could provide a non-native fallback.
  • Log the original windows-process-tree loading exception so this failure mode is visible.

Related: #744, #867, #899, #991, #1030.

貢獻指南

開啟貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

研究方向

從建構 @vscode/windows-process-tree 路徑的 process-picker loader 開始,追蹤其寬泛的 catch 如何選擇 WMIC。使用 node_modules.asar 和 node_modules.asar.unpacked 重現封裝後的配置,然後驗證無需 WMIC 即可進行程序列舉,且載入失敗仍會顯示在 extension host log 中。

由索引模型根據 Issue 內容生成。

評估

技術堆疊
node.js, typescript
領域
devtools
Issue 類型
缺陷
難度
4/5
預估耗時
3-5 天
活躍度
活躍
描述清晰度
基本清楚
新手友好度
58/100

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。