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:

[email protected]
[email protected]

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.

[Abax378]

Other scripts I run where forms are not used work correctly with the debugger.

Once I debugged a script with a reference to System.Windows.Forms, the debugger failed on all scripts. I then reinstalled Visual Studio Code (on top of the existing installation), and debug function was restored. If I again tried to debug a script with a reference to System.Windows.Forms, this cycle was repeated.

[andyleejordan]

Oof, that sounds awful.

[renerichard-gr]

I see the same behaviour, VSCode runs up until a breakpoint without any issues, then when I single step (F10) it hangs forever.

[banyula]

I have the same issue trying to debug a PS script that uses Windows Form. Unable to do it with VS Code I tried to use ISE (yuk!!) and at the end I was able to do it using Visual Studio 2019 and a trial copy of PowershellProTools that provides a similar capability.

Please rush on fixing this issue.

[renerichard-gr]

I have the same issue trying to debug a PS script that uses Windows Form. Unable to do it with VS Code I tried to use ISE (yuk!!) and at the end I was able to do it using Visual Studio 2019 and a trial copy of PowershellProTools that provides a similar capability.

Please rush on fixing this issue.

To be clear I'm not using WIndows Forms. I'm only importing the ActiveDirectory module.

[andyleejordan]

Other scripts I run where forms are not used work correctly with the debugger.

Once I debugged a script with a reference to System.Windows.Forms, the debugger failed on all scripts. I then reinstalled Visual Studio Code (on top of the existing installation), and debug function was restored. If I again tried to debug a script with a reference to System.Windows.Forms, this cycle was repeated.

For what it's worth, you should only need to restart the PowerShell session. From the command palette in VS Code, run "PowerShell: Restart Current Session". I have made some progress debugging this but haven't found the root cause yet.

[andyleejordan]

@banyula @Abax378 @youngr137 (and anyone else with issues debugging a PowerShell script which uses an object from Systems.Windows.Forms), could you test the dev build uploaded in the linked comment and let me know if the issue is resolved? Thank you! #3394 (comment)

[banyula]

I just tried and it worked as expected, not the first time after the VSIX was loaded because it hung on the DisplayDialog() method call by not displaying the dialog window. After I restarted VSCode it started working fine again being to able to stop at breakpoints after windows.form was invoked before DisplayDialog, as well as displaying the proper dialog thereafter.

[andyleejordan]

There's an entirely separate upstream issue with VS Code that GUI windows are displayed behind the VS Code window, and there's sadly nothing we as extension authors can do about it. So it sounds like it worked as best it could! This is great news.

[andyleejordan]

Here's that issue: #1175

[youngr137]

I probably confused people looking at issue #3394 with my comment there yesterday as they should have been here for this issue. Essentially the issue raised appears to be fixed by the preview v2021.8.1. I am able to run scripts with System.Windows.Form objects in them and step through using F10, F11 etc. There is a remaining problem (which I don't think is the same as issue #2821) where the script can't be re-run (or any PS script run). The script fails to start and the PowerShell Extension Logs show a timeout. This is a small snippet from the log:
11/08/2021 10:55:38 [VERBOSE] - Connected to socket!
11/08/2021 11:17:52 [VERBOSE] - Connecting to pipe: \.\pipe\PSES_cltnlzc4.cdi
11/08/2021 11:17:52 [VERBOSE] - Debug configuration: {"name":"PowerShell Launch Current File","type":"PowerShell","request":"launch","script":"c:\Users\roger\Documents\cmds\testit\generateThumbnailsInSourceTree.ps1","args":["-debug -testDir C:\tmp\m\sourcePics -checkOnly"],"cwd":"c:\Users\roger\Documents\cmds\testit\generateThumbnailsInSourceTree.ps1","__configurationTarget":5,"createTemporaryIntegratedConsole":false,"internalConsoleOptions":"neverOpen"}
11/08/2021 11:18:22 [ERROR] - Error on Debug Adapter: Error: connect ETIMEDOUT \.\pipe\PSES_cltnlzc4.cdi
The line a 11/08/2021 10:55:38 is the last thing logged when I ran a script successfully. Then at 11/08/2021 11:17:52 I attempted to start a new script and the timeout occurs.
I looked at the PowerShell Editor Services logs and the last thing logged is at 11:01:29 and these are errors (presumably from running the first script)
[Error - 11:01:29] Microsoft.PowerShell.EditorServices.Services.PowerShellContextService: Exception occurred while executing debugger command |
[Error - 11:01:29] Microsoft.PowerShell.EditorServices.Services.PowerShellContextService: Execution of the following command(s) completed with errors:

Get-Variable -Scope 1

|
[Warn - 11:01:29] Microsoft.PowerShell.EditorServices.Services.PowerShellContextService: Runtime exception occurred while executing command |

Looking back through this log file the first error looks like:
[Warn - 10:55:40] Microsoft.PowerShell.EditorServices.Services.WorkspaceService: Failed to get file for fileUri: 'untitled:Untitled-1' |

The file Untitled-1 does not exist but I am guessing gets created when you use File->New File. I had done this some days ago and just closed the tab that gets created. It does show up in the BREAKPOINTS section on the left of Visual Studio with 2 breakpoints. However having removed the breakpoints I still get problems on restarting/starting a script after a successful run.

I stopped and restarted Visual Studio
Here are the logs from a test to run and rerun a script testTextbox.ps1. I started it at 13:39:13 and after stepping through a couple of lines and then F5 I exited the program and started it again at 13:40:25.
The extension log shows a timeout and the Editor Services log shows error from the first run of testTextbox.ps1 so I am guessing the problem is there?
1628685473-ec06d506-16b0-4a93-b6a2-2b51f54fbdb41628685455792.zip

This issue is I think now raised as issue #3505

[andyleejordan]

Super helpful, thanks @youngr137! Sometimes this feels like a game of whack-a-mole: fix one problem and another crops up 😬

[andyleejordan]

The fix has been merged and will be in the next release! Seeing as how your new bug @youngr137 already has a separate issue, I'll mark this one resolved.

[ghost]

This issue has been marked as fixed. It has been automatically closed for housekeeping purposes.

[andyleejordan]

The Powershell Preview extension is out with this fix in it!