Closed HeKr09 closed 9 months ago
Anyone an idea?
@HeKr09 could you try the following and share the output?
$env:BICEP_TRACING_ENABLED="true"
-Verbose
flag:
New-AzResourceGroupDeployment -TemplateFile $resourceTemplate.FullName -TemplateParameterFile "parameters.$CustomerName.json" -ResourceGroupName $resourceGroup.ResourceGroupName -Verbose
Yes, same here, as referenced at https://github.com/Azure/bicep/issues/10350#issuecomment-1831547335
I found changing vscode to use powershell5.1 instead of pscore got it working again. You'll notice a hung bicep.exe process, that's what's stalling the deployment?
@lansalot it would be interesting to see if there's any difference in using .bicepparam
files - the Bicep CLI is invoked in a slightly different manner (using stdout, rather than writing a temporary file).
If you're able to:
Create a main.bicepparam
file with contents:
using 'main.bicep'
param foo = 'foo'
Create a main.bicep
file with contents:
param foo string
output foo string = foo
$env:BICEP_TRACING_ENABLED = "true"
$rgName = "" #replace this with an RG name
New-AzResourceGroupDeployment -TemplateParameterFile "main.bicepparam" -ResourceGroupName $rgName -Verbose
@anthony-c-martin I followed your steps. Same output than before:
VERBOSE: Using Bicep v0.23.1
VERBOSE: Calling Bicep with arguments: build "PATHTOBICEP" --outdir "C:\Users\my.user\AppData\Local\Temp\281977cc-4340-4668-8e43-4d1f45d920c9"
Got stuck. I waited five minutes...
@anthony-c-martin
Same with .bicepparam
.
I just wonder about the following. I run the following within my PowerShell:
Import-Module -Name Az -RequiredVersion 11.1.0 -Force
New-AzResourceGroupDeployment -ResourceGroupName "RG" -TemplateParameterFile "TemplateParam.bicepparam" -TemplateFile "Template.bicep" -Verbose
I just wonder about the fact that I am typing the Az cmdlet and when I have got this line printed:
New-AzResourceGroupDeployment -ResourceGroupName "RG" -TemplateParameterFile "TemplateParam.bicepparam"
When I then press TAB to see the other parameters my whole PowerShell got stuck. I can't click anything...
Anyone an idea?
One thing that's especially odd here - I can tell from your logs that the cmdlet was able to invoke Bicep successfully the first time (VERBOSE: Using Bicep v0.23.1
) to obtain the version number, so this isn't a generic issue with the mechanism we use to invoke bicep.exe.
I can't think of anything significantly different in the way the cmdlet invokes Bicep the 2nd time (to perform the build), so something like WDAC blocking certain operations (e.g. file I/O) feels like a plausible explanation. Unfortunately this is not my area of expertise. If you have the time, it might be worth trying to follow this guide to see if there's anything to indicate a WDAC issue.
@HeKr09 https://github.com/PowerShell/PowerShell/issues/20785 feels possibly related. Could you try and repro this after running the following in the same powershell window:
$ExecutionContext.SessionState.LanguageMode = 'FullLanguage'
@anthony-c-martin I followed the guide and could not detect any errors. I also set the LanguageMode and got the same output and behavior than before.
Currently I am using PowerShell 7.3.10. According to your #20785 the problem occurs with 7.4.0 and the user should roll back to 7.3.10. So this does not to seem the problem. Also with Az 10.4.1 everything works fine, :(
Hello everyone! I am having the same problem with:
What I also noticed was that:
Has anyone found a solution to that?
the same here.
New-AzResourceGroupDeployment and New-AzSubscriptionDeployment have suddenly stopped working in the mid of the day. Last verbose messages
VERBOSE: Using Bicep v0.24.24
VERBOSE: Calling Bicep with arguments: build ...
However, if i run bicep with the same params outside of VSCode, it works fine.
I've noticed from Sysinternals Process Explorer process tree last process conhost.exe is hanging code.exe -- pwsh.exe ---- bicep.exe ------ conhost.exe (\??\C:\WINDOWS\system32\conhost.exe 0x4)
@OlehGap that's very helpful. Is it possible to see the cli arguments that conhost was invoked with?
The only thing that comes to mind for me is that the sdk we use for Azure auth invokes AzCLI or AzPwsh via shell to obtain an auth token.
Are you using template spec or module registry modules anywhere in your deployment?
@anthony-c-martin, nothing fancy here, just developing sub modules
` $VerbosePreference = 'Continue'
$InformationPreference = 'Continue'
New-AzResourceGroupDeployment -ResourceGroupName $rgName -TemplateFile .\Modules\resourceGroup-RoleAssignments.bicep -DeploymentDebugLogLevel All -Pre -roleDefinitionIdOrName 'Custom1' -principalId $principalId `
I guess, I've found the issue - bicep gets stuck on big files. The deployment worked until I copied _builtInRoleNamesvar from CARML/AVM/BRM repos to include all Azure built-in roles into my module.
Once I reduced the number of roles, the deployment went back to normal.
Turns out bicep.exe cannot ingest those extra 35KB of data
Once I reduced the number of roles, the deploy Turns out bicep.exe cannot ingest those extra 35KB of data
That's a helpful data point! If you invoke the Bicep build command directly with the same parameters that the AzPwsh command does, do you see the same behavior?
That's correct. New-AzResourceGroupDeployment - hangs on calling bicep ( with extra child process - see a screenshot in my first post) Executing bicep.exe directly with the same params works as a charm.
I presume the settings are different. bicepconfig.json or some file in .bicep folders ???
The Bicep CLI command is executed exactly the same way via Azure PowerShell - there should be no difference in arguments or settings passed in.
I suspect we may be running into the deadlock condition described under https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.process.standardoutput?view=net-8.0&redirectedfrom=MSDN#remarks.
EDIT: Ruled this out - we actually run into this problem when not using stdout.
@OlehGap if you get a chance, could you test out using a .bicepparam
file without referencing the .bicep
file in the cmdlet with the -TemplateFile
parameter?
For example, something like:
New-AzResourceGroupDeployment -ResourceGroupName $rgName -TemplateParameterFile .\Modules\resourceGroup-RoleAssignments.bicepparam
Where your .bicepparam file could be:
using './resourceGroup-RoleAssignments.bicepparam'
// fill these out with your parameter values
param roleDefinitionIdOrName = ...
param principalId = ...
Building a .bicep
file requires us to create a temporary directory and write to disk, whereas building a .bicepparam
file doesn't have this dependency. This would allow us to rule in / out writing to disk as the cause.
Does anyone has a solution yet?
@HeKr09 if you're able to answer my previous comment, that would help us figure out the solution.
@anthony-c-martin
Half win: The PowerShell got stuck when using TAB to get the next parameter. Nevertheless the PowerShell ran after I wrote it myself:
New-AzResourceGroupDeployment -ResourceGroupName "TEST_RG" -TemplateParameterFile '.\parameters.TEST.bicepparam' -Verbose
The output:
VERBOSE: Using Bicep v0.23.1
VERBOSE: Calling Bicep with arguments: build-params "D:\Customer Templates\Test\Bicep\parameters.Test.bicepparam" --stdout
VERBOSE: Performing the operation "Creating Deployment" on target "TEST_RG".
VERBOSE: Using Bicep v0.23.1
VERBOSE: Calling Bicep with arguments: build-params "D:\Customer Templates\Test\Bicep\parameters.Test.bicepparam" --stdout
WARNING: D:\Customer Templates\Test\Bicep\templateLogicApp.Test.bicep(25,8) : Warning explicit-values-for-loc-params: Parameter 'location' of module 'ModuleConnections' isn't assigned an explicit value, and its default value may not give the intended behavior for a location-related parameter. You should assign an explicit value to the parameter. [https://aka.ms/bicep/linter/explicit-values-for-loc-params]
VERBOSE: 06:11:28 - Template is valid.
VERBOSE: 06:11:29 - Create template deployment '3ad712ee-e079-4737-a87a-2513417423b0'
VERBOSE: 06:11:29 - Checking deployment status in 5 seconds
VERBOSE: 06:11:35 - Resource Microsoft.Resources/deployments 'connectionsDeploy' provisioning status is running
VERBOSE: 06:11:35 - Checking deployment status in 14 seconds
VERBOSE: 06:11:50 - Resource Microsoft.Resources/deployments 'connectionsDeploy' provisioning status is succeeded
VERBOSE: 06:11:50 - Resource Microsoft.Web/connections 'office365' provisioning status is succeeded
VERBOSE: 06:11:50 - Resource Microsoft.Web/connections 'keyvault' provisioning status is succeeded
VERBOSE: 06:11:50 - Resource Microsoft.Web/connections 'azuread' provisioning status is succeeded
VERBOSE: 06:11:50 - Resource Microsoft.Web/connections 'azurequeues' provisioning status is succeeded
VERBOSE: 06:11:50 - Resource Microsoft.Web/connections 'azurequeues-1' provisioning status is succeeded
VERBOSE: 06:11:50 - Resource Microsoft.Web/connections 'sharepointonline' provisioning status is succeeded
VERBOSE: 06:11:50 - Resource Microsoft.Resources/deployments 'connectionsDeploy' provisioning status is succeeded
DeploymentName : 3ad712ee-e079-4737-a87a-2513417423b0
ResourceGroupName : TEST_RG
ProvisioningState : Succeeded
Timestamp : 31.01.2024 05:11:47
Mode : Incremental
TemplateLink :
Parameters :
[SOMEHERE]
Outputs :
DeploymentDebugLogLevel :
But: WHY?!?!?! Can anybody explain? Is this a bug in the module?
But: WHY?!?!?! Can anybody explain? Is this a bug in the module?
I'm still puzzled to be honest, but this gives me more confidence that #23997 may fix the problem.
The -ParameterFile
argument without the -TemplateFile
invokes the Bicep CLI, using the --stdout
option, and reads the compiled template back via stdout.
The -TemplateFile
argument invokes the Bicep CLI, but creates a temporary file on disk and then reads it back (rather than using --stdout
). My change switches this cmdlet to instead use --stdout
.
@wyunchi-ms is there a way to obtain a nightly/prerelease version of the cmdlet to test this out?
Just checked with the latest az.resources 6.15.0. This seems to have the --stdout flag implemented in your pr. But it still hangs on the bicep build.
See my output below:
PS C:\Users\xxx\Azure_devops\azure-resources> import-module az.resources -requiredVersion 6.15.0
PS C:\Users\xxx\Azure_devops\azure-resources> new-azsubscriptionDeployment -resourcegroupname xxx-it-weu-xxx-2001 -location westeurope -TemplateFile .\
modules\Microsoft.Storage\storageAccounts\.test\common\deploy.test.bicep -Verbose
VERBOSE: Using Bicep v0.23.1
VERBOSE: Calling Bicep with arguments: build "C:\Users\xxx\Azure_devops\azure-resources\modules\Microsoft.Storage\storageAccounts\.test\common\deploy.test.
bicep" --stdout
@JoranSlingerland thanks for sharing - at least we can rule out the "file writing" logic as the root cause I guess... 😞
So we're back to square one... Since I'm unable to reproduce this myself, I think the next step of investigation would be to try and capture a memory dump of the process:
@anthony-c-martin I've send you an email from my @achmea.nl work email with the memory dump.
I've also checked when the issues seems to be introduced and I've found that az.resources 6.11.1 still works but 6.11.2 doesn't work anymore.
@JoranSlingerland thank you very much! Here's where the application appears to have hung:
Searching for the call stack doesn't turn up much; https://github.com/dotnet/runtime/issues/97496 seems possibly related.
In Bicep 0.25.3 (released yesterday) we switched from using .NET7 to .NET8 - could you try using this version of Bicep in case it makes a difference?
@anthony-c-martin I've tried running on 0.25.3 but this still gives the same issue. I've send you another email with the dump file. See the powershell console output below:
PowerShell 7.4.1
PS C:\Users\xxx\Azure_devops\azure-resources> new-azsubscriptionDeployment -resourcegroupname xxx-it-weu-xxx-2001 -location westeurope -TemplateFile .\modules\Microsoft.Storage\storageAccounts\.test\common\deploy.test.bicep -Verbose
VERBOSE: Using Bicep v0.25.3
VERBOSE: Calling Bicep with arguments: build "C:\Users\xxx\Azure_devops\azure-resources\modules\Microsoft.Storage\storageAccounts\.test\common\deploy.test.bicep" --stdout
@JoranSlingerland thank you! I think I've finally figured out what's going on - I've submitted a PR to fix it here: https://github.com/Azure/azure-powershell/pull/24133
The deadlock appears when a large number of errors or warning diagnostics are logged, so a temporary workaround would be to find ways of cutting down the number of diagnostics emitted - for example adding inline suppressions.
@anthony-c-martin thank you for the update and fix! Will see if we can implement the workaround and otherwise wait for a new release.
This has just been released under Az powershell version 11.3.1 - you should be able to update to pick up the fix: https://learn.microsoft.com/en-us/powershell/azure/install-azps-windows#update-the-az-powershell-module
Closing the issue, but please re-open or respond here if you're still having problems.
Description
I am working with bicep templates to deploy some Azure resources. I am using bicep 0.23.1.45101 (install by MSI package if important) and the Az PowerShell module 10.4.1. Everything worked fine. A few weeks ago I wanted to update to the Az version 11.0.0. After the update I tried to ran
New-AzResourceGroupDeployment
. The cmdlet got stuck without any error. I needed to close the session. I had to go back to 10.4.1. Now I wanted to update to 11.1.0. Same problem.Can anybody help?
Issue script & Debug output
Environment data
Module versions
Error output