Powershell: Test-Connection 'hangs' after New-Object System.Windows.Forms.Form

Created on 21 Dec 2019 · 11Comments · Source: PowerShell/PowerShell

Steps to reproduce

Issue the following from a new pwsh session:
Add-Type -AssemblyName System.Windows.Forms
$MainForm = New-Object System.Windows.Forms.Form
Test-Connection 'PC-IAN'

Expected behavior

Test-Connection should run and produce similar output to the following:


   Destination: PC-IAN

Ping Source           Address                   Latency BufferSize Status
                                                   (ms)        (B)
---- ------           -------                   ------- ---------- ------
   1 PC-IAN           fe80::5158:e71e:c447:7e86       0         32 Success
   2 PC-IAN           fe80::5158:e71e:c447:7e86       0         32 Success
   3 PC-IAN           fe80::5158:e71e:c447:7e86       0         32 Success
   4 PC-IAN           fe80::5158:e71e:c447:7e86       0         32 Success

Actual behavior

The pwsh session ‘hangs’ (i.e. doesn’t respond at all after Test-Connection).

Test-Connection produces the expected results if $MainForm = New-Object System.Windows.Forms.Form IS NOT run beforehand.

$MainForm = New-Object System.Windows.Forms.Form is successful and the resulting form can be processed if Test-Connection IS NOT run afterwards.

Environment data


Name                           Value
----                           -----
PSVersion                      7.0.0-rc.1
PSEdition                      Core
GitCommitId                    7.0.0-rc.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

Issue-Question

Source

IanBAdams

Most helpful comment

@SeeminglyScience, many thanks for the work around. A quick test confirms that this gets around the problem for both the localhost and remote hosts.

I'll need to amend my scripts to build this in temporarily, until a fix become available. However, this allows me to continue in the meantime.

Thanks again.

IanBAdams on 23 Dec 2019

👍2 🎉1

All 11 comments

FWIW, I can reproduce this error.

doctordns on 21 Dec 2019

I haven't got time to verify right at the moment, but this _seems_ like it might be a .net core issue.

Might be something we need to try to work around in terms of how we're waiting for the Ping response. :thinking:

vexx32 on 21 Dec 2019

The Form constructor sets the synchronization context for the current thread which is messing with the async bits behind the scenes. Here's a work around for now:

Add-Type -AssemblyName System.Windows.Forms
$MainForm = New-Object System.Windows.Forms.Form

$oldSyncContext = $null
try {
    $oldSyncContext = [Threading.SynchronizationContext]::Current
    [Threading.SynchronizationContext]::SetSynchronizationContext($null)
    Test-Connection localhost
} finally {
    if ($null -ne $oldSyncContext) {
        [Threading.SynchronizationContext]::SetSynchronizationContext($oldSyncContext)
    }
}

SeeminglyScience on 23 Dec 2019

@SeeminglyScience is that something we can incorporate into the cmdlet itself, perhaps in its Dispose method?

vexx32 on 23 Dec 2019

Not sure about that. It's fine for a workaround, and would fix the deadlock, but I'm not sure what effect it could have on form behavior.

In the cmdlet itself, you could just start up a new thread with Task.Run before calling SendPingAsync (sync context is thread static). It's possible that could also cause a deadlock if the thread pool limits are set very low though.

Not sure which one is the lesser evil, or if there's a clearly better solution. Might be something the PS team needs to weigh in on.