The Windows SDK (10.0.22000) for Windows 11 provides the latest headers, libraries, metadata, and tools for building Windows applications. Use this SDK to build Universal Windows Platform (UWP) and Win32 applications for Windows 11 and previous Windows releases.
NEWWindows App SDK
The Windows App SDK provides a unified set of APIs and tools that are decoupled from the OS and released to developers via NuGet packages. These APIs and tools can be used in a consistent way by any desktop app on Windows 11 and downlevel to Windows 10, version 1809.
You can get the Windows SDK in two ways: install it from this page by selecting the download link or by selecting “Windows 11 SDK (10.0.22000)” in the optional components of the Visual Studio 2019 Installer.
Before you install this SDK:
The Windows SDK has the following minimum system requirements:
Supported operating systems
Universal Windows Platform (UWP) app development
- Windows 10 version 1507 or higher: Home, Professional, Education, and Enterprise (LTSB and S are not supported)
- Windows Server 2019, Windows Server 2016 and Windows Server 2012 R2 (Command line only)
Win32 app development
- Windows 10 version 1507 or higher
- Windows Server 2019, Windows Server 2016, and Windows Server 2012 R2 (Command line only)
- Windows 8.1
- Windows 7 SP1
(Not all tools are supported on earlier operating systems)
- 1.6 GHz or faster processor
- 1 GB of RAM
- 4 GB of available hard disk space
Additional SDK requirements
Installation on Windows 8.1 and earlier operating systems requires KB2999226. To install through Windows Update, make sure you install the latest recommended updates and patches from Microsoft Update before you install the Windows SDK.
The Windows SDK for Windows 11 lets you update your apps for the latest version of the Windows OS. Learn more about the new features in Windows 11.
To see the new APIs introduced with Windows 11, see New APIs in Windows 11 build 22000.
Rebuilt the binaries of the Windows 11 on ARM operating system itself with ARM64EC so that any system code loaded by x64 apps runs with native speed. Take advantage of ARM64EC to incrementally transition your app to running with native speed on ARM, even if you have dependencies or plugins that don’t support ARM yet. Read announcement.
Windows app samples are now available through GitHub. You can browse the code on GitHub, clone a personal copy of the repository from Git, or download a zipped archive of all the samples. We welcome feedback, so feel free to open an issue within the repository if you have a problem or question. These samples are designed to run on desktop, mobile, and future devices that support the Universal Windows Platform (UWP).
Previous SDK versions
Previously released SDKs and emulators, including update details, can be found on the archive page.
API Light Up
When you use new APIs, consider writing your app to be adaptive so that it runs correctly on the widest array of Windows devices. An adaptive app "lights up" with new features wherever the devices and Windows version supports them, but otherwise offers only the functionality available on the detected platform version. For implementation details, see the Version adaptive code article.
Release notes and known issues
Windows 10 SDK, Version 2104
- Removed api-ms-win-net-isolation-l1-1-0.lib. Apps that were linking against api-ms-win-net-isolation-l1-1-0.lib can switch t OneCoreUAP.lib as a replacement.
- Removed irprops.lib. Apps that were linking against irprops.lib can switch to bthprops.lib as a drop-in replacement.
- Moved ENUM tagServerSelection from wuapicommon.h to wupai.h and removed the header. If you would like to use the ENUM tagServerSelection, you will need to include wuapi.h or wuapi.idl.
- The Windows 10 WinRT API Pack lets you add the latest Windows Runtime APIs support to your .NET Framework 4.5+ and .NET Core 3.0+ libraries and apps. To access the Windows 10 WinRT API Pack, see the Microsoft.Windows.SDK.Contracts nuget package.
- The printf family of functions now conforms with the IEEE 754 rounding rules when printing exactly representable floating-point numbers and will honor the rounding mode requested via calls to fesetround. Legacy behavior is available when linking with legacy_stdio_float_rounding.obj.
- Windows App Certification Kit. Several new APIs were added to the Supported APIs list in the App Certification Kit and Windows Store. If there are APIs in the supported list that appear greyed out or disabled in Visual Studio, you can make a small change to your source file, to access them. For more details, see this known issue. Find more updates to tests.
- Message Compiler (mc.exe) updates:
- Now detects the Unicode byte order mark (BOM) in .mc files. If the .mc file starts with a UTF-8 BOM, it will be read as a UTF-8 file. Otherwise, if it starts with a UTF-16LE BOM, it will be read as a UTF-16LE file. If the -u parameter was specified, it will be read as a UTF-16LE file. Otherwise, it will be read using the current code page (CP_ACP).
- Now avoids one-definition-rule (ODR) problems in MC-generated C/C++ ETW helpers caused by conflicting configuration macros (e.g. when two .cpp files with conflicting definitions of MCGEN_EVENTWRITETRANSFER are linked into the same binary, the MC-generated ETW helpers will now respect the definition of MCGEN_EVENTWRITETRANSFER in each .cpp file instead of arbitrarily picking one or the other).
- Windows Trace Preprocessor (tracewpp.exe) updates:
- Supports Unicode input (.ini, .tpl, and source code) files. Input files starting with a UTF-8 or UTF-16 byte order mark (BOM) will be read as Unicode. Input files that do not start with a BOM will be read using the current code page (CP_ACP). For backwards-compatibility, if the -UnicodeIgnore command-line parameter is specified, files starting with a UTF-16 BOM will be treated as empty.
- Supports Unicode output (.tmh) files. By default, output files will be encoded using the current code page (CP_ACP). Use command-line parameters -cp:UTF-8 or -cp:UTF-16 to generate Unicode output files.
- Behavior change: tracewpp now converts all input text to Unicode, performs processing in Unicode, and converts output text to the specified output encoding. Earlier versions of tracewpp avoided Unicode conversions and performed text processing assuming a single-byte character set. This may lead to behavior changes in cases where the input files do not conform to the current code page. In cases where this is a problem, consider converting the input files to UTF-8 (with BOM) and/or using the -cp:UTF-8 command-line parameter to avoid encoding ambiguity.
- TraceLoggingProvider.h updates:
- Avoids one-definition-rule (ODR) problems caused by conflicting configuration macros (e.g. when two .cpp files with conflicting definitions of TLG_EVENT_WRITE_TRANSFER are linked into the same binary, the TraceLoggingProvider.h helpers will now respect the definition of TLG_EVENT_WRITE_TRANSFER in each .cpp file instead of arbitrarily picking one or the other).
- In C++ code, the TraceLoggingWrite macro has been updated to enable better code sharing between similar events using variadic templates.
- Signing your apps. Device Guard signing is a Device Guard feature that is available in Microsoft Store for Business and Education, which allows enterprises to guarantee every app comes from a trusted source. See the documentation about Device Guard Signing.
- SDK headers have been updated to address errors when compiling using the standard-conformant C preprocessor in the MSVC compiler cl.exe (/Zc:preprocessor, introduced in VS 2019 v16.6).
- Fixed: “GdiplusTypes.h does not compile with NOMINMAX”. See Visual Studio Feedback.
- When building with /std:c11 or /std:c17, you now get:
- C99 tgmath.h
- C11 static_assert in assert.h
- C11 stdalign.h
- C11 stdnoreturn.h
- Clang/LLVM for Windows v11 targeting ARM64 is not compatible with the latest winnt.h
- As a workaround, use the previous version of the Windows 10 SDK (build 19041), or clang/LLVM for Windows v10 when targeting ARM64 platforms
- DirectXMath (including version 3.16 in this release) is not compatible with Clang/LLVM for Windows on ARM64.
- As a workaround, use the latest version of DirectXMath, available from NuGet, vcpkg, or GitHub. These versions include the required hot fixes (version 3.16b).
- The case of some header files were changed, to normalize them for case-sensitive file systems:
- OAIdl.h, ObjIdl.h, ObjIdlbase.h, OCIdl.h, Ole2.h, OleAuto.h, and OleCtl.h were all made lower-case.
- For Clang/LLVM for Windows builds, to support both older version and the latest Windows 10 SDK without warnings, add `-Wno-nonportable-system-include-path` to the CLI, or the following #pragma in source:
#pragma clang diagnostic ignored "-Wnonportable-system-include-path"
Windows 10 SDK, Version 2004 servicing update (released 12/16/2020)
- This release contains the following files. If you encounter these issues, we recommend that you update your version of the SDK as soon as possible to avoid them:
- Resolved unpredictable and hard to diagnose crashes when linking both umbrella libraries and native OS libraries (for example, onecoreuap.lib and kernel32.lib)
- Resolved issue that prevented AppVerifier from working
- Resolved issue that caused WACK to fail with “Task failed to enable HighVersionLie”
Downloads and tools
Get the latest editions of Visual Studio and Windows 10 development tools.LEARN MORE
Find previous releases of the Window SDK and other tools.SEE ARCHIVE