Vscode-powershell: PowerShell debugging session crashes when debugging ends

[reduckted]

System Details

System Details Output

### VSCode version: 
1.52.1 ea3859d4ba2f3e577a159bc91e3074c5d85c0523 x64

### VSCode extensions:
[email protected]

### PSES version:

### PowerShell version:

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

(I've disabled all extensions except for the PowerShell extension).

Possibly also of note is that I have PowerShell installed as a .NET Global Tool using .NET SDK v5.0.102

Issue Description

After a few debugging sessions, the session will appear to end successfully, but then the Integrated Terminal will crash. Sometimes this occurs after only two or three runs, but sometimes it can be after seven, eight or even more successful runs. It doesn't seem to matter what the script does. Here's a screen capture of running a script that simply calls Write-Host.

Expected Behaviour

PowerShell doesn't crash.

Actual Behaviour

The PowerShell session will crash with the error:

An error has occurred that was not properly handled. Additional information is shown below. The PowerShell process will exit.
Unhandled exception. System.AggregateException: One or more errors occurred. (One or more errors occurred. (Safe handle has been closed.
Object name: 'SafeHandle'.))
 ---> System.AggregateException: One or more errors occurred. (Safe handle has been closed.
Object name: 'SafeHandle'.)
 ---> System.ObjectDisposedException: Safe handle has been closed.
Object name: 'SafeHandle'.
   at System.Runtime.InteropServices.SafeHandle.DangerousAddRef(Boolean& success)
   at System.StubHelpers.StubHelpers.SafeHandleAddRef(SafeHandle pHandle, Boolean& success)
   at Interop.Kernel32.CancelIoEx(SafeHandle handle, NativeOverlapped* lpOverlapped)
   at System.IO.Pipes.PipeCompletionSource`1.Cancel()
   at System.IO.Pipes.PipeCompletionSource`1.<>c.<RegisterForCancellation>b__14_0(Object thisRef)
   at System.Threading.CancellationTokenSource.ExecuteCallbackHandlers(Boolean throwOnFirstException)
   --- End of inner exception stack trace ---
   at System.Threading.CancellationTokenSource.ExecuteCallbackHandlers(Boolean throwOnFirstException)
   at Nerdbank.Streams.PipeExtensions.<>c.<UsePipeReader>b__18_0(Exception ex, Object state)
   at System.IO.Pipelines.PipeCompletionCallbacks.Execute(PipeCompletionCallback callback, List`1& exceptions)
   --- End of inner exception stack trace ---
   at System.IO.Pipelines.PipeCompletionCallbacks.Execute()
   at System.IO.Pipelines.Pipe.<>c.<.cctor>b__90_2(Object state)
   at System.Threading.QueueUserWorkItemCallback.Execute()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()

The same error is reported in Event Viewer:

Application: dotnet.exe
CoreCLR Version: 5.0.220.61120
.NET Version: 5.0.2
Description: The process was terminated due to an unhandled exception.
Exception Info: System.AggregateException: One or more errors occurred. (One or more errors occurred. (Safe handle has been closed.
Object name: 'SafeHandle'.))
<... snip ...>

Attached Logs

logs.zip

[reduckted]

I've just updated to the latest VS Code version (1.53.0 8490d3dde47c57ba65ec40dd192d014fd2113496 x64) and can still reproduce this bug.

[SydneyhSmith]

Thanks @reduckted for providing the detailed issue report including the GIF, and logs/stack trace, it is really appreciated!
It looks as though something is causing the named pipe to close at the transport layer....this one will be difficult to debug...in the meantime you may want to try the PowerShell Preview extension as the issue may be resolved in that version...thanks!

[reduckted]

I just tried with the preview extension and unfortunately I get the same problem.

I also tried to replicate this on a different machine but couldn't get it to crash. Is there any additional logging that I can turn on to help work out what's going on?

[SydneyhSmith]

Thanks for the update @reduckted we do not have any additional logging instrumented right now for you to turn on, however as we tackle this issue we may have future builds of the extension for you to test out, thanks for your patience!

[reduckted]

Seems like this may have been fixed in either v2021.2.0-preview or v2021.2.1-preview.

After upgrading from v2020.9.0-preview to v2021.2.1-preview, I cannot reproduce this anymore.