Fix TOCTOU race in SharedMemoryHelpers.CreateOrOpenFile by lewing · Pull Request #125633 · dotnet/runtime

lewing · 2026-03-16T20:20:44Z

Problem

CreateOrOpenFile uses a two-step open pattern:

open(O_RDWR) — try to open existing file
If ENOENT, open(O_CREAT|O_EXCL) — try to create atomically

If another process creates the file between steps 1 and 2, the O_CREAT|O_EXCL returns EEXIST and the method throws IOException instead of retrying:

System.IO.IOException: The file '/tmp/.dotnet/shm/session1/NuGet-Migrations' already exists.
at System.IO.SharedMemoryHelpers.CreateOrOpenFile(...)
at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name)
at NuGet.Common.Migrations.MigrationRunner.Run(...)
at Microsoft.DotNet.Configurer.DotnetFirstTimeUseConfigurer.Configure()

This is a classic TOCTOU (Time-of-Check-Time-of-Use) race. It's blocking the VMR official build on main — the ValidateInstallers_Linux_x64 job runs dotnet new inside a Docker container where multiple processes may race to create the named mutex file.

Fix

Wrap the open/create logic in a retry loop. When O_CREAT|O_EXCL fails with EEXIST, loop back to try O_RDWR on the now-existing file. Limited to one retry to avoid infinite loops.

Fixes#125632

CreateOrOpenFile uses a two-step pattern: first try open(O_RDWR) to open an existing file, then if ENOENT, try open(O_CREAT|O_EXCL) to create it atomically. However, if another process creates the file between these two calls, the O_CREAT|O_EXCL returns EEXIST and the method throws IOException instead of retrying the open. Fix by wrapping the logic in a retry loop that handles EEXIST from the create attempt by looping back to try opening the existing file. Limited to one retry to avoid infinite loops on persistent errors. Fixes#125632 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-03-16T20:21:43Z

Tagging subscribers to this area: @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

lewing · 2026-03-16T20:22:06Z

Duplicate of #125524 by @steveisok which has the same fix. Closing in favor of that PR.

Copilot

Pull request overview

Fixes a TOCTOU race in Unix shared-memory file creation/opening used by named mutexes by retrying when open(O_CREAT|O_EXCL) loses the race and returns EEXIST, avoiding spurious IOException failures during concurrent dotnet invocations.

Changes:

Wrap open(O_RDWR) + open(O_CREAT|O_EXCL) in a bounded retry loop.
On EEXIST from the create attempt, retry open(O_RDWR) to use the concurrently-created file.

You can also share your feedback on Copilot code review. Take the survey.

+ // Retry loop to handle the TOCTOU race between open(O_RDWR) returning ENOENT
+ // and open(O_CREAT|O_EXCL) returning EEXIST when another process creates the
+ // file in between.
+ for (int retries = 0; ; retries++)


+ if (error.Error == Interop.Error.EEXIST && retries < 1)
+ {
+ // Another process created the file between our open and create attempts.
+ // Retry the open to use the existing file.
+ continue;
+ }


lewing · 2026-03-16T20:20:44Z

Problem

CreateOrOpenFile uses a two-step open pattern:

open(O_RDWR) — try to open existing file
If ENOENT, open(O_CREAT|O_EXCL) — try to create atomically

If another process creates the file between steps 1 and 2, the O_CREAT|O_EXCL returns EEXIST and the method throws IOException instead of retrying:

System.IO.IOException: The file '/tmp/.dotnet/shm/session1/NuGet-Migrations' already exists.
at System.IO.SharedMemoryHelpers.CreateOrOpenFile(...)
at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name)
at NuGet.Common.Migrations.MigrationRunner.Run(...)
at Microsoft.DotNet.Configurer.DotnetFirstTimeUseConfigurer.Configure()

This is a classic TOCTOU (Time-of-Check-Time-of-Use) race. It's blocking the VMR official build on main — the ValidateInstallers_Linux_x64 job runs dotnet new inside a Docker container where multiple processes may race to create the named mutex file.

Fix

