# Method record for "Where Rust actually is in Windows 11" (hunterworks.software/teardowns/rust-in-windows-11)

Machine: one Windows 11 Home x64 installation, 25H2, build 26200.9168, scanned 2026-09-02 and 2026-09-03.
Not a clean image: NVIDIA and Intel GPU driver packages (several versions in DriverStore), WSL, Microsoft Office and Edge are installed.

Scope: every file named *.dll, *.exe or *.sys under C:\Windows, excluding .\WinSxS, .\servicing and .\SoftwareDistribution (scope exclusions, not a claim that those folders hold only duplicates).
Not scanned: other PE extensions (.cpl, .ocx, .scr, .efi, extensionless), C:\Program Files\WindowsApps (ACL-protected, not readable as a standard user), anything outside C:\Windows.
Files enumerated: 13,988. Files that could not be read: 0 (find ! -readable returned nothing; grep ran as a standard user).
Tools: GNU find and grep from Git for Windows (Git Bash). WSL users: replace /c/Windows with /mnt/c/Windows.

Discovery command (exact):
  cd /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'
Result: 92 files. See census-classified.tsv for each hit with SHA-256, size and marker counts.

Classification rule applied to each hit (see census-classified.tsv):
  CHROMIUM  contains 'third_party/rust-toolchain' (Chromium's own Rust build paths)
  RUST      at least one '/rustc/<40 hex>/' string, or more than five strings matching '(src|library)[/\]...\.rs'
  LLVM-FP   none of the above, but DW_LANG_* DWARF language-tag strings present (LLVM's own tables)
Counts in that file are regex occurrences in the raw bytes (grep -a -o | wc -l), not unique strings. The rs_src_paths columns of census-classified.tsv and winsxs-classified.tsv were counted with different expressions and differ by a few percent on identical files; compare within one table, and use SHA-256 to match identical bytes across them.
The counts quoted in the article's screenshot captions are Binocular's Strings view: distinct extracted strings (ASCII and UTF-16, minimum length 4) matching the filter shown in the search box. The two methods count different things and are labelled as such.

What the markers do and do not prove:
  Rust source paths, standard-library paths and rustc commit hashes are strong indicators that a binary contains Rust-origin code. They do not prove that the whole binary is Rust, that the Rust code is on the live execution path, or that there was no earlier C++ version.
  Absence is inconclusive: --remap-path-prefix, location-detail stripping, the immediate-abort panic strategy, packing, or post-link string removal would remove these markers.
  A rustc commit hash identifies the compiler's source revision, not a specific compiler binary or build configuration.

Compiler-hash check: rustc-stable-hashes.txt lists the git_commit_hash from every stable release manifest 1.84.0 to 1.96.1; none matches the hashes found in sudo.exe or either DWriteCore.dll.

Further sources, all attached in this folder.
  Component store: the same grep, without the three exclusions, over WinSxS, servicing and SoftwareDistribution
    (44,889 files, 0 read errors, 34 hits). Classified by the same rule; reconciled against the main census by
    SHA-256; the superseded builds give a per-component version history. See winsxs-census.txt and winsxs-classified.tsv.
  Microsoft public symbols: symchk (Windows SDK debuggers) fetched the public PDB for every component except
    NarratorMCAT.dll (its cargo-named PDB is not on the server); llvm-pdbutil 21.1.4 dumped publics, modules and
    section contributions. Rust versus C++ is attributed by CONTRIBUTING OBJECT FILE (rustc .rcgu.o versus MSVC .obj),
    not by symbol mangling: with link-time optimisation the Rust side is one object and its functions are internal,
    so mangled publics undercount it to near zero. Counts are lower bounds; the code-byte shares are the reliable
    measure. See pdb-symbol-census.txt, symbols/, driver/ (feature flags, from_path mapping, loaded-module check,
    C++ host symbols) and narrator-mathcat-static.txt. Live feature state was read with ntdll!RtlQueryFeatureConfiguration
    from a non-elevated PowerShell; the loaded-module list with NtQuerySystemInformation(SystemModuleInformation).
  Crate and source-file census: Python over the raw bytes of each Rust component and six DWriteCore copies, repairing
    glued string literals against the panic Location structs. See crate-census.txt, rust-crate-census.tsv and crates/.
  Compiler revisions: all ten rustc hashes checked against the stable manifests and against GitHub. See rustc-commit-lookup.txt.
  No program was run to observe behaviour for any finding here: every statement about what is loaded or configured
  comes from kernel queries that any user can make, and the Narrator load path is reported as not observed.

  Toolchain channels: every embedded rust.tools package name collected across the live files and the component
    store, grouped by the channel segment of the package name (none, stable-llvm, stable-utc). The component store
    holds the same MathCAT crate version built by two different channels, so the two builds are compared directly:
    sizes, SHA-256, crate versions and rustc revisions. The Rich header of each was decoded (XOR with the key stored
    after the Rich signature) to test whether a different code generator is visible there; it is not, and that
    negative result is reported as one. The size comparison is confounded by the rustc version, which moved at the
    same time; toolchain-channels.txt states what the evidence does and does not support.
  Reproducing the byte counts: symbols/REPRODUCE.txt carries the symchk and llvm-pdbutil invocations that generate
    census.py inputs, the PDB signature prefixes used here, and the .text sizes. Note the headline percentage is the
    Rust share of ATTRIBUTED code contributions, not of .text (about 98.7% of .text for DWriteCore 2.1.1). The raw
    dumps are not republished (size, and they are specific to the exact PDB builds); the reports published here are the subset of census.py output the article
    cites; its per-function functions-*.tsv tables and summary.txt are not republished.