Teardown measures Rust's real footprint inside Windows 11 system binaries

A hands-on teardown of a Windows 11 installation, published at hunterworks.software and surfaced on Hacker News, replaces years of Microsoft talking points with measurements: how much Rust actually ships in the operating system's binaries, and exactly where.

How the census was run

The author searched every .dll, .exe and .sys under C:\Windows — 13,988 files once the WinSxS, servicing and SoftwareDistribution stores were set aside — for traces the standard Rust toolchain typically leaves in read-only data: /rustc/ path prefixes containing compiler commit hashes, standard-library source paths, and panic-handling symbols. That produced 92 candidates, each opened by hand in the Binocular disassembler, along with the two DirectWrite binaries that earlier press coverage had made interesting.

Strings alone cannot quantify anything, so a second ruler was added. Microsoft's public symbol server hosts PDBs for nearly all Windows binaries, and a public PDB records which object file contributed each block of machine code. Because rustc's objects are easy to tell apart from the MSVC compiler's — with link-time optimisation, the Rust side of a binary tends to land in a single codegen unit — you can attribute code bytes to each compiler rather than estimating source lines. The author pulled symbols with symchk and read them with llvm-pdbutil, attaching the per-object tables. A second sweep over the excluded component stores covered another 44,889 files; since WinSxS keeps superseded component versions, it doubles as the only build history one machine can offer.

Counting symbols undercounts Rust

One methodological finding stands on its own: counting Rust-mangled symbol names is close to useless as a measure of language mix. DWriteCore 2.1.1 exposes 8,424 public symbols and not one is Rust-mangled, yet rustc produced 57.9 percent of its code bytes. Link-time optimisation keeps nearly every Rust function internal to the binary. The exception in this sample is win32kbase_rs.sys, which exports a plain C interface instead of being linked into a C++ host; its symbol table names 177 Rust functions. Whether Rust symbols survive is a property of how a binary was linked, not of how much Rust it contains.

What the binaries contain

• Two servicing DLLs with no previous public write-up, CloudRecoveryDownloadTool.dll and UdiApiClient.dll, have carried Rust since the first 24H2 build and measure 96.6 and 96.2 percent Rust by the linker's attribution, sharing seven internal crates.
• DWriteCore is 57.9 percent Rust in both shipped builds examined. System32\DWrite.dll, by contrast, contains none: no Rust-associated strings among 30,073 checked and no rustc objects among 454 — consistent with Microsoft's own documentation that the two are separate implementations.
• NarratorMCAT.dll is MathCAT, Neil Soiffer's open-source crate, compiled on Microsoft's internal toolchain and signed as a Windows component, with 26 crates drawn from the public registry and no surviving Microsoft crate paths.
• win32kbase_rs.sys is loaded, but its own feature table is empty; the switch deciding whether the Rust GDI-region path runs lives in the C++ host rather than in the driver.
• 83 files that looked like Rust are not: every one is an Intel or NVIDIA driver embedding a shader compiler, and LLVM fully explains the matches.

A hint of Microsoft's rustc backend

The MathCAT component was built by an internal toolchain package called stable-utc, dated four months before Microsoft publicly described rustc_codegen_utc. That description came on 10 September 2026, when Victor Ciura's Rust Foundation guest post named Rust a Tier-1 language at Microsoft and detailed the backend, which wires the Rust compiler into MSVC's UTC backend, has self-hosted since Rust 1.90, and is used across more than a hundred Microsoft repositories with cross-language inlining and hotpatch support. The teardown also notes the utc-built binary is 14 percent smaller than the same crate version built by the llvm channel, while explicitly flagging the toolchain identification as an inference from a package name rather than a direct reading.

Why it matters

Microsoft's public record on Rust in Windows has been long on statements and short on measurements. The Register's April 2023 report on David Weston's BlueHat talk cited roughly 152,000 lines of Rust in DWriteCore against 96,000 of C++, plus a 36,000-line GDI port that booted but stayed behind a flag. win32kbase_rs.sys shipped in July 2023 as what Microsoft called a small trial, Check Point showed it executing in 2025, and Sudo for Windows arrived as open-source Rust in February 2024. This teardown replaces quotes with byte-level attribution on shipped bits, and the resulting picture is incremental: Rust is genuinely present but concentrated in a handful of components, the DirectWrite DLL most users actually load contains none of it, and two near-total rewrites were sitting unnoticed in servicing plumbing. The method travels too — PDB object-file attribution is a repeatable way to audit language composition in any shipped binary, and it catches Rust that symbol-name counting misses by more than half.