You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've encountered an issue using PowerShell v7.0.1 or higher in a .NET Windows application.
This bug causes a hang when PS fails to import a module through WinCompat in these two scenarios:
the application depends on the entire PowerShell SDK, but only in self-contained published builds
PS: I know that applications using PowerShell should depend on the entire SDK and not just on System.Management.Automation, but in my case I have an application that only needs to run some commands on the machine and then operate on their output. The full SDK contains 20MB+ of dependencies that my application never uses and significantly bloat the distributable EXE.
Steps to reproduce
The simplest code that triggers the bug is the following:
InitialSessionStatesessionState=InitialSessionState.CreateDefault2();sessionState.ExecutionPolicy=ExecutionPolicy.Unrestricted;// needed to make import workusingPowerShellpwsh=PowerShell.Create(sessionState);pwsh.AddScript("Import-Module Dism -UseWindowsPowerShell");pwsh.Invoke();Console.WriteLine("Script executed");
I have a created a VS project (which can be downloaded here) that contains this code and a PublishProfile that can be used to reproduce the bug in the second scenario described above.
Important: when removing the project dependency on Microsoft.PowerShell.SDK remember to remove the bin directory inside the project folder! Otherwise you'll get inconsistent results.
Expected behavior
Script executed
is printed to the standard output and then the application exits gracefully. (in scenario 1 Import-Module command will fail anyway, since we don't have Microsoft.PowerShell.Utility module that is required for WinCompat)
Actual behavior
The application hangs indefinitely before printing the Script executed message when:
it depends only on System.Management.Automation and Microsoft.PowerShell.Security v7.0.1+ regardless of the build type
it depends on Microsoft.PowerShell.SDK v7.0.1+, but only in Published builds
Possible cause
Looking at the stack trace of the pipeline execution thread while the application hangs in scenario 1, the thread appears to be stuck in an infinite loop when trying to import the Microsoft.PowerShell.Utility module.
This bug was introduced by #12269. (see my analysis below: #13157 (comment))
I've encountered an issue using PowerShell v7.0.1 or higher in a .NET Windows application.
This bug causes a hang when PS fails to import a module through WinCompat in these two scenarios:
PS: I know that applications using PowerShell should depend on the entire SDK and not just on System.Management.Automation, but in my case I have an application that only needs to run some commands on the machine and then operate on their output. The full SDK contains 20MB+ of dependencies that my application never uses and significantly bloat the distributable EXE.
Steps to reproduce
The simplest code that triggers the bug is the following:
I have a created a VS project (which can be downloaded here) that contains this code and a PublishProfile that can be used to reproduce the bug in the second scenario described above.
Important: when removing the project dependency on Microsoft.PowerShell.SDK remember to remove the
bindirectory inside the project folder! Otherwise you'll get inconsistent results.Expected behavior
is printed to the standard output and then the application exits gracefully. (in scenario 1
Import-Modulecommand will fail anyway, since we don't haveMicrosoft.PowerShell.Utilitymodule that is required for WinCompat)Actual behavior
The application hangs indefinitely before printing the
Script executedmessage when:Possible cause
Looking at the stack trace of the pipeline execution thread while the application hangs in scenario 1, the thread appears to be stuck in an infinite loop when trying to import the
Microsoft.PowerShell.Utilitymodule.This bug was introduced by #12269. (see my analysis below: #13157 (comment))