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 摘要。