Wrap the open/create logic in a retry loop. When O_CREAT|O_EXCL fails with EEXIST, loop back to try O_RDWR on the now-existing file. Limited to one retry to avoid infinite loops.

Fixes#125632

CreateOrOpenFile uses a two-step pattern: first try open(O_RDWR) to open an existing file, then if ENOENT, try open(O_CREAT|O_EXCL) to create it atomically. However, if another process creates the file between these two calls, the O_CREAT|O_EXCL returns EEXIST and the method throws IOException instead of retrying the open. Fix by wrapping the logic in a retry loop that handles EEXIST from the create attempt by looping back to try opening the existing file. Limited to one retry to avoid infinite loops on persistent errors. Fixes#125632 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-03-16T20:21:43Z

Tagging subscribers to this area: @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

lewing · 2026-03-16T20:22:06Z

Duplicate of #125524 by @steveisok which has the same fix. Closing in favor of that PR.

Copilot

Pull request overview

Fixes a TOCTOU race in Unix shared-memory file creation/opening used by named mutexes by retrying when open(O_CREAT|O_EXCL) loses the race and returns EEXIST, avoiding spurious IOException failures during concurrent dotnet invocations.

Changes:

Wrap open(O_RDWR) + open(O_CREAT|O_EXCL) in a bounded retry loop.
On EEXIST from the create attempt, retry open(O_RDWR) to use the concurrently-created file.

You can also share your feedback on Copilot code review. Take the survey.

+ // Retry loop to handle the TOCTOU race between open(O_RDWR) returning ENOENT
+ // and open(O_CREAT|O_EXCL) returning EEXIST when another process creates the
+ // file in between.
+ for (int retries = 0; ; retries++)


+ if (error.Error == Interop.Error.EEXIST && retries < 1)
+ {
+ // Another process created the file between our open and create attempts.
+ // Retry the open to use the existing file.
+ continue;
+ }


lewing · 2026-03-16T20:20:44Z

Problem

CreateOrOpenFile uses a two-step open pattern:

open(O_RDWR) — try to open existing file
If ENOENT, open(O_CREAT|O_EXCL) — try to create atomically

If another process creates the file between steps 1 and 2, the O_CREAT|O_EXCL returns EEXIST and the method throws IOException instead of retrying:

System.IO.IOException: The file '/tmp/.dotnet/shm/session1/NuGet-Migrations' already exists.
at System.IO.SharedMemoryHelpers.CreateOrOpenFile(...)
at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name)
at NuGet.Common.Migrations.MigrationRunner.Run(...)
at Microsoft.DotNet.Configurer.DotnetFirstTimeUseConfigurer.Configure()

This is a classic TOCTOU (Time-of-Check-Time-of-Use) race. It's blocking the VMR official build on main — the ValidateInstallers_Linux_x64 job runs dotnet new inside a Docker container where multiple processes may race to create the named mutex file.

Fix

Wrap the open/create logic in a retry loop. When O_CREAT|O_EXCL fails with EEXIST, loop back to try O_RDWR on the now-existing file. Limited to one retry to avoid infinite loops.

Fixes#125632

CreateOrOpenFile uses a two-step pattern: first try open(O_RDWR) to open an existing file, then if ENOENT, try open(O_CREAT|O_EXCL) to create it atomically. However, if another process creates the file between these two calls, the O_CREAT|O_EXCL returns EEXIST and the method throws IOException instead of retrying the open. Fix by wrapping the logic in a retry loop that handles EEXIST from the create attempt by looping back to try opening the existing file. Limited to one retry to avoid infinite loops on persistent errors. Fixes#125632 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-03-16T20:21:43Z

Tagging subscribers to this area: @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

lewing · 2026-03-16T20:22:06Z

Duplicate of #125524 by @steveisok which has the same fix. Closing in favor of that PR.

Copilot

Pull request overview

Fixes a TOCTOU race in Unix shared-memory file creation/opening used by named mutexes by retrying when open(O_CREAT|O_EXCL) loses the race and returns EEXIST, avoiding spurious IOException failures during concurrent dotnet invocations.

Changes:

