Remove instances of %S

[AaronRobinsonMSFT]

The slow slog to removing %S usage in the code base.

[AaronRobinsonMSFT]

@BruceForstall Does this output mean anything to you? I don't understand what failed or why. The full log is at https://helixre107v0xdeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-78894-merge-dcf126a5aef944a183/win-x64-2/1/console.9966e11b.log?helixlogtype=result.

Running superpmi.py replay for JitStressRegs=0x1000
Running: C:\python3\python.exe C:\h\w\BB170A2D\p\superpmi.py replay -core_root C:\h\w\BB170A2D\p -jitoption JitStressRegs=0x1000 -target_os windows -target_arch x64 -arch x64 -jit_path C:\h\w\BB170A2D\p\clrjit_win_x64_x64.dll -spmi_location C:\h\w\BB170A2D\p\artifacts\spmi -log_level debug -log_file C:\h\w\BB170A2D\w\A43B0970\uploads\superpmi_JitStressRegs_0x1000.log
[02:41:40] ================ Logging to C:\h\w\BB170A2D\w\A43B0970\uploads\superpmi_JitStressRegs_0x1000.log

[02:41:40] Using mcs.exe from Core_Root: C:\h\w\BB170A2D\p\mcs.exe

[02:41:40] Using JIT/EE Version from mcs: 0330a175-dd05-4760-840f-a1a4c47284d3

No Azure Storage MCH files to download from 0330a175-dd05-4760-840f-a1a4c47284d3/windows/x64/

[02:41:41] No MCH files found to replay


Consolidating final C:\h\w\BB170A2D\w\A43B0970\uploads\superpmi_windows_x64_2.log
Appending superpmi_JitStressRegs_0x10.log
Appending superpmi_JitStressRegs_0x1000.log
Appending superpmi_JitStressRegs_0x80.log
Appending superpmi_JitStressRegs_8.log

C:\h\w\BB170A2D\w\A43B0970\e>set _commandExitCode=1 

C:\h\w\BB170A2D\w\A43B0970\e>EXIT /b 1 
['win-x64-2' END OF WORK ITEM LOG: Command exited with 1]

[BruceForstall]

The issue is that #78783 changed the JIT-EE GUID, so until the SuperPMI collections get refreshed (which takes about 7 hours), the superpmi-replay and superpmi-diffs pipelines will fail. (This is the job doing the refresh: https://dev.azure.com/dnceng/internal/_build/results?buildId=2055077&view=results)

[AaronRobinsonMSFT]

@BruceForstall Should we create a tracking issue so the system can tag the failure?

[BruceForstall]

@BruceForstall Should we create a tracking issue so the system can tag the failure?

I don't think so. The failure should self resolve soon, and any such failure indicates you've changed the JIT and should probably wait until the collection completes at which point you should re-run the failed pipelines.

[jkotas]

Thanks!