Profile fails to load when System.Windows.Forms objects are used, hanging extension

[baldieavenger]

Hey team,
Since the latest update, i'm not able to use the editor to run any code. Love that I wont get prompted to save now when running, not loving the fact the PowerShell session never completes now when running my auto loading profile (365 module signs in, which appear to be successful - Other than the latest ExchangeManagement module never popping out the creds prompt but I can work around using the lower version for now!)
All my modules pop up and sign ins are successful, but I cant figure out why the session hasn't finished to allow me to use the editor to run code now?
I've downgraded for now back to v2021.2.2 which lets me auto load my profile and sign in and let me carry on using the editor without issue.

[andyleejordan]

Hi,

Could you please provide more logging and environment information by following these steps?

Thanks!

[baldieavenger]

Hi,

Could you please provide more logging and environment information by following these steps?

Thanks!

Hiya!

Here you go, wasn't sure which so you have all 3!

I updated to v2021.5.1, restarted, entered creds from the prompts and tried to run something using F5 from the editor again and got the same issue.

Thanks!
VSCode-Logs-20210603..zip

[andyleejordan]

All three is perfect, thanks!

[andyleejordan]

Ah, I see in the logs that this is with PowerShell 5.1. Can you try PowerShell 7 and see if it still repros?

[baldieavenger]

I can, but, it's not managed Enterprise wide so this wont help for everyone here that uses Code as well as 5.1 on our prod servers. Also, embarrassingly im not sure how to update Code to use Ps7....
Is 5.1 no longer supported?

[baldieavenger]

Ignore this comment, it is still an issue with the latest VSCode, I just hadnt moved editors away from the settings page so didnt see the "Starting Powershell" notification not going away after everything has completed!

[baldieavenger]

Side note.... Now that im not prompted to save changes when using Editor, it doesnt run the code with the changes I made, unless I save it first. Is that intentional? I assumed it would allow me to run whatever was in that editor at that time, regardless of if id saved it or not?

[andyleejordan]

It should only not be prompting for untitled files, and that should only be the case in VS Code Insiders right now. Otherwise that behavior is unchanged. What happened was that we added this default config for their upcoming feature: https://github.com/PowerShell/vscode-powershell/pull/3357/files

For PowerShell files, it is to set to prompt for nonUntitledEditorsInActiveGroup or, "all editors except those that are untitled."

[andyleejordan]

Sorry, haven't had a chance to look at the main part of this issue yet.

[baldieavenger]

No worries, I'm in the UK so the weekend has already started

[baldieavenger]

Happy Monday! Rearing to go to help out where I can for this!

[andyleejordan]

Hey! Sorry, I was on vacation this last week and am just now back today. I should get to this on Monday, currently just triaging everything.

[andyleejordan]

@baldieavenger I'm wondering if this has to do with the main PowerShell 5.1 bug #3395 (comment) that cropped up this release. Can you test this extension build? PowerShell-insiders.vsix.zip

[baldieavenger]

Hi Andrew,
I tried this but it didnt help. I thought it might just be me and my local, but my colleague now sees the same issue after updating to Powershell too so not just me!

[baldieavenger]

Hi Andrew,
Anything more you need from me to dig into this?
Thanks!
John

[baldieavenger]

Something to add! I use a little Microsoft.VSCode_profile.ps1 which contains a pop out then invoke command so I can choose the ps1 profile I want to use at the time and its this causing the issue!
If I just use my log in script as Microsoft.VSCode_profile.ps1 it auto loads, prompts, signs in and then has finished doing its thing!
If I use my function to open and let me choose which one, it doesnt!
Microsoft.VSCode_profile.txt

[andyleejordan]

Oh, that is helpful. I see your function uses System.Windows.Forms which I know is causing other issues too: #3410 (comment)

[baldieavenger]

Looks like the same cause then for both of these too!
https://github.com/MicrosoftDocs/office-docs-powershell/issues/7895
#3396

[andyleejordan]

Ah, well, at least we know the problem. My understanding is that it may be difficult to fix due to the way System.Windows.Forms interoperates with a program's threading. But maybe PowerShell/PowerShellEditorServices#1295 will fix it? We shall see...