Wrap open(O_RDWR) + open(O_CREAT|O_EXCL) in a bounded retry loop.
On EEXIST from the create attempt, retry open(O_RDWR) to use the concurrently-created file.

You can also share your feedback on Copilot code review. Take the survey.

+ // Retry loop to handle the TOCTOU race between open(O_RDWR) returning ENOENT
+ // and open(O_CREAT|O_EXCL) returning EEXIST when another process creates the
+ // file in between.
+ for (int retries = 0; ; retries++)


+ if (error.Error == Interop.Error.EEXIST && retries < 1)
+ {
+ // Another process created the file between our open and create attempts.
+ // Retry the open to use the existing file.
+ continue;
+ }


lewing · 2026-03-16T20:20:44Z

Problem

CreateOrOpenFile uses a two-step open pattern:

open(O_RDWR) — try to open existing file
If ENOENT, open(O_CREAT|O_EXCL) — try to create atomically

If another process creates the file between steps 1 and 2, the O_CREAT|O_EXCL returns EEXIST and the method throws IOException instead of retrying:

System.IO.IOException: The file '/tmp/.dotnet/shm/session1/NuGet-Migrations' already exists.
at System.IO.SharedMemoryHelpers.CreateOrOpenFile(...)
at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name)
at NuGet.Common.Migrations.MigrationRunner.Run(...)
at Microsoft.DotNet.Configurer.DotnetFirstTimeUseConfigurer.Configure()

This is a classic TOCTOU (Time-of-Check-Time-of-Use) race. It's blocking the VMR official build on main — the ValidateInstallers_Linux_x64 job runs dotnet new inside a Docker container where multiple processes may race to create the named mutex file.

Fix

Wrap the open/create logic in a retry loop. When O_CREAT|O_EXCL fails with EEXIST, loop back to try O_RDWR on the now-existing file. Limited to one retry to avoid infinite loops.

Fixes#125632

CreateOrOpenFile uses a two-step pattern: first try open(O_RDWR) to open an existing file, then if ENOENT, try open(O_CREAT|O_EXCL) to create it atomically. However, if another process creates the file between these two calls, the O_CREAT|O_EXCL returns EEXIST and the method throws IOException instead of retrying the open. Fix by wrapping the logic in a retry loop that handles EEXIST from the create attempt by looping back to try opening the existing file. Limited to one retry to avoid infinite loops on persistent errors. Fixes#125632 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-03-16T20:21:43Z

Tagging subscribers to this area: @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

lewing · 2026-03-16T20:22:06Z

Duplicate of #125524 by @steveisok which has the same fix. Closing in favor of that PR.

Copilot

Pull request overview

Fixes a TOCTOU race in Unix shared-memory file creation/opening used by named mutexes by retrying when open(O_CREAT|O_EXCL) loses the race and returns EEXIST, avoiding spurious IOException failures during concurrent dotnet invocations.

Changes:

Wrap open(O_RDWR) + open(O_CREAT|O_EXCL) in a bounded retry loop.
On EEXIST from the create attempt, retry open(O_RDWR) to use the concurrently-created file.

You can also share your feedback on Copilot code review. Take the survey.

+ // Retry loop to handle the TOCTOU race between open(O_RDWR) returning ENOENT
+ // and open(O_CREAT|O_EXCL) returning EEXIST when another process creates the
+ // file in between.
+ for (int retries = 0; ; retries++)


+ if (error.Error == Interop.Error.EEXIST && retries < 1)
+ {
+ // Another process created the file between our open and create attempts.
+ // Retry the open to use the existing file.
+ continue;
+ }


lewing · 2026-03-16T20:20:44Z

Problem

CreateOrOpenFile uses a two-step open pattern:

open(O_RDWR) — try to open existing file
If ENOENT, open(O_CREAT|O_EXCL) — try to create atomically

If another process creates the file between steps 1 and 2, the O_CREAT|O_EXCL returns EEXIST and the method throws IOException instead of retrying:

System.IO.IOException: The file '/tmp/.dotnet/shm/session1/NuGet-Migrations' already exists.
at System.IO.SharedMemoryHelpers.CreateOrOpenFile(...)
at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name)
at NuGet.Common.Migrations.MigrationRunner.Run(...)
at Microsoft.DotNet.Configurer.DotnetFirstTimeUseConfigurer.Configure()

