Cannot attach debugger to PS 7.4.0 processes

[nightroman]

Prerequisites

• I have written a descriptive issue title.
• I have searched all open and closed issues to ensure it has not already been reported.
• I have read the troubleshooting guide.
• I am sure this issue is with the extension itself and does not reproduce in a standalone PowerShell instance.
• I have verified that I am using the latest version of Visual Studio Code and the PowerShell extension.
• If this is a security issue, I have read the security issue reporting guidance.

Summary

Cannot attach debugger to an interactively selected PS 7.4.0 processes.
This operation takes long time, then results in this error

PowerShell Version

PS C:\ROM\SET\VSCode\debug-psf> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.4.0
PSEdition                      Core
GitCommitId                    7.4.0
OS                             Microsoft Windows 10.0.19045
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visual Studio Code Version

1.84.2
1a5daa3a0231a0fbba4f14db7ec463cf99d7768e
x64

Extension Version

ms-vscode.powershell@2023.8.0
I have also tried the latest pre-release, same issue.

Steps to Reproduce

• Select launch profile "PowerShell attach" (below)
• Hit F5
• Select one of PS 7.4.0 choices

Launch profile:

{
  "launch": {
    "version": "0.2.0",
    "configurations": [
      {
        "type": "PowerShell",
        "request": "attach",
        "name": "PowerShell attach",
        "processId": "${command:PickPSHostProcess}",
        "runspaceId": 1
      }
    ]
  }
}

Visuals

No response

Logs

No response

[nightroman]

Bump...

[SydneyhSmith]

Thanks for the issue @nightroman we will need to do some more investigation into this

[andyleejordan]

Are you perhaps using the Windows Store installed version of PowerShell? I can never seem to attach to that installation, but can attach to 7.4 installed in pretty any other manner.

[nightroman]

I use the PowerShell-7.4.0-win-x64.zip from Releases -- https://github.com/PowerShell/PowerShell/releases/tag/v7.4.0

[nightroman]

Here is the latest status, changed with new versions, still not working but differently

VSCode version:
1.85.1
0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2
x64

ms-vscode.powershell version:
ms-vscode.powershell@2024.0.0

$PSVersionTable; $Host

Name                           Value
----                           -----
PSVersion                      7.4.1
PSEdition                      Core
GitCommitId                    7.4.1
OS                             Microsoft Windows 10.0.22631
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Name             : Visual Studio Code Host
Version          : 2024.0.0
InstanceId       : 8b608c97-927c-4d67-abc2-488fec552269
UI               : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture   : en-GB
CurrentUICulture : en-US
PrivateData      : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
DebuggerEnabled  : True
IsRunspacePushed : False
Runspace         : System.Management.Automation.Runspaces.LocalRunspace

[andyleejordan]

Thanks for the update, that's very helpful and has led me to find a bug (or two).

[andyleejordan]

So I think VS Code got stricter about type matching in variable substitutions, and these were mismatched. The original design allowed the PID to be an int or a string (which was just a special case for "current") but that led to a lot of unnecessary complication.

[nightroman]

When can we try the fix?

[JustinGrote]

@nightroman every commit has a build, here is the one for the PR:
https://github.com/PowerShell/vscode-powershell/actions/runs/7549834396/artifacts/1173960040

Extract the VSIX and use "install with VSIX" in vscode and then reload your vscode.

[nightroman]

Thank you. Same result so far, maybe the fix is not in this VSIX yet

[JustinGrote]

Can confirm I reproduced on the VSIX after choosing host process 80488.

@andyleejordan surprised type checking didn't catch this but I think this needs to be Promise<number> instead of Promise<string>

vscode-powershell/src/features/DebugSession.ts

Line 620 in d367094

private async pickPSHostProcess(): Promise<string | undefined> {

[andyleejordan]

Can confirm I reproduced on the VSIX after choosing host process 80488.

@andyleejordan surprised type checking didn't catch this but I think this needs to be Promise<number> instead of Promise<string>

vscode-powershell/src/features/DebugSession.ts

Line 620 in d367094

private async pickPSHostProcess(): Promise<string | undefined> {

I definitely changed that so either I lost it in a rebase or that's the wrong build.

[andyleejordan]

Yup, it is fixed in the PR: https://github.com/PowerShell/vscode-powershell/pull/4888/files#r1462216399 which build did you guys grab?

[JustinGrote]

I thought I grabbed the PR build so I probably screwed up, let me double check

[andyleejordan]

Well you did grab the right artifact...but when I build locally I go from being able to repro to not.

[andyleejordan]

Now with the changes made, the input to "processId" in the JSON should be an int so it does throw a squiggly warning about it being "${command:PickPSHostProcess}". This way of doing it continues to work, but I set it up so just not setting "processId" at all for an attach configuration will run PickPSHostProcess. So you can delete the whole line.

[nightroman]

Removing the line with processId seems to be doing the trick, it's a very good news and progress, thank you.
Looking forward to the official update. Any ETA? Sometimes debugging helps :)

NB I believe this attached debugger flow was not well documented. But it's formally a breaking change. Please mention this in release notes. For your consideration.

[JustinGrote]

@nightroman the goal is to not break existing configs, we are working on it in the linked PR and will note back here if we find it.