[baldieavenger]

Thanks! Whilst I'm here...... Any ideas on another way I can open a dialogue box to ask me for a ps1 to load? Lol

[andyleejordan]

@rjmholt thinks that we may have missed a location in PSES where we are not using ConfigureAwait(false) which causes these issues with System.Windows.Forms, so it looks like a bug on our end that we need to investigate. Sadly we cannot think of another way to open a dialogue box (though I suppose you could just use a Y/N prompt on the terminal?)

[andyleejordan]

I didnt have this setting so added it, if set to true I get either PID:0 7836, PID: 22228, PID: 14684, PID: 16512 when opening. (Is it meant to be different every time? Should I even be looking to add this and let you know what it does??)

This setting instructs the extension to wait for a debugger to be attached to the PowerShell process that it starts. That's why it's emitting the PID (which is different every time because new processes each have a new Process ID). It's used by developers for debugging the extension. Unless you want to attach a debugger to the extension's PowerShell process, leave it set to false.

I get the same behaviour which is as you asked @andschwa above

Can you state what that behavior is? Got a lot of issues and discussions happening, trying to keep this all straight is hard.

[baldieavenger]

No problem!
After using Microsoft.VSCode_profile.txt to open a prompt to allow me to select 365AdminSignIns.txt which should auto sign me in to Exchange Online, I dont get the authentication box pop up whih then passes through my creds to sign me in.

[andyleejordan]

Instead of:

    $file = Get-FileName -initialDirectory "C:\Users\USER\PATH\Documents\WindowsPowerShell"

   "&'$file'" | invoke-expression

Can you try:

    $file = Get-FileName -initialDirectory "C:\Users\USER\PATH\Documents\WindowsPowerShell"

   & $file

[baldieavenger]

