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 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

triage-needed
主要言語
TypeScript
スター
181
フォーク
126
平均マージ
2日 3時間
マージ済み PR(30日)
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. リポジトリをフォークし、ブランチを切って変更します。
  4. 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 を短くまとめたダイジェスト。