Creating Windows.Forms.Form lock the debugger - v2019.11.0-preview

[ili101]

Issue Type: Bug

Add-Type -AssemblyName System.Windows.Forms
$Form = [System.Windows.Forms.Form]::new()
Set-PSBreakpoint -Variable 'Foo'
$Foo = 5

When Run in the "PowerShell Integrated Console" in any way you will get into DBG mode as expected but you cannot write anything in the console, In addition adding/removing breakpoints have no effect.
Essentially making debugging unusable.

Extension version: 2019.11.1-CI.38936
VS Code version: Code 1.40.2 (f359dd69833dd8800b54d458f6d37ab7c78df520, 2019-11-25T14:54:45.096Z)
OS version: Windows_NT x64 10.0.18362

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz (8 x 3392)
GPU Status	2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: disabled_off protected_video_decode: unavailable_off rasterization: enabled skia_renderer: disabled_off surface_control: disabled_off surface_synchronization: enabled_on video_decode: enabled viz_display_compositor: enabled_on viz_hit_test_surface_layer: disabled_off webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	15.93GB (7.72GB free)
Process Argv
Screen Reader	no
VM	67%

[SydneyhSmith]

@ili101 thanks for opening this issue, could you please also provide the logs of this? Thanks!

[ili101]

EditorServices.log

[ili101]

Still a problem on v2019.12.0-preview (v2019.12.0-stable don't have this problem)

[ghost]

This issue is being closed as inactive, if this issue is still occurring it will be re-opened

[rjmholt]

Output from !EEStack in windbg from a deadlock reproduced with the steps given in the issue description:

deadlock_dump.txt

[rjmholt]

Looking into this further, I'm not experiencing a difference in the experience due to Windows forms use; commenting out the winforms parts gives me the same behaviour, where the console won't accept input.

In the case where a variable breakpoint is set, I believe the deadlock is an extension of the above problem. The pipeline thread is blocked by the debugger, which in the first case means the prompt is blocked, but in the second case means the variable execution is blocked, which in turn blocks the debugger, leading to a block cycle.

I'll keep investigating now that I've characterised the issue

[ili101]

For me it works without the Form part.
Make sure you trash the integrated console between the testes as once [System.Windows.Forms.Form]::new() has been run debugging will be locked even if commented out in followings runs until you get a new console.

[rjmholt]

Is this in PowerShell 5.1?

[ili101]

PS 5.1 and PS 7rc1 same behavior. VSCode PowerShell Preview Extension v2019.12.0
Once $Form = [System.Windows.Forms.Form]::new() is run (while debugging or not) every following debug session on this console will not let you type while debugging.

[rjmholt]

Sorry, yes just noticed that it's the same behaviour across both:

• The debug prompt accepts input and interacts properly until a WinForms type is loaded
• After this, debugging can continue, but the debug prompt does not allow typing
• Once debugging ends, any typed characters appear and the prompt goes back to behaving as normal
• Further debugging sessions, even without further WinForms usage, continue to be affected by the same issue for the lifetime of the PSES host PowerShell process

[SeeminglyScience]

@rjmholt FYI it's probably because the Form constructor sets the sync context for the thread it's called on.

[rjmholt]

That does indeed seem to be the case

[SeeminglyScience]

Also sorta related: PowerShell/PowerShell#11418

[rjmholt]

So you can work around this to some extent today by running this in your script:

[System.Threading.SynchronizationContext]::SetSynchronizationContext([System.Threading.SynchronizationContext]::new())

However, for some reason I haven't yet understood, it doesn't work the first time. But subsequent times it works fine.

I should say that WinForms doesn't play nicely with things with their own thread model, like PowerShell. If you execute WinForms code directly in PowerShell, it can cause deep state changes that interfere with other things. If, instead, you're able to kick the WinForms code into another thread or process (like with a job), you won't hit these issues.

[rjmholt]

So I've worked through this more and come up with a much better fix with the help of @daxian-dbw. Basically bad async/await usage was marshalling thread delegates through a synchronisation context, and the WinForms one in particular tried to force the work marshalling delegates back to the already-blocked pipeline thread.

Some simple changes have fixed that.