Debugger hangs when `System.Windows.Forms` objects are used

[youngr137]

1623418243-1001617c-c46c-460d-a567-6024e60e18a91623416489171.zip

System Details Output

VSCode version: 1.57.0 b4c1bd0a9b03c749ea011b06c6d2676c8091a70c x64

VSCode extensions:

ms-vscode.powershell@2021.5.1
vscodevim.vim@1.21.1

PSES version: 2.4.3.0

PowerShell version:

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


System Info:
Edition	Windows 10 Home
Version	20H2
Installed on	‎03/‎10/‎2020
OS build	19042.1052
Serial number	MP1A8Y87
Experience	Windows Feature Experience Pack 120.2212.2020.0

Issue Description

Visual Studio was installed and ran for some days without problems. I saw a message indicating that an update was applied. After that I got the problem described below.
Script is:

Add-Type -AssemblyName 'System.Windows.Forms'

$contextFilmStripAlbumPictureBoxMenuStrip = New-Object System.Windows.Forms.ContextMenuStrip
$null = $contextFilmStripAlbumPictureBoxMenuStrip.Items.Add("Single larger picture slideshow")
Write-Host 'Hello world'

I set a breakpoint on line 4 ($contextFilmStripAlbumPictureBoxMenuStrip = New-Object System.Windows.Forms.ContextMenuStrip)
Start debugging with F5. Stops on line 4 with highlight. Press F10 and debugger appears hung. (Run menu has grayed out the F10 and F11). These keys do not work. On occasions pressing F5 then 'Hello World' appears on terminal. Terminal prompt> is not hung.

Expected Behaviour

Expected using F10 to step over each line of code in script.

Actual Behaviour

After a number of steps Visual Studio hangs. F10,F11 are greyed out in the Run menu and the keys do not work

Attached Logs

Set to diagnostic and supplied.

[youngr137]

Ok I have noticed that although F10,F11 etc are not working the terminal prompt is from the debugger eg [DBG]: PS C:\Users...\cmds\testit> so I can type v to step over or c to continue and the code jumps to the next breakpoint
eg Hit Line breakpoint on 'c:\Users...\cmds\testit\HelloWorld.ps1:6'
Sadly nothing is visible in VARIABLES. CALL STACK shows Running and stays with that even when script exits.

I am guessing that something in the Terminal should be being sent to the Visual Studio UI but is not when handling .NET calls

[AlfiCode]

I observe the same behaviour with the integrated terminal.
I saw it with 2 different commands:
$VerRes = gitversion /version
[string]$tmpVerRes = perl -le 'print $]'.
It doesn't matter if I run (F5 without breakpoint) or step over (F10).
The debugger does nothing. The blue symbols (F5, F10, F11, Shift+F11) on debug-bar are greyed out.
I go to the terminal press the enter-key and the debugger continues.
If I make a breakpoint at that line and issue the command in the terminal directly -> no problem and the result is as expected.

It happens with:
=====> PowerShell Integrated Console v2021.5.1 <=====
Sometimes ago it didn't happen.

[andyleejordan]

Interesting. It seems to be a protocol issue because as you say the PowerShell process itself is correctly debugging, it's just that the information that needs to be relayed from the process to the DAP server underneath VS Code. We'll need to repro this internally to make any headway, and the DAP is actually being worked on by @rjmholt so perhaps this bug will be fixed by the rework in PowerShell/PowerShellEditorServices#1459

Also the use of System.Windows.Forms may be the root of this as it reroutes the asynchronous calls around.

[youngr137]

If there is anything further you need from me please let me know. I’m UK based but retired so my time is my own. Roger

…

On Mon, 14 Jun 2021 at 21:39, Andrew Schwartzmeyer ***@***.***> wrote: Interesting. It seems to be a protocol issue because as you say the PowerShell process itself is correctly debugging, it's just that the information that needs to be relayed from the process to the DAP server underneath VS Code. We'll need to repro this internally to make any headway, and the DAP is actually being worked on by @rjmholt <https://github.com/rjmholt> so perhaps this bug will be fixed by the rework in PowerShell/PowerShellEditorServices#1459 <PowerShell/PowerShellEditorServices#1459> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3410 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUMZMC7YONZKABWSPVW23HDTSZSJLANCNFSM46QZQLSA> .

[youngr137]

You are right about Forms:
A simple 3 line script demonstrates the issue seen:
Add-Type -AssemblyName 'System.Windows.Forms'
$form = New-Object System.Windows.Forms.Form
Write-Host "Hello"
Runs correctly until you set a breakpoint, for example, on the Write-Host.
Other scripts I run where forms are not used work correctly with the debugger.

[Abax378]

System Info:
Windows 10 version 20H2 (OS Build 1904201052)
.NET 3.5 and 4.8.084 installed
Visual Studio Code version 1.57.1
VS Code extension PowerShell (ms-vscode.powershell) version 2021.6.2
PowerShell version 5.1.19041.1023 and 7.1.3

My comments touch on items previously discussed in this issue - hopefully they add something valuable.

I was debugging a PowerShell script that used Get-ChildItem to process some files - the debugger worked as expected.. When I added a reference to System.Windows.Forms in the code to select a directory and ran the debugger, the debugger immediately stopped working. The debugger also stopped working on any other script, whether it had a reference to System.Windows.Forms or not. The failure was as @youngr137 described above: the terminal prompt changed to [DBG]: PS {my directory}, all the debugger toolbar buttons were grayed out except Pause / Restart / Stop, and debugger function keys (F5, F11, et al) did not work. I could, however, move to the next breakpoint by entering "c" at the [DBG] terminal prompt.

In the midst of debugging a script and with the debugger toolbar partially grayed out as described above, I discovered if I moved to the next breakpoint by entering "c", then called the script again from the [DBG] terminal prompt (by entering the path and file name), the debugger would start from the beginning of the script (executing the code), advance past any previous breakpoints to the current breakpoint, and the debugger toolbar would revert to normal. When I pressed the toolbar down arrow (i.e., Step Into / F11), the debugger advanced but the toolbar was immediately grayed out again. This process could be repeated until all breakpoints were exhausted. Under any set of circumstances, the debugger never exited at the end of a script . . . I always had to stop the debugger to get a normal terminal prompt again.

I also tried the debugger using VS Code version 1.56.2 with the same results.

Other things that did not restore the debugger to normal operation:

• disable and re-enable the PowerShell extension in VS Code.
• uninstall and re-install the PowerShell extension in VS Code.
• completely uninstall VS Code, manually remove all directories and registry entries formerly associated with the installation, reboot, then reinstall VS Code and the PowerShell extension.
• run Microsoft's NetFxRepairTool.exe, then re-run Win 10 MS update (which did grab some .NET updates).
• run the command sfc /scannow.
• deselect .NET 3.5 and 4.8 at Control Panel | Programs | Uninstall | Turn Windows features on or off. Reboot, re-select .NET 3.5 and 4.8, then reboot again.

Googling "Visual Studio Code debugger not working" returns a lot of complaints on many different forums (including GitHub) over the last three years. It sure would be nice if a concerted effort was made to resolve this issue in the very near future. Debugging is the ONLY reason I have VS Code installed - if it doesn't work, VS Code is useless to me.

edit - added turning .NET feature off then back on

[andyleejordan]

It sure would be nice if a concerted effort was made to resolve this issue in the very near future.

I have great news for you! We are actively making a concerted effort to resolve our debugger (and other) stability issues! See more in our blog post and track our progress in the project.