Eric StJohn

Looks like this path is coming from environment: ``` DOTNET_ROOT = /Users/runner/.dotnet ``` Comparing this to linux to see if that's the difference.

Yep that's what did it: https://github.com/dotnet/roslyn/pull/68918/files#diff-ec99cd9453fe657dd1ea08e93e94b0bb51c51484b8ad25882d312564e5fe8e26R61 It's unusual that this Mac build is setting DOTNET_ROOT though -- I'm looking into why that is. The linux build doesn't set it.

I don't think this repo is setting the DOTNET_ROOT value. I think it's already set on the build machine, it's just not overridden by the build process.

Removed [7.0] from the title since this appears to be happening across branches.

Still happening: https://github.com/dotnet/runtime/pull/84357

Be careful about assuming we should workaround such issues. If they appear regularly it's more likely we have a concurrency issue in the build, or a bad practice (eg: open/re-write...

Just hit this again: https://dev.azure.com/dnceng/public/_build/results?buildId=1070066&view=logs&j=e93c566c-b6be-5acb-6fc2-de2972d01fec&t=2dc174be-b57a-56b6-9566-e621f39fb1f6&l=3009 ``` block.cpp D:\workspace\_work\1\s\src\coreclr\jit\emit.cpp(8624,1): fatal error C1090: PDB API call failed, error code '23': (0x000006BA) [D:\workspace\_work\1\s\artifacts\obj\coreclr\windows.x86.Debug\jit\clrjit_win_x86_x86.vcxproj] hashbv.cpp ``` It's at a different point in the build.

Most of the failures listed here were not the same as @stephentoub's OP issue. Many were due to the test running on a platform that didn't support RemoteExecutor (not part...

All failures here are ``` System.ComponentModel.Win32Exception : Access is denied. at System.Diagnostics.ProcessManager.OpenProcess(Int32 processId, Int32 access, Boolean throwIfExited) in /_/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/ProcessManager.Windows.cs:line 252 at System.Diagnostics.Process.GetProcessHandle(Int32 access, Boolean throwIfExited) in /_/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Windows.cs:line 787 at System.Diagnostics.Process.WaitForExitCore(Int32...

I don't believe this is hit at all anymore after the fix to not run in environments that don't support remote executor. Closing this out.