azure-functions-powershell-worker
azure-functions-powershell-worker copied to clipboard
ConvertTo-SecureString hangs PowerShell host when run in the VS Code debugger
If you run the below code without using Wait-Debugger then it will run correctly without issue:
param($Request, $TriggerMetadata)
Wait-Debugger
$EncryptString = "eamon"
Write-Output $EncryptString
$TestSecure = ConvertTo-SecureString -String $EncryptString -AsPlainText -Force
$TestSecure
If you run it with Wait-Debugger enabled, it will not complete and hang in VSCode.
Are you sure that it's not just waiting for the debugger to break?
This looks like an issue in the PowerShell extension. It happens as soon as you step over into ConvertTo-SecureString. I'll have to look into this further but please open an issue on https://github.com/PowerShell/vscode-powershell
Hi. I have some more information on this. ConvertFrom-SecureString fails as well. Here is my tests:
Test 1 - ConvertTo-SecureString: Pass (However debugger cannot step past the cmdlet)
Wait-Debugger
# Let's Create a Secure String :-D
$TestSecureString = "Testing123" | ConvertTo-SecureString -AsPlainText -Force
Test 2 - ConvertTo-SecureString: Failure
# Let's Create a Secure String :-D
$TestSecureString = "Testing123" | ConvertTo-SecureString -AsPlainText -Force
Wait-Debugger
Test 3 - ConvertFrom-SecureString: Failure
# Please note this won't ConvertTo-Secure String since usercontext is different.
#$string = "01000000d08c9ddf0115d1118c7a00c04fc297eb010000009cbb6d7ca83ac044b8943efa8f42406a00000000020000000000106600000001000020000000b739e3d4725e84e7e6ba29ec61859f85801225cb0251c1660044c3f1918476f1000000000e80000000020000200000003c414018ff4ed7803209e80c91fdec757276c523588b7116b5d84ccfddbb40162000000028ff0a3ab2ff8df5d0e15f0ff109c4dd93786a3d601728bc91f916e3a40bd19240000000821660128fc1d013a0fda8c2c1f0035a21471d652e4af07f3698a873b38062000513e43f6cb5f014c8073b278f57e4e87bbdfd7b044b234872d1595b73563758"
#$ss = $string | ConvertTo-SecureString
Wait-Debugger
I can confirm this behavior on my end as well are there any known workarounds ?
One more piece of info to expand on the example provided by @ZanattaMichael as I think this could be related to assignment of a secure string vs the actual converto-securestring cmdlet ? Take for example the following slightly modified scenarios which are both working inside azure functions / debugged locally:
This example has an error (empty string), however the debugger is able to continue onto next line (it just complains about the empty string)....
Wait-Debugger
# Let's Create a Secure String :-D
$TestSecureString = "" | ConvertTo-SecureString -AsPlainText -Force
In a similar fashion, if you don't capture the string, the debugger is able to continue, business as usual:
Wait-Debugger
# Let's Create a Secure String :-D
"Test" | ConvertTo-SecureString -AsPlainText -Force
The weird thing is that the code provided by @eamonoreilly and @ZanattaMichael is working just fine when debugged in vscode using the same powershell extension with "no configurations"

with "no configurations"
This just means it launches the script and runs it in the Integrated Console below with debugging.
From my experience, this issue only serviced in the attach debugging scenario.
This is going to be a very strange sounding workaround...
But when you see this hang, can you just press Ctrl+C twice and see if it gets out of a bad state?
@TylerLeonhardt, gave this workaround a try but unless i am doing something wrong (i.e. my focus is on the wrong vscode window) I dont think pressing Ctrl+C twice helped getting me out of this bad state.
I tried this while my focus was on the main terminal window and the result was that my debug session was terminated (pipe was broken).
@invisibleaxm what OS are you using?
@TylerLeonhardt once again thanks for your time at ignite, after coming back I tried with the Powershell (Preview) extension for vscode (on windows) and the work-around you mentioned seems to be working. It is not ideal but definitely helps me work-around this issue and will speed things up for us.
Thanks again!
So glad that works for you @invisibleaxm! I hope our chat at Ignite has helped in understanding how non-trivial this bug is. That said, it's my top priority once the code in the PowerShell Preview ext has made it into the PowerShell stable one!