This is a classic TOCTOU (Time-of-Check-Time-of-Use) race. It's blocking the VMR official build on main — the ValidateInstallers_Linux_x64 job runs dotnet new inside a Docker container where multiple processes may race to create the named mutex file.

Fix

Wrap the open/create logic in a retry loop. When O_CREAT|O_EXCL fails with EEXIST, loop back to try O_RDWR on the now-existing file. Limited to one retry to avoid infinite loops.

Fixes#125632

CreateOrOpenFile uses a two-step pattern: first try open(O_RDWR) to open an existing file, then if ENOENT, try open(O_CREAT|O_EXCL) to create it atomically. However, if another process creates the file between these two calls, the O_CREAT|O_EXCL returns EEXIST and the method throws IOException instead of retrying the open. Fix by wrapping the logic in a retry loop that handles EEXIST from the create attempt by looping back to try opening the existing file. Limited to one retry to avoid infinite loops on persistent errors. Fixes#125632 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-03-16T20:21:43Z

Tagging subscribers to this area: @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

lewing · 2026-03-16T20:22:06Z

Duplicate of #125524 by @steveisok which has the same fix. Closing in favor of that PR.

Copilot

Pull request overview

Fixes a TOCTOU race in Unix shared-memory file creation/opening used by named mutexes by retrying when open(O_CREAT|O_EXCL) loses the race and returns EEXIST, avoiding spurious IOException failures during concurrent dotnet invocations.

Changes:

Wrap open(O_RDWR) + open(O_CREAT|O_EXCL) in a bounded retry loop.
On EEXIST from the create attempt, retry open(O_RDWR) to use the concurrently-created file.

You can also share your feedback on Copilot code review. Take the survey.

+ // Retry loop to handle the TOCTOU race between open(O_RDWR) returning ENOENT
+ // and open(O_CREAT|O_EXCL) returning EEXIST when another process creates the
+ // file in between.
+ for (int retries = 0; ; retries++)


+ if (error.Error == Interop.Error.EEXIST && retries < 1)
+ {
+ // Another process created the file between our open and create attempts.
+ // Retry the open to use the existing file.
+ continue;
+ }


lewing · 2026-03-16T20:20:44Z

Problem

CreateOrOpenFile uses a two-step open pattern:

open(O_RDWR) — try to open existing file
If ENOENT, open(O_CREAT|O_EXCL) — try to create atomically

If another process creates the file between steps 1 and 2, the O_CREAT|O_EXCL returns EEXIST and the method throws IOException instead of retrying:

System.IO.IOException: The file '/tmp/.dotnet/shm/session1/NuGet-Migrations' already exists.
at System.IO.SharedMemoryHelpers.CreateOrOpenFile(...)
at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name)
at NuGet.Common.Migrations.MigrationRunner.Run(...)
at Microsoft.DotNet.Configurer.DotnetFirstTimeUseConfigurer.Configure()

This is a classic TOCTOU (Time-of-Check-Time-of-Use) race. It's blocking the VMR official build on main — the ValidateInstallers_Linux_x64 job runs dotnet new inside a Docker container where multiple processes may race to create the named mutex file.

Fix

Wrap the open/create logic in a retry loop. When O_CREAT|O_EXCL fails with EEXIST, loop back to try O_RDWR on the now-existing file. Limited to one retry to avoid infinite loops.

Fixes#125632

CreateOrOpenFile uses a two-step pattern: first try open(O_RDWR) to open an existing file, then if ENOENT, try open(O_CREAT|O_EXCL) to create it atomically. However, if another process creates the file between these two calls, the O_CREAT|O_EXCL returns EEXIST and the method throws IOException instead of retrying the open. Fix by wrapping the logic in a retry loop that handles EEXIST from the create attempt by looping back to try opening the existing file. Limited to one retry to avoid infinite loops on persistent errors. Fixes#125632 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-03-16T20:21:43Z

Tagging subscribers to this area: @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

lewing · 2026-03-16T20:22:06Z

