(Windows) "The system cannot find the file specified. (os error 2)" when running `rustup doc` in a non-ANSI path
Verification
- I searched for recent similar issues at https://github.com/rust-lang/rustup/issues?q=is%3Aissue and found no duplicates.
- I am on the latest version of Rustup according to https://github.com/rust-lang/rustup/tags and am still able to reproduce my issue.
Problem
I installed rustup to learn the language. When running it standalone, I noticed the following remark:
If you are new to Rust consider running
rustup doc --bookto learn Rust.
I tried it out, however it did not work. Checking other commands I found that no rustup doc commands work...
Opening docs named `book` in your browser
error: couldn't open browser: IO error: The system cannot find the file specified. (os error 2)Steps
- Have a user with a non-ANSI character in their username (for example,
ł) - Probably important: Change the locale encoding to UTF-8
- Open the region control panel applet
- Open the Run menu (Win+R)
- Enter
intl.cpl - Press Enter
- Open the "Administrative" tab
- Click "Change system locale..."
- Check the "Beta: Use Unicode UTF-8 for worldwide language support" checkbox
- Restart the PC
- Open the region control panel applet
- Download
rustup-initand installrustupwith default settings - Run
rustup doc --book - Get really sad
Possible Solution(s)
The path seems to be URL-encoded as UTF-8 and passed to ShellExecuteW, which doesn't understand UTF-8; only UCS-2, or wchar_t.
Notes
Investigating events under Process Monitor, I found that the path rustup attempts to read is malformed. The expected path should contain Michał, not MichaÅ. (The \x82 byte is invisible under Process Monitor.)
I attempted to get rustup to spit out some logs, but $env:RUSTUP_LOG=trace did not produce anything useful. I then decided to clone rust-lang/rustup and poke around, getting it to spit out the path it's trying to access to see where the encoding mismatch happens.
I had absolutely no idea what I'm doing and the surrounding source code looked , but I managed to determine that rustup URL-encodes the path and passes it to ShellExecuteW. I then found that my username was being URL-encoded in UTF-8, but ShellExecuteW does not understand UTF-8, only UCS-2.
I dumped the path being opened with this patch:
diff --git a/src/toolchain.rs b/src/toolchain.rs
index 57ed54a6..c2e7bd85 100644
--- a/src/toolchain.rs
+++ b/src/toolchain.rs
@@ -527,6 +527,7 @@ impl<'a> Toolchain<'a> {
.ok()
.with_context(|| anyhow!("invalid doc file absolute path `{}`", relative.display()))?;
doc_url.set_fragment(fragment);
+ info!("opening path `{}`", doc_url.to_string());
utils::open_browser(doc_url.to_string())
}This yielded the following:
info: opening docs named `book` in your browser
info: opening path `file:///C:/Users/Micha%C5%82/.rustup/toolchains/stable-x86_64-pc-windows-msvc/share/doc/rust/html/book/index.html`
error: couldn't open browser: IO error: The system cannot find the file specified. (os error 2)
error: process didn't exit successfully: `target\debug\rustup-init.exe doc --book` (exit code: 1)I later tested this in a C# REPL and called ShellExecuteW with the ł being URL encoded and not. The URL-encoded version returned 2, which seems to be the Win32 error code for ERROR_FILE_NOT_FOUND. Running the non-URL-encoded version, it worked and returned 42.
Setting the $env:BROWSER variable to a valid browser executable seems to work, however.
Rustup version
rustup 1.29.0 (28d1352db 2026-03-05)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: the currently active `rustc` version is `rustc 1.98.0 (88d9e12ae 2026-08-18)`Installed toolchains
Default host: x86_64-pc-windows-msvc
rustup home: C:\Users\Michał\.rustup
installed toolchains
--------------------
stable-x86_64-pc-windows-msvc (active, default)
active toolchain
----------------
name: stable-x86_64-pc-windows-msvc
active because: it's the default toolchain
installed targets:
x86_64-pc-windows-msvcOS version
Windows 11, Version 25H2 (OS Build 26200.9168)Source: rust-lang/rustup