No change :(

[andyleejordan]

You're certain you've uninstalled the PowerShell extension from the marketplace and manually installed the VSIX I posted? I can no longer reproduce your issue with the dev build I posted, while I could reproduce it from the marketplace version. What version are you seeing on startup in the integrated console?

[baldieavenger]

I think so!

This is interesting though, if I skip Connect-ExchangeOnline -UserPrincipalName adm-User@domain.com -ShowProgress $true, the next one to pop out is Connect-SPOService -Url "https://domain-admin.sharepoint.com" and this one does pop out and let me enter my credentials.

[baldieavenger]

I tried changing Connect-ExchangeOnline -UserPrincipalName adm-User@domain.com -ShowProgress $true to $cred = Get-Credential Connect-ExchangeOnline -Credential $cred -ShowProgress $false
This allows me to type my creds in the terminal and I wondered if that would mean it doesnt need to open the browser to authenticate, but its still the same so it must try and use tha pop up browser to authenticate regardless of what I do.

[andyleejordan]

Since the original bug in this issue is fixed, and that fix is now merged and will be in the next release, I will mark this issue as resolved. For your new problem, could you kindly open a new issue? You may want to wait until the extension is updated so you can try to reproduce it...take a look on Monday!

[ghost]

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

[baldieavenger]

I mean, its the same issue just worked through symptoms and the Beta isnt working for me as mentioned and after trying everything requested and providing all the logs but hey ho....
Ill come back if I still have issues and can confirm a colleague has the same issues after we update on Monday. Thanks!

[andyleejordan]

So, your issue goes away when you execute the code directly in your profile script, right? It now only fails when it's executed through "&'$file'" | invoke-expression? That seems to me to be a completely separate (albeit obviously still extant and annoying! I know) issue from the the bug around System.Windows.Forms.

[strickdd]

Hey @baldieavenger, could you test this dev build and let me know if it solves the issue?
powershell-preview-2021.8.1.zip

@andschwa I installed the preview linked and initial tests have allowed me to debug as expected. I'll continue to run some tests today. If debugging fails again, should I open a new issue or is there one I can reference since this has been closed?

[rjmholt]

If debugging fails again, should I open a new issue or is there one I can reference since this has been closed?

If it fails again it's probably a new (if related) problem, so worth a new issue for fresh discussion

[baldieavenger]

So, your issue goes away when you execute the code directly in your profile script, right? It now only fails when it's executed through "&'$file'" | invoke-expression? That seems to me to be a completely separate (albeit obviously still extant and annoying! I know) issue from the the bug around System.Windows.Forms.

It always worked when executing the code directly, I've only ever had the problem when using the "&'$file'" | invoke-expression but ill give it a try, just in case when the new version is released!
Thanks.

[andyleejordan]

So, your issue goes away when you execute the code directly in your profile script, right? It now only fails when it's executed through "&'$file'" | invoke-expression? That seems to me to be a completely separate (albeit obviously still extant and annoying! I know) issue from the the bug around System.Windows.Forms.

It always worked when executing the code directly, I've only ever had the problem when using the "&'$file'" | invoke-expression but ill give it a try, just in case when the new version is released!
Thanks.

It's out! Give it a go. This particular issue seems like something else is going on that Rob and I need to debug with you. That line of PowerShell itself is confusing, as it's first invoking the file $file (the & says "run this as a script") and then taking the result of that and piping it to Invoke-Expression, which I mean is a thing you can do, but what are you expecting out of it? That line of code is executing $file and then executing its results as PowerShell code.

[strickdd]

If debugging fails again, should I open a new issue or is there one I can reference since this has been closed?

If it fails again it's probably a new (if related) problem, so worth a new issue for fresh discussion

Thought things were working well, but started having issues. Boiled it down to the simplest steps I could.
#3522

[baldieavenger]

So, your issue goes away when you execute the code directly in your profile script, right? It now only fails when it's executed through "&'$file'" | invoke-expression? That seems to me to be a completely separate (albeit obviously still extant and annoying! I know) issue from the the bug around System.Windows.Forms.

It always worked when executing the code directly, I've only ever had the problem when using the "&'$file'" | invoke-expression but ill give it a try, just in case when the new version is released!
Thanks.

It's out! Give it a go. This particular issue seems like something else is going on that Rob and I need to debug with you. That line of PowerShell itself is confusing, as it's first invoking the file $file (the & says "run this as a script") and then taking the result of that and piping it to Invoke-Expression, which I mean is a thing you can do, but what are you expecting out of it? That line of code is executing $file and then executing its results as PowerShell code.

I tried today and no joy :(
The aim of my current Microsoft.VSCode_profile.ps1 is to give open a prompt to let me choose which otherprofile.ps1 to choose and then load immediately rather than opening in the editor for me to manually load.

I manage multiple O365 tenants and have multiple creds for different things and this was a really efficient way for me to control which Code Session loads into which O365 session.
I can of course manually choose which account I want in Microsoft.VSCode_profile.ps1 to load and change it manually but its not as smooth a ride but it does work, so ive been changing the names of my Microsoft.VSCode_profile.ps1 depending on which profile I need to log into at the time.

[baldieavenger]

So, your issue goes away when you execute the code directly in your profile script, right? It now only fails when it's executed through "&'$file'" | invoke-expression? That seems to me to be a completely separate (albeit obviously still extant and annoying! I know) issue from the the bug around System.Windows.Forms.

It always worked when executing the code directly, I've only ever had the problem when using the "&'$file'" | invoke-expression but ill give it a try, just in case when the new version is released!
Thanks.

It's out! Give it a go. This particular issue seems like something else is going on that Rob and I need to debug with you. That line of PowerShell itself is confusing, as it's first invoking the file $file (the & says "run this as a script") and then taking the result of that and piping it to Invoke-Expression, which I mean is a thing you can do, but what are you expecting out of it? That line of code is executing $file and then executing its results as PowerShell code.

@andschwa This is fixed with the latest update today!
v2021.9.0 and I can use the original Microsoft.VSCode_profile.ps1 with the "&'$file'" | invoke-expression and my pop up comes out, in front of my other windows and I can then navigate and choose another .ps1 with my profile in, which then does load!

[andyleejordan]

Awesome! So glad to hear that @baldieavenger.