Duplicate of #125524 by @steveisok which has the same fix. Closing in favor of that PR.

Copilot

Pull request overview

Fixes a TOCTOU race in Unix shared-memory file creation/opening used by named mutexes by retrying when open(O_CREAT|O_EXCL) loses the race and returns EEXIST, avoiding spurious IOException failures during concurrent dotnet invocations.

Changes:

Wrap open(O_RDWR) + open(O_CREAT|O_EXCL) in a bounded retry loop.
On EEXIST from the create attempt, retry open(O_RDWR) to use the concurrently-created file.

You can also share your feedback on Copilot code review. Take the survey.

+ // Retry loop to handle the TOCTOU race between open(O_RDWR) returning ENOENT
+ // and open(O_CREAT|O_EXCL) returning EEXIST when another process creates the
+ // file in between.
+ for (int retries = 0; ; retries++)


+ if (error.Error == Interop.Error.EEXIST && retries < 1)
+ {
+ // Another process created the file between our open and create attempts.
+ // Retry the open to use the existing file.
+ continue;
+ }


lewing · 2026-03-16T20:20:44Z

Problem

CreateOrOpenFile uses a two-step open pattern:

open(O_RDWR) — try to open existing file
If ENOENT, open(O_CREAT|O_EXCL) — try to create atomically

If another process creates the file between steps 1 and 2, the O_CREAT|O_EXCL returns EEXIST and the method throws IOException instead of retrying:

System.IO.IOException: The file '/tmp/.dotnet/shm/session1/NuGet-Migrations' already exists.
at System.IO.SharedMemoryHelpers.CreateOrOpenFile(...)
at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name)
at NuGet.Common.Migrations.MigrationRunner.Run(...)
at Microsoft.DotNet.Configurer.DotnetFirstTimeUseConfigurer.Configure()

This is a classic TOCTOU (Time-of-Check-Time-of-Use) race. It's blocking the VMR official build on main — the ValidateInstallers_Linux_x64 job runs dotnet new inside a Docker container where multiple processes may race to create the named mutex file.

Fix

Wrap the open/create logic in a retry loop. When O_CREAT|O_EXCL fails with EEXIST, loop back to try O_RDWR on the now-existing file. Limited to one retry to avoid infinite loops.

Fixes#125632

CreateOrOpenFile uses a two-step pattern: first try open(O_RDWR) to open an existing file, then if ENOENT, try open(O_CREAT|O_EXCL) to create it atomically. However, if another process creates the file between these two calls, the O_CREAT|O_EXCL returns EEXIST and the method throws IOException instead of retrying the open. Fix by wrapping the logic in a retry loop that handles EEXIST from the create attempt by looping back to try opening the existing file. Limited to one retry to avoid infinite loops on persistent errors. Fixes#125632 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-03-16T20:21:43Z

Tagging subscribers to this area: @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

lewing · 2026-03-16T20:22:06Z

Duplicate of #125524 by @steveisok which has the same fix. Closing in favor of that PR.

Copilot

Pull request overview

Fixes a TOCTOU race in Unix shared-memory file creation/opening used by named mutexes by retrying when open(O_CREAT|O_EXCL) loses the race and returns EEXIST, avoiding spurious IOException failures during concurrent dotnet invocations.

Changes:

Wrap open(O_RDWR) + open(O_CREAT|O_EXCL) in a bounded retry loop.
On EEXIST from the create attempt, retry open(O_RDWR) to use the concurrently-created file.

You can also share your feedback on Copilot code review. Take the survey.

+ // Retry loop to handle the TOCTOU race between open(O_RDWR) returning ENOENT
+ // and open(O_CREAT|O_EXCL) returning EEXIST when another process creates the
+ // file in between.
+ for (int retries = 0; ; retries++)


+ if (error.Error == Interop.Error.EEXIST && retries < 1)
+ {
+ // Another process created the file between our open and create attempts.
+ // Retry the open to use the existing file.
+ continue;
+ }


lewing · 2026-03-16T20:20:44Z

Problem

CreateOrOpenFile uses a two-step open pattern:

