rust-lang
No Windows SDK installed when installing Rust on a freshly installed Windows 11
Verification
- [x] I searched for recent similar issues at https://github.com/rust-lang/rustup/issues?q=is%3Aissue+is%3Aopen%2Cclosed and found no duplicates.
- [x] 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 just reinstalled Windows 11 Home Edition 24H2. When I installed Rustup, I didn't see the Windows SDK installed. I remember it being installed with Windows SDK 22000. After installing Rust, I tried creating a new project with cargo and then running cargo run. The terminal complained that I was missing link.exe. I then went to Visual Studio 17.14.12 and saw that the only Windows SDKs available were 19041, 22621, and 26100. I chose to install 26100. After the installation, I ran cargo run again, and it worked correctly.
Steps
- Prepare a Windows 11 system that has not installed Rust and Visudo Studio related content.
- Double-click rustup-init.exe.
- Choose to install Visual Studio Community Edition.
Possible Solution(s)
If I remember correctly, it used to install Windows SDK version 22000. Now it seems it is gone, maybe it's time to choose to install another version of Windows SDK by default.
Notes
No response
Rustup version
rustup 1.28.2 (e4f3ad6f8 2025-04-28)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.89.0 (29483883e 2025-08-04)`
Installed toolchains
Default host: x86_64-pc-windows-msvc
rustup home: C:\Users\shapg\.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-msvc
OS version
Windows 11 Home Edition 24H2 26100.4946
@vagreargnatry Thanks for your report!
FYI we do hardcode 22000 in the installation helper because it is known to work at least at the time of writing:
https://github.com/rust-lang/rustup/blob/3f6b75b20f550015359ed98a20912b7cecc55980/src/cli/self_update/windows.rs#L309-L314
... are you suggesting that this toolchain is no longer being distributed?
cc @ChrisDenton is there a more generic way than just pinning a version here?
@rami3l Thanks for the response. Yes, I searched this and it said that 22000 has been removed. https://github.com/microsoft/win32metadata/issues/2110
Yes, this is unfortunate. Last I looked into it there was no general way to install the latest available Windows SDK via the installer. So our only viable option is to hard code it somewhere.
Though maybe in the future we could make this more adaptable. If we put the components needed to be installed in a text file that can be downloaded by rustup, then maybe we could make changes without needing to release a new version of rustup.
Windows SDKs are not actually guaranteed to be backwards compatible, so installing the latest blindly would probably bad idea anyway.
For rust usage we mostly don't care about the SDK itself just a few import libraries (like kermel32.lib). And bare in mind that it only gets automatically installed if the user hasn't installed anything themselves. If they have specific requirements they can (and should) select that themselves.
In the future we could omit installing the SDK entirely. But this requires raw-dylib to be the default in the standard library and across the ecosystem.
Throwing out some other options to avoid the direct SDK reference:
- Microsoft.VisualStudio.Workload.NativeDesktop VS workload
- Microsoft.Windows.SDK.BuildTools nuget package
(I presume the team already looked at all this though!)
- Sure we could install the full workload. People are already unhappy with the install size though and that would make it worse.
- I don't think the nuget BuildTools includes the import libraries we needs. IIRC it's just binaries.
Ok so I think the options can be summarised as:
- Use the full C++ workload. However, this requires an additional ~5gb of drive space.
- Move the list of components to a file that's downloaded and therefore can be updated outside of normal rustup releases
- rustc could ship open source versions of the libs we need from the SDK. This would mean rustup doesn't need to install the SDK but would also increase the download size of rustc itself.
- rustc could move entirely to using the
raw-dylib, removing the necessity for import libraries. This is still blocked on a few issues.
The first would be the easiest but the downside is substantial. I think the second one is the more adaptable in the face of other unexpected changes. The other two options require work on the rustc side. Switching to raw-dylib by default would be the better of those but there's a few issues still blocking that.
I agree with @djc that we should go with option 2; doing such hotfixes definitely aligns better with what rustup has been doing regarding release manifests.
Can we add something to the README as an intermediate solution, since at the moment if you install fresh via rustup you just get a broken installation and it's confusing to users?
