Parallel Powershell Sessions Lead to Corruption of the StartUpProfileData Cache

[JulianHangstoerferEnscape]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

We are using powershell core as the execution shell for self-managed GitLab runners on macOS that don't use any sort of virtualization. Some of these machines can execute up to 5 jobs in parallel for very light workloads. For each job a non-interactive powershell session is launched, and exited again once the job is complete. These parallel jobs are corrupting the ~/.cache/powershell/StartupProfileData-NonInteractive cache file, which then causes a meriad of issues like load assembly errors, segfeaults and stackoverflows until the cache is fixed. Deleting the file fixes the problem temporarily but it will eventually come back.

I have managed to boil down the issue into a small powershell script to simulate the parallel nature of our GitLab runners. We do not run 64 jobs in parallel but it hopefully speeds up the reproduction of the problem. This is not a perfect reproduction of the problem, because when running so many session in parallel it guarantees that the corrupted cache instantly gets overriden by a different powershell session and thus the problem is fixed again. On our real runners it's likely that just 2 parallel powershell session clash with eachother and leave the corrupted cache on the filesystem.

Running this on macOS can take between 1 and 300 tries for me to reproduce the problem.

$parallelJobs = 64
$iteration = 0
while ($true) {
    $iteration++
    Write-Host "Iteration $iteration"

    $results = 1..$parallelJobs | ForEach-Object -Parallel {
        # This parallel start of pwsh is the actual problem.
        $output = pwsh -NonInteractive -Command {
            # Simulate some work
            foreach ($item in 1..10) {
                [Math]::Sqrt($item) | Out-Null
            }
        } 2>&1
        return [PSCustomObject]@{
            Output = $output
            ExitCode = $LASTEXITCODE
        }
    } -ThrottleLimit $parallelJobs

    # Print errors
    $errorResults = $results | Where-Object { $_.ExitCode -ne 0 }
    foreach ($result in $errorResults) {
        $exitCode = $result.ExitCode
        $output = $result.Output -join "`n"
        Write-Host
        if ($exitCode -eq 139) {
            Write-Host "Segmentation fault (139) in job. Output:`n$output"
        } elseif ($exitCode -eq 134) {
            Write-Host "Sigabort (134, cache corruption) in job. Output:`n$output"
        } else {
            Write-Host "Unknown error ($exitCode) in job. Output:`n$output"
        }
    }
}

Workarounds

1. Deleting the corrupt cache file ~/.cache/powershell/StartupProfileData-NonInteractive fixes the problem temporarily until it becomes corrupt again.
2. Setting $Env:PSModuleAnalysisCachePath or $Env:XDG_CACHE_HOME to something unique per parallel runner likely solves the problem to avoid parallel access to the cache files.
3. Making the cache file readonly prevents corruption but might not be appropriate for all use-cases. This also might not work when running powershell as root.

   chmod -w ~/.cache/powershell/StartupProfileData-NonInteractive

Expected behavior

Parallel non-interactive powershell sessions can be executed without problems.

Actual behavior

Parallel non-interactive powershell sessions interfere with each other by corrupting the profile cache, which prevents new sessions from being started. It's not even possible to run pwsh -c Write-Host "foo" on the agent when the cache is corrupt.

Error details

Get-Error itself does not print anything there are multiple other errors.

1. pwsh exits with 134 SIGABRT. This is accompied by an error like below with a random assembly that usually contains some corruption. Usually the front or back of the string is truncated or possibly showing random unicode characters like PublicKeyToken=b03f5f7f11ﾰ.
   There is an attached crash report of this happening.

# Output from the reproduction script
Iteration 156

Sigabort (134, cache corruption) in job. Output:

An error has occurred that was not properly handled. Additional information is shown below. The PowerShell process will exit.
Unhandled exception. System.IO.FileLoadException: The given assembly name was invalid.
File name: 'System.Runtime.Numerics, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11ﾠ'
   at System.Reflection.AssemblyNameParser.Parse(ReadOnlySpan`1 name)
   at System.Reflection.AssemblyName.ParseAsAssemblySpec(Char* pAssemblyName, Void* pAssemblySpec)
Iteration 157

2. pwsh exits with 134 SIGABRT. This is accompied by a stackoverflow. This seems to be related to this bug Stack overflow error and SIGABRT due to corrupted cache #26431
   Unfortunately this does not seem to create crash reports on macOS.

# Output from the reproduction script
Iteration 190

Sigabort (134, cache corruption) in job. Output:
Stack overflow.

Sigabort (134, cache corruption) in job. Output:
Stack overflow.
Iteration 191

3. pwsh exits with 139 segmentation fault and no output. I'm not sure if this is also due to the corrupt cache, in GitLab our problems always manifested itself with either the assembly load errors and rarely the stackoverflow.
   There is an attached crash report of this happening.

# Output from the reproduction script
Iteration 77

Segmentation fault (139) in job. Output:

Iteration 78

Environment data

$PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.5.4
PSEdition                      Core
GitCommitId                    7.5.4
OS                             Darwin 25.0.0 Darwin Kernel Version 25.0.0: Wed Sep 17 21:39:53 PDT 2025; root:xnu-1237…
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

                     ..'          
                 ,xNMM.           -------------------
               .OMMMMo            OS: macOS Tahoe 26 26.0.1 x86_64
               lMM"               Host: iMac (Retina 5K, 27-inch, 2020)
     .;loddo:.  .olloddol;.       Kernel: Darwin 25.0.0
   cKMMMMMMMMMMNWMMMMMMMMMM0:     Uptime: 12 hours, 29 mins
 .KMMMMMMMMMMMMMMMMMMMMMMMWd.     Packages: 118 (brew), 5 (brew-cask)
 XMMMMMMMMMMMMMMMMMMMMMMMX.       Shell: zsh 5.9
;MMMMMMMMMMMMMMMMMMMMMMMM:        Display (iMac): 5120x2880 @ 60 Hz (as 2560x1440) in 27" [Built-in]
:MMMMMMMMMMMMMMMMMMMMMMMM:        DE: Aqua
.MMMMMMMMMMMMMMMMMMMMMMMMX.       WM: Quartz Compositor 341.0.1
 kMMMMMMMMMMMMMMMMMMMMMMMMWd.     WM Theme: Multicolor (Light)
 'XMMMMMMMMMMMMMMMMMMMMMMMMMMk    Font: .AppleSystemUIFont [System], Helvetica [User]
  'XMMMMMMMMMMMMMMMMMMMMMMMMK.    Cursor: Fill - Black, Outline - White (32px)
    kMMMMMMMMMMMMMMMMMMMMMMd      Terminal: /dev/ttys002
     ;KMMMMMMMWXXWMMMMMMMk.       CPU: Intel(R) Core(TM) i7-10700K (16) @ 3.80 GHz
       "cooc*"    "*coo'"         GPU 1: AMD Radeon Pro 5500 XT [Integrated]
                                  GPU 2: Intel HD Graphics CFL [Integrated]
                                  Memory: 5.15 GiB / 8.00 GiB (64%)
                                  Swap: 58.25 MiB / 1.00 GiB (6%)
                                  Disk (/): 350.46 GiB / 465.63 GiB (75%) - apfs [Read-only]
                                  Locale: C.UTF-8

It's also reproducible on a m1 and a m4 mac but it seems more difficult to corrupt.

$PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.5.4
PSEdition                      Core
GitCommitId                    7.5.4
OS                             Darwin 25.0.0 Darwin Kernel Version 25.0.0: Wed Sep 17 21:41:39 PDT 2025; root:xnu-12377.1.9~141/RELEASE_ARM64_T8103
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

                     ..'          
                 ,xNMM.           --------------------
               .OMMMMo            OS: macOS Tahoe 26 26.0.1 arm64
               lMM"               Host: MacBook Air (M1, 2020)
     .;loddo:.  .olloddol;.       Kernel: Darwin 25.0.0
   cKMMMMMMMMMMNWMMMMMMMMMM0:     Uptime: 12 hours, 42 mins
 .KMMMMMMMMMMMMMMMMMMMMMMMWd.     Packages: 172 (brew), 10 (brew-cask)
 XMMMMMMMMMMMMMMMMMMMMMMMX.       Shell: zsh 5.9
;MMMMMMMMMMMMMMMMMMMMMMMM:        Display (Color LCD): 2880x1800 @ 60 Hz (as 1440x900) in 13" [Built-in]
:MMMMMMMMMMMMMMMMMMMMMMMM:        DE: Aqua
.MMMMMMMMMMMMMMMMMMMMMMMMX.       WM: Quartz Compositor 341.0.1
 kMMMMMMMMMMMMMMMMMMMMMMMMWd.     WM Theme: Multicolor (Light)
 'XMMMMMMMMMMMMMMMMMMMMMMMMMMk    Font: .AppleSystemUIFont [System], Helvetica [User]
  'XMMMMMMMMMMMMMMMMMMMMMMMMK.    Cursor: Fill - Black, Outline - White (32px)
    kMMMMMMMMMMMMMMMMMMMMMMd      Terminal: /dev/ttys000
     ;KMMMMMMMWXXWMMMMMMMk.       CPU: Apple M1 (8) @ 3.20 GHz
       "cooc*"    "*coo'"         GPU: Apple M1 (8) [Integrated]
                                  Memory: 5.60 GiB / 8.00 GiB (70%)
                                  Swap: 710.44 MiB / 2.00 GiB (35%)
                                  Disk (/): 276.81 GiB / 460.43 GiB (60%) - apfs [Read-only]
                                  Battery (bq20z451): 100% [AC connected]
                                  Power Adapter: 30W USB-C Power Adapter
                                  Locale: C.UTF-8

Visuals

Screenshot of the corruption happening with the repro script:

Screenshot of the corruption happening in GitLab when trying to set up the shell session:

Screenshot of the contents of a corrupted StartupProfileData-NonInteractive with truncated assembly string.

macOS .ips crash report files.
macOS crash report.zip

Screenshot of a stacktrace from the macOS crash reports

[jborean93]

This might have to be reported to .NET as the profile optimisation in PowerShell is done by the System.Runtime. ProfileOptimization class in the BCL. You can see this call is at

PowerShell/src/Microsoft.PowerShell.ConsoleHost/host/msh/ConsoleHost.cs

Line 320 in b9ff1da

ProfileOptimization.StartProfile("StartupProfileData-NonInteractive");

It could be that this call isn't safe to run in parallel but the .NET maintainers will probably have to share their recommendations here.

[iSazonov]

It looks like edge race condition. So I agree this should be reported to .Net Runtime repository.

[daxian-dbw]

I've opened the issue dotnet/runtime#121977, and let's see what the runtime folks say about it.

I opened a similar issue a couple of years back dotnet/runtime#81799, and it was fixed in .NET 9. However, PowerShell v7.5.4 runs on .NET 9, so this issue could be a different root cause.

[JulianHangstoerferEnscape]

We have settled on a workaround for our GitLab runners, making the cache file readonly seems to be the best solution for us.
We did not find a way to easily split up the cache files for each parallel runner since we can't seemingly configure the environment variables on that level via the GitLab configuration.

Locking the cache to be readonly is also appropriate for our use-case because these runners will execute a lot of the samey jobs over and over again and it's unlikely that the cache would need to be refreshed.

This is enough to prevent cache corruption, I'l add it to the workarounds in my main post.

chmod -w ~/.cache/powershell/StartupProfileData-NonInteractive

[AndrewSav]

chmod -w ~/.cache/powershell/StartupProfileData-NonInteractive

If PowerShell porcess is running as root the above command does not deter it from writing cache and hitting this bug. In docker containers I had to use gosu/su-exec to drop the root so that this workaround actually worked

[technomancer-101]

chmod -w ~/.cache/powershell/StartupProfileData-NonInteractive

If PowerShell porcess is running as root the above command does not deter it from writing cache and hitting this bug. In docker containers I had to use gosu/su-exec to drop the root so that this workaround actually worked

I discovered this the other day as well. I haven't had time to rework my environment to avoid using root, so I used chattr -i to make the cache immutable for the time being. root has the power to remove the immutable flag, but it will respect it as long as it is set.

[gobenausnice]

This issue seems to have become significantly worse with an upgrade to pwsh 7.5.x. We upgraded from 7.4.x. to 7.5.3. We experienced issues with cache corruption before but were able to contain the problem to a large degree by deleting the cache file twice a day. We use pwsh to run checks that are executed by Nagios. After the upgrade to 7.5.3 on production systems, we received thousands of alerts because powershell failed to start. We mitigated the problem by creating separate cache files to reduce the likelyhood that two processes have to mess with the same cache file at the same time. In addition, we launched our short running checks by putting a lock on the cache file by preceding the pwsh command with a flock statement to create a lock on the file. That approach only works if the pwsh commands returns < 1 second and you know that the maximum concurrency will be < 10 concurrent processes at most. Otherwise, checks will back up behind each other waiting for the lock to be released and time out. This problem really needs to be fixed in the .runtime. These workarounds are fine on a workstation or laptop but are a massive pain to deal with if you are dealing with a few thousand servers in a production system.

[iSazonov]

I think the race condition is mostly for interactive (not server) pwsh mode. I mean it is in the ProfileOptimization.StartProfile("StartupProfileData-Interactive"); code (but not StartupProfileData-ServerMode, StartupProfileData-SSHServerMode, NamedPipe, V2SocketServerMode, SocketServerMode.

Possible ways to mitigate the issue:

1. Wait infinitely fix in .Net Runtime
2. Since we already use PublishReadyToRun we could use PublishReadyToRunComposite in PowerShell.Common.props file
3. For short lived sessions (if command line has -File or -Command parameter and hasn't -NoExit) we could not call ProfileOptimization.StartProfile("StartupProfileData-Interactive"); .
4. Introduce new command line parameter(s) to disable ProfileOptimization.StartProfile() or/and point custom folder for the JIT profile (so that user can make the profile readonly or disable it). Alternative - new env variable.
5. Remove ProfileOptimization.StartProfile("StartupProfileData-Interactive"); at all since we use R2R (PublishReadyToRun, TieredCompilationQuickJit, TieredCompilationQuickJitForLoops in csproj files) and it is a question how many benefits we have with ProfileOptimization.StartProfile() in the case.