open(O_RDWR) — try to open existing file
If ENOENT, open(O_CREAT|O_EXCL) — try to create atomically

If another process creates the file between steps 1 and 2, the O_CREAT|O_EXCL returns EEXIST and the method throws IOException instead of retrying:

System.IO.IOException: The file '/tmp/.dotnet/shm/session1/NuGet-Migrations' already exists.
at System.IO.SharedMemoryHelpers.CreateOrOpenFile(...)
at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name)
at NuGet.Common.Migrations.MigrationRunner.Run(...)
at Microsoft.DotNet.Configurer.DotnetFirstTimeUseConfigurer.Configure()

This is a classic TOCTOU (Time-of-Check-Time-of-Use) race. It's blocking the VMR official build on main — the ValidateInstallers_Linux_x64 job runs dotnet new inside a Docker container where multiple processes may race to create the named mutex file.

Fix

Wrap the open/create logic in a retry loop. When O_CREAT|O_EXCL fails with EEXIST, loop back to try O_RDWR on the now-existing file. Limited to one retry to avoid infinite loops.

Fixes#125632

CreateOrOpenFile uses a two-step pattern: first try open(O_RDWR) to open an existing file, then if ENOENT, try open(O_CREAT|O_EXCL) to create it atomically. However, if another process creates the file between these two calls, the O_CREAT|O_EXCL returns EEXIST and the method throws IOException instead of retrying the open. Fix by wrapping the logic in a retry loop that handles EEXIST from the create attempt by looping back to try opening the existing file. Limited to one retry to avoid infinite loops on persistent errors. Fixes#125632 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-03-16T20:21:43Z

Tagging subscribers to this area: @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

lewing · 2026-03-16T20:22:06Z

Duplicate of #125524 by @steveisok which has the same fix. Closing in favor of that PR.

Copilot

Pull request overview

Fixes a TOCTOU race in Unix shared-memory file creation/opening used by named mutexes by retrying when open(O_CREAT|O_EXCL) loses the race and returns EEXIST, avoiding spurious IOException failures during concurrent dotnet invocations.

Changes:

Wrap open(O_RDWR) + open(O_CREAT|O_EXCL) in a bounded retry loop.
On EEXIST from the create attempt, retry open(O_RDWR) to use the concurrently-created file.

You can also share your feedback on Copilot code review. Take the survey.

+ // Retry loop to handle the TOCTOU race between open(O_RDWR) returning ENOENT
+ // and open(O_CREAT|O_EXCL) returning EEXIST when another process creates the
+ // file in between.
+ for (int retries = 0; ; retries++)


+ if (error.Error == Interop.Error.EEXIST && retries < 1)
+ {
+ // Another process created the file between our open and create attempts.
+ // Retry the open to use the existing file.
+ continue;
+ }


lewing added the area-System.Threading label Mar 16, 2026

CopilotAI review requested due to automatic review settings March 16, 2026 20:20

dotnet-policy-serviceBot assigned lewing Mar 16, 2026

lewing closed this Mar 16, 2026

Copilotstarted reviewing on behalf of lewing March 16, 2026 20:23 View session

CopilotAI reviewed Mar 16, 2026
View reviewed changes

github-actionsBot locked and limited conversation to collaborators Apr 16, 2026

jkotas deleted the fix/shared-memory-create-race branch May 22, 2026 17:03

lewing added the area-System.Threading label Mar 16, 2026

CopilotAI review requested due to automatic review settings March 16, 2026 20:20

dotnet-policy-serviceBot assigned lewing Mar 16, 2026

lewing closed this Mar 16, 2026

Copilotstarted reviewing on behalf of lewing March 16, 2026 20:23 View session

CopilotAI reviewed Mar 16, 2026
View reviewed changes

github-actionsBot locked and limited conversation to collaborators Apr 16, 2026

jkotas deleted the fix/shared-memory-create-race branch May 22, 2026 17:03

lewing added the area-System.Threading label Mar 16, 2026

CopilotAI review requested due to automatic review settings March 16, 2026 20:20

dotnet-policy-serviceBot assigned lewing Mar 16, 2026

