Open kwill-MSFT opened 3 years ago
Thank you @kwill-MSFT.
A few more details:
C:\Users\xxx\Documents\PowerShell\Modules
and C:\Program Files\PowerShell\Modules
folders to the process-scoped PSModulePath
environment variable. These folders are usually automatically added by the stand-alone pwsh.exe
, but we don't use the stand-alone pwsh.exe
in the worker, and the worker sets its own PSModulePath
value explicitly (the first value in the the traces is the correct one). Apparently, the code path we hit when the second runspace is created modifies PSModulePath
again. But I don't see that in the worker code, so this must be happening in the PowerShell SDK. We need to find a way to suppress this.Workarounds:
PSModulePath
in profile.ps1
may work as well, but this is less reliable because the variable is process-scoped, and modules may be imported by multiple concurrent function invocations any time, so having PSModulePath
set incorrectly even for a short time interval creates an opportunity for something to break again.
Repro steps
"schedule": "*/1 * * * * *"
Start-Sleep -Seconds 5
into the code for both timer functions. This ensures they both try to execute simultaneously."PSWorkerInProcConcurrencyUpperBound": "2"
Result:
The first time profile.ps1 executes, PSModulePath is correct and only shows a single Az.Resources module available.
The second time profile.ps1 executes, PSModulePath includes 'C:\Users\xxx\Documents\PowerShell\Modules' and results in 2 available Az.Resources modules available. This then results in the FileLoadException.
This can be worked around by manually setting the $env:PSModulePath in profile.ps1 prior to the Import-Module line.