WinSxS census for "Where Rust actually is in Windows 11" (hunterworks.software/teardowns/rust-in-windows-11) Why: the main census (census-classified.tsv) deliberately left out C:\Windows\WinSxS, servicing and SoftwareDistribution. WinSxS is the component store: it holds the current build of every Windows component plus the superseded builds that servicing has not yet cleaned up. Scanning it answers two objections at once: "you skipped where Windows keeps its files", and "you cannot see lineage on one machine". The superseded builds are the lineage. Machine: the same Windows 11 Home x64 25H2 installation, build 26200.9168. Scanned 2026-09-04, 15:09 to 15:13 local. Command (Git Bash, same regex as the main census, run from C:\Windows): find ./WinSxS ./servicing ./SoftwareDistribution -type f \( -iname '*.dll' -o -iname '*.exe' -o -iname '*.sys' \) -print0 \ | xargs -0 grep -l -a -E 'rustc[/\\][0-9a-f]{40}|library[/\\](core|alloc|std)[/\\]src|core::panicking|rust_eh_personality|__rust_alloc' Files enumerated: 44,889 (WinSxS, servicing and SoftwareDistribution together). Read errors: 0. Hits: 34, all under WinSxS. Classification (same rule as the main census; per-file rows with SHA-256, marker counts, file version, link date and the WinSxS component folder are in winsxs-classified.tsv): RUST 21 CHROMIUM 13 (Edge WebView2 pieces carrying Chromium's own third_party/rust-toolchain paths; excluded from the Windows count as before) LLVM-FP 0 (the GPU driver false positives live in DriverStore, which is under System32 and was in the main census) Reconciliation against the main census, by SHA-256: 11 hits are byte-identical to a file the main census already lists (the current build, hard-linked or copied into the store). 12 hits have a name the census lists but different bytes: superseded builds of the same components. These are the history below. 11 hits are names the census does not list: ten Edge WebView2 files from WebView versions 147 and 148 (EmbeddedBrowserWebView.dll, msedge_elf.dll, elevated_tracing_service.exe, mip_core_gn.dll), all CHROMIUM class, and one RUST-class file, dwritemin.dll (below). The current System32 copies of those four WebView files (version 150.0.4078.93) contain none of the marker strings, which is why the main census did not list them; only msedge.dll still does. Chromium's Rust footprint in those binaries is a Chromium matter. Version history of the Rust components, oldest build first (FileVersion from the version resource; "OS component" is the WinSxS component version, i.e. the Windows servicing build that shipped it; the toolchain string and rustc hash are read from the binary; "-" means the string is not present in that build). Link dates are not listed: for most OS binaries the PE timestamp is a reproducible-build hash, not a date (the values decode to years such as 1979, 2003, 2044 and 2094). CloudRecoveryDownloadTool.dll (Microsoft Cloud Recovery Download Tool) OS 26100.1 FileVersion 1.0.37.0 3,127,328 bytes 771 Rust source paths toolchain - rustc - OS 26100.8115 FileVersion 0.2.717.0 2,824,608 bytes 784 Rust source paths rust.tools.stable-llvm-...1.90.0-ms-20251106.9 rustc 82a24cd0 OS 26100.8972 FileVersion 0.3.28.0 2,792,864 bytes 786 Rust source paths rust.tools.stable-llvm-...1.90.0-ms-20260302.10 rustc e4768218 (= System32 today) Reading: Rust in the very first 24H2 build (26100.1); no C++ predecessor exists on this machine to compare against. The version number went 1.0.37 -> 0.2.717 -> 0.3.28, which looks like a renumbering, not a regression. UdiApiClient.dll (Microsoft Universal Download and Install) OS 26100.1 FileVersion 0.1.186.0 3,600,296 bytes 925 Rust source paths toolchain - rustc - OS 26100.8521 FileVersion 0.2.789.0 2,258,888 bytes 556 Rust source paths rust.tools.stable-llvm-...1.93.1-ms-20260416.7 rustc 0bcbc193 OS 26100.8972 FileVersion 0.4.45.0 2,310,048 bytes 567 Rust source paths rust.tools.stable-llvm-...1.93.1-ms-20260416.7 rustc 0bcbc193 (= System32 today) Reading: Rust in the first 24H2 build as well. The 26100.1 builds of both servicing DLLs carry neither a toolchain package name nor a rustc hash, only the source paths; the msrustup fingerprints appear from the 2025/2026 builds on. win32kbase_rs.sys (Base Win32k Kernel Driver) OS 26100.1301 151,552 bytes 10 Rust source paths toolchain - rustc 3e667cc5 OS 26100.8521 155,648 bytes 21 Rust source paths "rust.tools" only rustc - OS 26100.8875 155,648 bytes 21 Rust source paths "rust.tools" only rustc - OS 26100.8972 155,648 bytes 21 Rust source paths "rust.tools" only rustc - (= System32 today) Reading: the driver grew by 4 KB and from 10 to 21 source-path strings between the 1301 build and the 8521 build; the May 2025 servicing fix reported by Check Point (KB5058499) lies between those two builds. The 1301 build still embedded its rustc hash; later builds do not, which is a build-configuration change, not evidence of less Rust. DWriteCore.dll (Microsoft DirectX Typography Services, ProductName Windows App SDK), inbox Windows App Runtime OS 26100.1591 App SDK 1.5.0.2311 3,033,600 bytes 189 Rust source paths toolchain - rustc - OS 26100.8328/8737/8972 App SDK 1.6.1.2406 3,019,776 bytes 197 Rust source paths toolchain - rustc d34f430f (= SystemApps CBS today) OS 26100.8328 App SDK 1.8.1.2512 3,087,872 bytes 197 Rust source paths rust.tools-...1.88.0-ms-20250913.5 rustc 6a6eaca6 OS 26100.8875/8972 App SDK 2.1.1.2605 3,242,496 bytes 197 Rust source paths rust.tools-...1.88.0-ms-20250913.5 rustc 6a6eaca6 (= SystemApps CBS.2 today) Reading: two inbox channels (stable 1.5 -> 1.6.1, vnext 1.8.1 -> 2.1.1). The 2.1.1 build was compiled with the same toolchain package and compiler revision as 1.8.1. Source-path strings count files, not code; the symbol census (pdb-symbol-census) is the measure of growth. dwritemin.dll (Microsoft DirectX Typography Services, OriginalFilename DWriteMin, ProductName Windows App SDK) OS 26100.1, inside the Edge WebView2 component App SDK 1.5.0.2308 1,999,760 bytes 84 Rust source paths toolchain - rustc - Reading: the 24H2 RTM WebView2 package bundled a trimmed DWriteCore build under the name DWriteMin, with Rust source paths in it. No current copy exists anywhere under C:\Windows outside WinSxS; the WebView2 150 package does not ship it. It is counted here as a superseded Microsoft binary, not as a seventh component. NarratorMCAT.dll (no version resource) OS 26100.7705 4,382,296 bytes 466 Rust source paths rust.tools.stable-llvm-...1.88.0-ms-20250913.6 rustc fa6ff70e OS 26100.8972 3,768,656 bytes 312 Rust source paths rust.tools.stable-utc-...1.95.0-ms-20260514.2 rustc 32dfec32 (= System32 today) Reading: the 7705 servicing build is the first one in the store to contain the MathCAT DLL, consistent with Microsoft's statement that Narrator reads Office maths with MathCAT from build 26200.7623 onwards. sudo.exe OS 26100.7705 FileVersion 1.0.1 970,272 bytes 93 Rust source paths rust.tools-...1.87.0-ms-20250722.10 rustc 035286e2 (= System32 and SysWOW64 today) Compiler revisions: the store adds three rustc hashes to the six the main census found, and the DWriteCore that WSL bundles supplies a tenth. All ten were checked against the stable release manifests and against GitHub; see rustc-commit-lookup.txt. What this does and does not show: It shows which builds of each component this machine has received and what each contained. It does not show what is loaded or running; superseded WinSxS builds are inert. It says nothing about builds the machine never received (the store only holds what servicing delivered here), so "first build in the store" is a lower bound on age, not a release date.