Fix Windows process picker loading from ASAR

[Rich Chiodo (rchiodo)]

Summary

• load @vscode/windows-process-tree from VS Code's packaged node_modules.asar layout
• retain the physical node_modules fallback for development and older layouts
• log native process-tree failures before falling back to WMIC
• cover both module layouts with unit tests

Fixes #1095

Validation

• exercised both loader paths against the emitted JavaScript
• git diff --check

Full TypeScript and unit test execution was blocked locally by npm registry TLS handshake failures while restoring dependencies.

[Travis Evashkevich (TravisEvashkevich)]

Is there anyway to get people to approve this so we can all get back to debugging python again?

[Rich Chiodo (rchiodo)]

Is there anyway to get people to approve this so we can all get back to debugging python again?

Thanks for bringing it up. I forgot to ping people internally to review this.

[Travis Evashkevich (TravisEvashkevich)]

Thanks! Is there any way to pick this up sooner rather than later on a user end? Is it just using pre release vscode?

[Bill Schnurr (bschnurr)]

🔒 Automated review in progress — Bill Schnurr (@bschnurr) is auto-reviewing this PR.

[Bill Schnurr (bschnurr)]

Warning · Non-blocking recommendation

loadError ??= error preserves the expected ASAR-miss error even when the physical node_modules load is the one that actually fails (for example, due to an ABI mismatch). This makes the fallback diagnostic misleading; retain the physical-path failure or include both path-specific errors, and cover the case where both candidates throw.

[verified]

[Bill Schnurr (bschnurr)]

Result: ⚠️ needs-more-tests

Verification details

Verification: Isolated verification observed failures that were not classified as caused by this PR: Should fall back to WMIC when getAllProcesses fails. The relevant tests could not be fully run in the isolated environment; this review is not fully verified.

Summary: TypeScript compilation succeeded, and both newly added loader tests passed against the emitted JavaScript. The existing WMIC fallback test could not complete because the custom non-Electron harness lacks the Python extension API; this is unrelated to the PR. The new error-logging behavior has no assertion coverage. Confidence is therefore limited despite successful loader-path verification.

Test runs: 2 passed, 1 failed, 1 skipped

• ⏩ Skipped | WMIC fallback test discovery attempt | Custom Node/Mocha harness loading out/test/unittest/attachQuickPick/provider.unit.test.js with anchored grep /^Should fall back to wmic when getAllProcesses fails$/
• ❌ Failed | unrelated to this PR | Should fall back to WMIC when getAllProcesses fails | Custom Node/Mocha harness loading out/test/unittest/attachQuickPick/provider.unit.test.js with grep /Should fall back to wmic when getAllProcesses fails/
• ✅ Passed | TypeScript test compilation | npm run compile-tests
• ✅ Passed | Windows process-tree loader tests | Custom Node/Mocha harness loading out/test/unittest/attachQuickPick/provider.unit.test.js with grep /Loads windows-process-tree from node_modules.asar|Falls back to the physical node_modules directory/

⏩ WMIC fallback test discovery attempt diagnostic output

0 passing (2ms)

❌ Should fall back to WMIC when getAllProcesses fails diagnostic output

0 passing
1 failing

Error: Python extension is not installed or is disabled
  at Object.api (node_modules/@vscode/python-extension/out/main.js:17:19)
  at legacyGetPythonExtensionEnviromentAPI (out/extension/common/legacyPython.js:42:53)
  at async legacyGetEnvironmentVariables (out/extension/common/legacyPython.js:76:17)

[Bill Schnurr (bschnurr)]

Approved via Review Center.

[Rich Chiodo (rchiodo)]

Thanks! Is there any way to pick this up sooner rather than later on a user end? Is it just using pre release vscode?

The next prerelease version of the debugger extension will have the fix.