Toolchain channel names, and the MathCAT pair ============================================= Evidence for section 9 of "Where Rust actually is in Windows 11" (hunterworks.software/teardowns/rust-in-windows-11) Machine: Windows 11 Home x64 25H2, build 26200.9168. Census taken 2 to 4 September 2026; the toolchain comparison below was taken 18 September 2026 on the same machine, after Windows had installed build .9278 of the MathCAT component alongside .8972. 1. Every toolchain package name embedded in a Rust binary here -------------------------------------------------------------- Extracted with: grep -a -o 'rust\.tools[A-Za-z0-9._-]*' | sort -u no channel in the package name sudo.exe rust.tools-x86_64-pc-windows-msvc.1.87.0-ms-20250722.10 DWriteCore.dll (1.8.1, 2.1.1) rust.tools-x86_64-pc-windows-msvc.1.88.0-ms-20250913.5 stable-llvm NarratorMCAT.dll (26100.7705) rust.tools.stable-llvm-x86_64-pc-windows-msvc.1.88.0-ms-20250913.6 CloudRecoveryDownloadTool.dll rust.tools.stable-llvm-x86_64-pc-windows-msvc.1.90.0-ms-20251106.9 (26100.8115) CloudRecoveryDownloadTool.dll rust.tools.stable-llvm-x86_64-pc-windows-msvc.1.90.0-ms-20260302.10 (current) UdiApiClient.dll rust.tools.stable-llvm-x86_64-pc-windows-msvc.1.93.1-ms-20260416.7 stable-utc NarratorMCAT.dll (current) rust.tools.stable-utc-x86_64-pc-windows-msvc.1.95.0-ms-20260514.2 names no package at all win32kbase_rs.sys D:\os\tools\Rust\vpack\rust.tools (OS-repo vpack copy, no version string) DWriteCore.dll (1.6.1, 1.7.1) rustc hash only (d34f430f..., c6bcfe6a...), no package path Note the pair dated 20250913: build .5 has no channel segment, build .6 is stable-llvm. The channel convention appears between those two builds. Cross-reference: the same package names appear per-file in crate-census.txt and winsxs-census.txt, and the rustc revision hashes in rustc-commit-lookup.txt. 2. The MathCAT pair ------------------- The component store holds the same upstream crate, at the same version, built by two different channels. Enumerated with: Get-ChildItem C:\Windows\WinSxS -Filter NarratorMCAT.dll -Recurse 26100.7705 26100.8972 / .9278 / live channel stable-llvm stable-utc rustc package 1.88.0-ms-20250913.6 1.95.0-ms-20260514.2 rustc revision fa6ff70ed0808ced4abe0e4dae135016bdcc8919 32dfec32535536bd884c46f0b69850be9f0b8d02 crate mathcat-0.7.0 mathcat-0.7.0 mathcat_c-0.7.0 mathcat_c-0.7.0 size (bytes) 4,382,296 3,768,656 sha256 ae77944e39192eb7309fa6a92cc797793f8ea85a1c44390e8285782d583e8dfc edd0987181c5ad5f2de63105b461efdc7e57e215f3c4170cc1617c8910de4b84 delta -613,640 bytes, -14.0% C:\Windows\System32\NarratorMCAT\NarratorMCAT.dll (the live copy) is byte-identical to the .8972 and .9278 store copies: same sha256 as above. Both builds carry mathcat-0.7.0 and mathcat_c-0.7.0 in their crate registry paths, so the size change is not an upstream version bump. CONFOUND, stated plainly: the rustc version also moved, 1.88.0 to 1.95.0. Seven releases of rustc change code size on their own. This pair does NOT isolate the backend. A clean test would need one rustc version built both ways, which a census of one machine cannot arrange. 3. The Rich header does not distinguish the two builds ------------------------------------------------------ If the UTC backend (MSVC's own code generator) had produced the stable-utc build, the Rich header, which is MSVC's record of which tools contributed to the link, might be expected to show it. It does not. Decoded by XOR with the key stored after the "Rich" signature; records are (prodID, build, count) triples. 26100.7705 (stable-llvm), xor key 0x051f9c01, 10 records prodID 0x093 build 30729 count 8 prodID 0x101 build 35207 count 2 prodID 0x103 build 35207 count 4 prodID 0x104 build 35207 count 8 prodID 0x105 build 35207 count 16 prodID 0x101 build 33145 count 9 prodID 0x001 build 0 count 174 prodID 0x000 build 0 count 178 prodID 0x100 build 35219 count 1 prodID 0x102 build 35219 count 1 26100.8972 (stable-utc), xor key 0x6dc7216c, 10 records prodID 0x093 build 30729 count 8 prodID 0x101 build 35207 count 4 prodID 0x103 build 35207 count 4 prodID 0x104 build 35207 count 8 prodID 0x105 build 35207 count 18 prodID 0x101 build 33145 count 9 prodID 0x001 build 0 count 177 prodID 0x000 build 0 count 54 prodID 0x100 build 36244 count 1 prodID 0x102 build 36244 count 1 Same record count and the same set of prodIDs, in the same order. The linker moves from build 35219 to 36244. The per-record counts DO change, one of them substantially: the 0x000 record goes from 178 to 54, and 0x101, 0x105 and 0x001 shift by smaller amounts. What does not change is the membership. No record is present in one build and absent from the other, and no tool appears that would mark a different code generator. This is a NEGATIVE result and it is reported as one: the Rich header gives no evidence for or against a different code generator. Separately, and unrelated to the channel question: UdiApiClient.dll carries no Rich header at all, while every other Rust-bearing binary in this census does. 4. What this evidence supports ------------------------------ Supported: a toolchain channel named "utc" exists in Microsoft's internal Rust distribution; it built a shipping Windows component, from a package dated 14 May 2026; that component is 14.0% smaller than the same upstream crate built by the "llvm" channel; Microsoft publicly described a rustc backend named rustc_codegen_utc on 10 September 2026. NOT supported: that rustc_codegen_utc produced this binary. The evidence is a package name plus a naming correspondence. No test performed here reads the code generator out of the file, and the size comparison is confounded by the compiler version. Anyone who can settle it from the binary is invited to. Sources for the public description: https://rustfoundation.org/media/guest-post-rust-is-tier-1-language-at-microsoft/ https://github.com/AzureAD/microsoft-authentication-cli/issues/410 (msrustup, Sept 2024)