lewing closed this Mar 16, 2026

Copilotstarted reviewing on behalf of lewing March 16, 2026 20:23 View session

CopilotAI reviewed Mar 16, 2026
View reviewed changes

github-actionsBot locked and limited conversation to collaborators Apr 16, 2026

jkotas deleted the fix/shared-memory-create-race branch May 22, 2026 17:03

lewing added the area-System.Threading label Mar 16, 2026

CopilotAI review requested due to automatic review settings March 16, 2026 20:20

dotnet-policy-serviceBot assigned lewing Mar 16, 2026

lewing closed this Mar 16, 2026

Copilotstarted reviewing on behalf of lewing March 16, 2026 20:23 View session

CopilotAI reviewed Mar 16, 2026
View reviewed changes

github-actionsBot locked and limited conversation to collaborators Apr 16, 2026

jkotas deleted the fix/shared-memory-create-race branch May 22, 2026 17:03

lewing added the area-System.Threading label Mar 16, 2026

CopilotAI review requested due to automatic review settings March 16, 2026 20:20

dotnet-policy-serviceBot assigned lewing Mar 16, 2026

lewing closed this Mar 16, 2026

Copilotstarted reviewing on behalf of lewing March 16, 2026 20:23 View session

CopilotAI reviewed Mar 16, 2026
View reviewed changes

github-actionsBot locked and limited conversation to collaborators Apr 16, 2026

jkotas deleted the fix/shared-memory-create-race branch May 22, 2026 17:03

lewing added the area-System.Threading label Mar 16, 2026

CopilotAI review requested due to automatic review settings March 16, 2026 20:20

dotnet-policy-serviceBot assigned lewing Mar 16, 2026

lewing closed this Mar 16, 2026

Copilotstarted reviewing on behalf of lewing March 16, 2026 20:23 View session

CopilotAI reviewed Mar 16, 2026
View reviewed changes

github-actionsBot locked and limited conversation to collaborators Apr 16, 2026

jkotas deleted the fix/shared-memory-create-race branch May 22, 2026 17:03

lewing added the area-System.Threading label Mar 16, 2026

CopilotAI review requested due to automatic review settings March 16, 2026 20:20

dotnet-policy-serviceBot assigned lewing Mar 16, 2026

lewing closed this Mar 16, 2026

Copilotstarted reviewing on behalf of lewing March 16, 2026 20:23 View session

CopilotAI reviewed Mar 16, 2026
View reviewed changes

github-actionsBot locked and limited conversation to collaborators Apr 16, 2026

jkotas deleted the fix/shared-memory-create-race branch May 22, 2026 17:03

lewing added the area-System.Threading label Mar 16, 2026

CopilotAI review requested due to automatic review settings March 16, 2026 20:20

dotnet-policy-serviceBot assigned lewing Mar 16, 2026

lewing closed this Mar 16, 2026

Copilotstarted reviewing on behalf of lewing March 16, 2026 20:23 View session

CopilotAI reviewed Mar 16, 2026
View reviewed changes

github-actionsBot locked and limited conversation to collaborators Apr 16, 2026

jkotas deleted the fix/shared-memory-create-race branch May 22, 2026 17:03

Uh oh!

Conversation

lewing commented Mar 16, 2026

Problem

Fix

Uh oh!

dotnet-policy-serviceBot commented Mar 16, 2026

Uh oh!

lewing commented Mar 16, 2026

Uh oh!

CopilotAI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

lewing commented Mar 16, 2026

Problem

Fix

Uh oh!

dotnet-policy-serviceBot commented Mar 16, 2026

Uh oh!

lewing commented Mar 16, 2026

Uh oh!

CopilotAI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

lewing commented Mar 16, 2026

Problem

Fix

Uh oh!

dotnet-policy-serviceBot commented Mar 16, 2026

Uh oh!

lewing commented Mar 16, 2026

Uh oh!

CopilotAI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

lewing commented Mar 16, 2026

Problem

Fix

Uh oh!

dotnet-policy-serviceBot commented Mar 16, 2026

Uh oh!

lewing commented Mar 16, 2026

Uh oh!

CopilotAI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!