Repository navigation
Parallel Powershell sessions lead to corruption of the StartUpProfileData cache created by ProfileOptimization.StartProfile #121977
Description
Description
We PowerShell team got a new report about the profile data created by ProfileOptimization.StartProfile got corrupted by parallel PowerShell session started by pwsh -command. This happened on macOS and GitLab runners with PowerShell v7.5.4, which runs on top of .NET 9.0.
Please see the detailed bug report in the PowerShell issue, including a .ips crash report collected on macOS.
I reported a similar issue #81799 a couple years back, and that was fixed in .NET 9.0. However, this still happens on .NET 9, indicating that the root cause may be different. /cc @mangod9 and @kouvel from #81799.
Reproduction Steps
The PowerShell issue PowerShell/PowerShell#26528 has the repro script.
Expected behavior
The profile file created by parallel PowerShell doesn't get corrupted.
Actual behavior
The profile seems corrupted by parallel PowerShell session.
Regression?
It could be a regression. We didn't hear the same issue before.
Known Workarounds
There is no workaround. Deleting the profile can temporarily fix the issue, but the next parallel run of PowerShell may run into the same issue.
Configuration
Which version of .NET is the code running on?
.NET 9
What OS and version, and what distro if applicable?
GitLab runners on macOS that don't use any sort of virtualization
Other information
No response
Activity
dotnet-policy-service commentedon Nov 26, 2025
Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.
agocke commentedon Jan 23, 2026
@kg Could you take a quick look and see if it's the same or similar to the issue you fixed for 9?
kg commentedon Jan 23, 2026
This looks like a different bug. It is most likely a race condition between processes all sharing the same profile data file. Off-hand I don't know what the best fix would be other than trying to protect against the race with some sort of system wide mutex and silently skipping MCJ if the mutex can't be acquired.
agocke commentedon Jan 23, 2026
@AndyAyersMS @davidwrighton I can't tell, is this intended use of this API? Is it supposed to be concurrency-safe?
gobenausnice commentedon Feb 5, 2026
I added the same comment in the Powershell threaad that lead to this issue being created. We experienced this on a production system with several thousand servers where pwsh commands are executed by Nagios. In scenarios where multiple checks are launched at the same time, we ended up with cache corruption and thousands of alerts with the 'An error has occurred that was not properly handled...'. We had thousands of alerts all of a sudden. The pwsh commands are run by a local nrpe user with the non-interactive profile. We were able to mitigate it by creating separate cache files for checks and putting a flock command and by setting up a custom cache file. Creating an exclusive lock on the file only works if the pwsh command executed afterwards returns quickly -- at least in our scenario. Otherwise the monitors time out waiting for a lock if too many pile up. What are the chances of getting this addressed? It really makes pwsh a poor choice in monitoring scenarios where multiple processes can be a common occurrence. As I said in my post on the PS forum, this problem was not as pronounced in version 7.4.x. We did experience the occasional issue but were able to contain it by just clearing the cache twice a day with cron job. After the upgrade to 7.5.x it was a major issue.
ci: avoid shared PowerShell startup-profile corruption
fix(terraform): adopt mapotf 0.1.12 module source resolution (#108)
Start pwsh host wrappers off the shared startup JIT profile (#144)