Current tests run on Windows will accidently clears installed registry values by normal installation of rustup

[baka-gourd]

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

This bug was originally discovered by @Cloud0310 , but due to operating system limitations, it could not be reproduced independently; I was able to reproduce the issue.

Currently, some tests incorrectly clear the properly installed Windows RustUp registry values while running. like:

cargo test --features test --test test_bonanza suite::cli_self_upd::uninstall_deletes_bins -- --exact --nocapture

This is a clear violation of the rules and will result in the properly installed version of Rust on the developers' computers being accidentally “uninstalled.”

Steps

1. For test, backup HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall\Rustup in anywhere
2. Ran cargo test --features test --test test_bonanza suite::cli_self_upd::uninstall_deletes_bins -- --exact --nocapture
3. Values in the registry may be accidentally deleted. You can use Get-ItemProperty -Path <mentioned key before> to verify this.

Possible Solution(s)

Decoupling File Deletion from Registry Cleanup

Notes

This is because the method for removing directories is tightly coupled with the method for removing files.

rustup/src/cli/self_update/windows.rs

Lines 567 to 571 in 9773857

	pub(crate) fn do_remove_from_path(process: &Process) -> Result<()> {
	let new_path = _with_path_cargo_home_bin(_remove_from_path, process)?;
	_apply_new_path(new_path)?;
	do_remove_from_programs()
	}

Rustup version

rustup 1.29.0 (28d1352db 2026-03-05)

Installed toolchains

installed toolchains
--------------------
stable-x86_64-pc-windows-gnu
stable-x86_64-pc-windows-msvc (active, default)
stable-x86_64-unknown-linux-gnu
nightly-x86_64-pc-windows-msvc
1.78-x86_64-pc-windows-msvc
1.80-x86_64-pc-windows-msvc
1.86-x86_64-pc-windows-msvc
1.90.0-x86_64-pc-windows-msvc
1.93-x86_64-pc-windows-msvc

active toolchain
----------------
name: stable-x86_64-pc-windows-msvc
active because: it's the default toolchain
installed targets:
  x86_64-pc-windows-msvc
  x86_64-unknown-linux-gnu

OS version

Windows 25H2(26220.8690)

[baka-gourd]

I've done some testing and tweaking, and I think I can @rustbot claim

[Cloud0310]

This is a issue that find when doing #4861 , thanks @baka-gourd for complete the work left with me. And after my PR is done, we can make a swift fix upon this.

[rami3l]

@baka-gourd @Cloud0310 Thanks for reporting! This does look like a design flaw of our test suite.

Some ideas that I can think of:

• Use an alternative registry path each time instead of the global one for each tests?
• Since the result of most tests won't be influenced by NO_MODIFY_PATH, maybe that should be the default for the Windows environment. Then, for the rest we can couple the path/registry modification with RegistryGuard and force them to run serially.
• Follow the current dependency injection chain for environment variables, and use a mocked registry. This approach is the most performant theoretically but might be non-trivial to implement.

[Cloud0310]

@rami3l @baka-gourd I think this is actually two separate problems:

1. Decoupling Windows PATH modification from other program modifications.
2. Ensuring tests can safely and reliably validate PATH modification behavior without affecting the real system state, while also avoiding potential concurrency issues in Windows tests.

The first approach is to create a separate registry subkey with a unique random id for each test and perform all PATH modifications within that isolated scope. I prefer this approach for a few reasons:

• It keeps the production code untouched.
• It provides proper test isolation and avoids modifying the real PATH registry location.
• It eliminates potential concurrency issues when Windows tests are run in parallel.
• Building a dedicated, fully featured registry mock seems relatively costly for this use case.

cc @ChrisDenton Do you have any other suggestions for addressing this? I'm not very familiar with Windows-specific development, so I'd appreciate your perspective.

[baka-gourd]

Currently, Rust does not have a good way to create a mock registry, and implementing one is quite difficult. Therefore, we have implemented a single-path solution to avoid modifying the actual path

[ChrisDenton]

Could we more simply mock setting the registry by not actually calling registry APIs. Just override create/get/set to use a hashmap or something like that?

[baka-gourd]

Could we more simply mock setting the registry by not actually calling registry APIs. Just override create/get/set to use a hashmap or something like that?

I’ve considered this approach. But it’s essentially the same as impl a dry run of the registry for rustup, might that have too big an impact?

[ChrisDenton]

We use the windows_registry crate for accessing the registry so in general I'd say it's their job to ensure the crate works correctly, not ours. And if we can assume the crate works then we don't gain much from retesting it.

If we want to be paranoid we could have a single integration test that's run separately from other tests (and only run in CI by default) that tests the registry is correctly set after installing rustup.

[rami3l]

@ChrisDenton I think the point here is that we would want to make sure that rustup is adding/removing the registry contents at the right time, as a part of the integration tests, similar to how we assert $PATH changes on Unix, so I'm in favor of keeping those tests, although probably the mechanisms should be somehow redesigned to make this safer.

@baka-gourd It should be noted that rustup does not use most parts and most features of the registry so only mocking the part that we actually use should be enough (so far it's just for USER_PATH and USER_RUSTUP_VERSION, right?). I think given the fact that we already use almost the same mechanism for environment variables, it might be worth trying...

[ChrisDenton]

@rami3l To be clear I wasn't suggesting removing these tests, only adapting them to not use the real registry.