Skip to content

Due to wmic has been deprecated. Use @vscode/windows-process-tree for Windows process listing with WMIC fallback#991

Open
ZA139 wants to merge 4 commits intomicrosoft:mainfrom
ZA139:trunk
Open

Due to wmic has been deprecated. Use @vscode/windows-process-tree for Windows process listing with WMIC fallback#991
ZA139 wants to merge 4 commits intomicrosoft:mainfrom
ZA139:trunk

Conversation

@ZA139
Copy link
Copy Markdown

@ZA139 ZA139 commented Mar 30, 2026

Following up on #858, which replaced WMIC with PowerShell for process listing, this PR takes a different approach by using the native @vscode/windows-process-tree module (getAllProcesses) to enumerate processes on Windows. This avoids spawning external commands entirely and provides better performance.

Changes:

  • Use @vscode/windows-process-tree (getAllProcesses with ProcessDataFlag.CommandLine) as the primary method for listing processes on Windows.
  • When windows-process-tree is unavailable or fails (e.g. native module load failure), fall back to the existing WMIC parser to maintain backward compatibility on older Windows versions.
  • Wrap getAllProcesses in a manual Promise instead of util.promisify, since the library's callback signature (callback, flags?) does not follow the Node.js (err, result) convention.
  • Add @vscode/windows-process-tree as a dependency and configure it as a webpack external (native module).
  • macOS/Linux process listing remains unchanged (ps-based).

Test changes:

  • Add unit tests for the getAllProcesses happy path on Windows.
  • Add unit tests for the WMIC fallback when getAllProcesses throws.
  • Add getAttachItems sorting and Python-process-priority tests for both paths.

No feature changed. This is an internal improvement to process enumeration reliability on Windows.

ZA139 and others added 4 commits March 24, 2026 19:58
Add @vscode/windows-process-tree as a dependency and use it on Windows to enumerate processes (via promisified getAllProcesses). Fall back to the existing WMIC parser when windows-process-tree is unavailable. Update provider logic to return parsed process items from the native API on Windows and keep PS-based listing for macOS/Linux. Update unit tests to stub and exercise the new getAllProcesses flow and the WMIC fallback, and add webpack externals entry for the new native module.
Adjust Windows process provider unit tests to match the updated getAllProcesses API that accepts a flag parameter and uses an error-first callback. Stubs now use signatures like (_flag, callback) and call callback(null, processList); throwing stubs were updated to accept two arguments. These are test-only updates to align with the new function signature.
Replace use of util.promisify with an explicit Promise wrapper around wpc.getAllProcesses, removing the promisify import and adapting the call site to resolve with the process list. Update unit tests to match the changed callback shape (stubs now call callback(processList) and throw without an error-first parameter). This keeps Windows process enumeration working while aligning with the windows-process-tree callback behavior.
Integrate windows-process-tree for Windows process enumeration
@ZA139
Copy link
Copy Markdown
Author

ZA139 commented Mar 30, 2026

Hi,@eleanorjboyd @Tyriar Sorry for the delay!
Due to the merge of microsoft/vscode-windows-process-tree#84 and some delays from my regular work, progress on this PR was postponed for a while. The new implementation is now ready and available for review. Could someone please be assigned to review it? Thank you!

Best Regards
Charles

'@opentelemetry/instrumentation': 'commonjs @opentelemetry/instrumentation', // ignored because we don't ship instrumentation
'@azure/opentelemetry-instrumentation-azure-sdk': 'commonjs @azure/opentelemetry-instrumentation-azure-sdk', // ignored because we don't ship instrumentation
'@azure/functions-core': '@azure/functions-core', // ignored because we don't ship instrumentation
'@vscode/windows-process-tree': 'commonjs @vscode/windows-process-tree',
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is correct. It's not an external. We need to have it as part of the webpack. Otherwise VS code would have to provide it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants