Where Rust actually is in Windows 11

The short versionTwo servicing DLLs I found no write-up of. CloudRecoveryDownloadTool.dll and UdiApiClient.dll have carried Rust since the first 24H2 build, are 96.6 and 96.2 percent Rust by the linker’s own accounting, and share seven internal crates. (Sections 3 and 4.)DirectWrite, measured rather than quoted. DWriteCore is 57.9 percent Rust by code bytes in both shipped builds. System32\DWrite.dll is zero: no Rust strings among 30,073, no rustc objects among 454. (Section 7.)Windows ships somebody else’s Rust library. NarratorMCAT.dll is MathCAT, Neil Soiffer’s open-source crate, compiled on Microsoft’s own internal toolchain and signed as a Windows component. No first-party crate path survives in it: 26 registry crates, not one of them Microsoft’s. (Section 5.)A compiler channel called utc. The MathCAT component on this machine was built by a toolchain package named stable-utc, in a package dated four months before Microsoft publicly described a rustc backend called rustc_codegen_utc, and it is 14 percent smaller than the same crate version built by the llvm channel. This one is an inference from a package name, and section 9 says exactly how far it goes.The kernel driver’s switch is not in the kernel driver. win32kbase_rs.sys is loaded, its own feature table is empty, and the Rust region gate lives in the C++ host. (Section 1.)83 files that look like Rust, with no Rust evidence in them. All 83 are Intel and NVIDIA driver binaries with an embedded shader compiler, and in every one the match is fully explained by LLVM. (Section 6.)Counting Rust by symbol name badly undercounts it. DWriteCore 2.1.1 has zero Rust-mangled symbols among its 8,424 publics and is still 57.9 percent Rust. Count contributing object files instead. (Method.)Already public, and credited as such: that win32kbase_rs.sys is Rust (announced in 2023, and Check Point demonstrated it executing in 2025), that sudo.exe is Rust (it is an open-source repository), that DWriteCore and DWrite.dll are different implementations (Microsoft’s own specification says so), that Narrator reads maths with MathCAT (Microsoft announced the feature in 2026, and MathCAT’s own project page says it is Rust), and that an internal Rust toolchain exists (named in public since 2024). What was missing from every one of them was a measurement.What Microsoft has actually saidThe public record is thinner than the discourse. At BlueHat IL in March 2023, David Weston said Windows would probably be booting with Rust in the kernel within several weeks or months. The Register’s April 2023 report of that talk put numbers on it: DWriteCore, the DirectWrite implementation in the Windows App SDK, at about 152,000 lines of Rust alongside 96,000 of C++, and the Win32 GDI port at 36,000 lines, booting but disabled behind a feature flag. In July 2023, Insider build 25905 shipped a kernel driver called win32kbase_rs.sys, which Microsoft described as a new implementation of GDI region and a small trial. In February 2024, Sudo for Windows arrived as an open-source Rust project.The toolchain has a public record too, and it is easy to miss. A September 2024 issue in an unrelated Microsoft repository names msrustup and the Microsoft Rust toolchain in passing, so the existence of an internal distribution has been visible for two years. Then, a week after the census below was taken, Microsoft described it properly: on 10 September 2026 Victor Ciura published a Rust Foundation guest post announcing Rust as a Tier-1 language at Microsoft and naming rustc_codegen_utc, an alternative rustc code generation backend in the same architectural family as rustc_codegen_llvm that wires the Rust compiler into MSVC’s own UTC backend. It has been self-hosted since Rust 1.90, is used in more than a hundred Microsoft repositories, and is credited with cross-language inlining and hotpatch support. That post describes in the abstract a good deal of what the binaries below show concretely. Section 9 is where the two meet.None of that tells you what is on a machine today. So I checked one. The rules for this piece: every claim below is something the screenshots or the attached evidence files show, the build is named so you can repeat it, and where the evidence runs out it says so. Where I am inferring rather than reading, the sentence says that too.MethodRust binaries built with the standard toolchain usually carry fingerprints in their read-only data: panic-location strings that name .rs source files, standard-library paths like library\core\src, and a /rustc/<commit>/ prefix that identifies the source revision the compiler was built from. I ran one grep for those patterns over every .dll, .exe and .sys under C:\Windows, leaving out WinSxS, servicing and SoftwareDistribution as a scope decision (they are component stores that mostly hold copies of files found elsewhere, though not only that):cd /c/Windows # Git Bash. In WSL use: cd /mnt/c/Windows find . -type f \( -iname '*.dll' -o -iname '*.exe' -o -iname '*.sys' \) \ -not -path './WinSxS/*' -not -path './servicing/*' -not -path './SoftwareDistribution/*' -print0 \ | xargs -0 grep -l -a -E 'rustc[/\\][0-9a-f]{40}|library[/\\](core|alloc|std)[/\\]src|core::panicking|rust_eh_personality|__rust_alloc'That covered 13,988 files with no read errors and returned 92 hits. Most of the hits are one family of false positives, which gets its own section below. The rest I opened in Binocular one by one, plus the two DirectWrite binaries the press coverage made me curious about. Grep finds candidates. What follows is what the files say when you read them, including the ones where grep was wrong.The same grep, without the three exclusions, went over the component store: 44,889 more files under WinSxS, servicing and SoftwareDistribution, in about four minutes. WinSxS keeps the superseded builds of every component that servicing has not yet cleaned up, so it doubles as the only history a single machine can offer. Its results are in section 8.The other source is Microsoft itself. Its public symbol server carries debugging symbols for most Windows binaries, and it has them for every component here except the MathCAT DLL, whose symbol file is named by cargo rather than by Windows. A public symbol file has no source and no types, but it records which object file contributed each block of code, and rustc’s object files are unmistakable: with link-time optimisation the whole Rust side of a binary lands in a single .rcgu.o. That is a ruler the strings cannot supply, how many bytes of a binary rustc compiled and how many the C++ compiler did, and it does not depend on panic strings surviving. It measures the linker’s attribution, not source lines, and identical-code folding can merge a handful of functions across the line; the cross-checks that bound that are attached. The symbol files were fetched with the SDK’s symchk and read with LLVM’s llvm-pdbutil; the census and every per-object table are attached.Why not just count Rust symbol names. Because the count bears almost no relation to the amount of Rust. DWriteCore 2.1.1 has zero Rust-mangled symbols among its 8,424 publics, and rustc still produced 57.9 percent of its code. Link-time optimisation folds the Rust half into one codegen unit, so almost every Rust function is internal and never reaches the publics table; the only Rust-mangled publics in those binaries are #[link_section] statics. That is not a universal rule. win32kbase_rs.sys is the exception here: it exports a plain C table rather than linking a staticlib into a C++ host, and its symbols do name 177 Rust functions. Why those survived and DWriteCore’s did not is a question about how each was linked, which is the point. A symbol count measures the link, not the language. The contributing object file is the thing to count, and a public PDB records it.Two cautions before the reading starts. First, these markers are strong indicators that a binary contains Rust-origin code. They do not prove the whole binary is Rust, that the Rust code is on the live execution path, or that there was never a C++ version. Absence proves even less: a build that remaps its source paths, strips location detail, or removes strings after linking would show nothing. Second, filtering strings for .rs also matches Serbian domain names (it is a country code, and google.rs turned up) and LLVM’s MIPS intrinsics (llvm.mips.extr.rs.w). The Rust source paths in these files all have \src\ or library\ in them. Every screenshot below shows its filter in the search box so you can repeat it exactly.1. The kernel driver: win32kbase_rs.sysThis is the one Microsoft announced, and it is still there in 25H2: a 152 KB driver (155,648 bytes), version 10.0.26100.8972, described in its own version resource as Base Win32k Kernel Driver. Filter its strings for anything ending in .rs and you get 21 hits.win32kbase_rs.sys, Strings view filtered with /\.rs\b/. 21 of 1,780 extracted strings match, every one a Rust source path. The three tagged Paths are absolute paths from Microsoft's build machine: the OS source tree, the vendored toolchain and the crate cache.The crate names are readable straight off the panic strings: gdi_rust, rgncore, gdi_alloc, seh_unwind, handle_manager, and a small crate called fallible_vec, which is what you reach for when a kernel allocation is allowed to fail. Microsoft’s symbol file confirms the list and adds two crates the strings do not show, gdi_bindings and gdi_region, plus a symbol prefix, cxxbridge1$, that names the generator of the bridge between the two languages: the cxx crate. Of the 177 Rust functions the symbol file names, 54 are in rgncore and 18 in gdi_rust, and the only standard library present is core and alloc, as a kernel driver’s should be. Binocular tags three of the 21 as Paths, absolute paths from Microsoft’s build machine. Two name the vendored toolchain under D:\os\tools\Rust\vpack and the crate cache that served fallible_vec from a Visual Studio package feed. The third