Windows 10 SDK

The Windows 10 SDK for Windows 10, version 1809 (servicing release 10.0.17763.132) provides the latest headers, libraries, metadata, and tools for building Windows 10 apps.

Released in conjunction with the Windows 10, version 1809. Use this SDK to building Universal Windows apps and desktop apps for Windows 10, version 1809 and previous Windows.

This SDK, originally released in October 2018, has received the following updates:

  • Addressed issue where Windows App Certification Kits crashes for any app that declares more than one Device Family in manifest
  • Addressed issue where Windows App Certification Kit failed to deploy MSIX bundle
  • Addressed issue where UWP projects that used multiple MinTargetPlatformVersions would fail with a build error related to XAML.
  • Addressed issue where deriving from SelectorAutomationPeer in IDL raises MIDL error "Unsupported array pattern detected."

Getting started

There are two ways to get the Windows 10 SDK. You can install it from this web site, by selecting the download link, or you can by select this version of the Windows 10 SDK (10.0.17763.132) in the Visual Studio 15.8 Installer optional components.

Before you install this SDK:

  1. Review all system requirements in this topic.
  2. Exit Visual Studio 2017 RTM prior to installation. If Visual Studio is running, it is possible the SDK Setup will fail. Learn more about common tool issues.
  3. Review the Known Issues in this topic.

System requirements

The Windows SDK has the following minimum system requirements:

Supported operating systems

  • Windows 10 App Development (UWP)
    • Windows 10 version 1507 or higher: Home, Professional, Education, and Enterprise (LTSB and S are not supported)
    • Windows Server 2012 R2 (Command line only) Windows Server 2016 (Command Line only)
  • Win32 Development
    • Windows 10 version 1507 or higher
    • Windows Server 2016: Standard and Datacenter
    • Windows 8.1
    • Windows Server 2012 R2
    • Windows 7 SP1

(Not all tools are supported on earlier operating systems)

Hardware requirements

  • 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.

What's new

The Windows 10 SDK for Windows 10, version 1809 offers exciting new APIs and updated tools for developing your Windows applications. Learn more about the new features in Windows 10, version 1809.


To see the new APIs introduced with Windows 10, version 1809, see: What's New in Windows 10 for developers, build 17763.



With this release of the Windows SDK (version 1809), we've made significant improvements and changes to C++/WinRT. We have better code generation, improved compatibility with the stricter conformance modes in Clang and VC++, and many more updates. For detailed information, see the C++/WinRT docs for the latest news.


We’ve made some important changes to the C/C++ ETW code generation of Message Compiler (MC, or mc.exe):

  • The -mof parameter is deprecated. This parameter instructs mc.exe to generate ETW code that is compatible with Windows XP and earlier. Support for the “-mof” parameter will be removed in a future version of mc.exe.
  • Provided that the “-mof” parameter is not used, the generated C/C++ header is now compatible with both kernel mode and user mode, regardless of whether -km or -um parameter is specified on the command line. The header uses the _ETW_KM_ macro to automatically determine whether it is being compiled for kernel mode or user mode and calls the appropriate ETW APIs for each mode.
  • The only remaining difference between -km and -um is that the EventWrite[EventName] macros generated with -km have an Activity ID parameter while the EventWrite[EventName] macros generated with -um do not.
  • The EventWrite[EventName] macros now default to calling EventWriteTransfer (user mode) or EtwWriteTransfer (kernel mode). Previously, the EventWrite[EventName] macros defaulted to calling EventWrite (user mode) or EtwWrite (kernel mode).
  • The generated header now supports several customization macros. For example, you can set the MCGEN_EVENTWRITETRANSFER macro if you need the generated macros to call something other than EventWriteTransfer.
  • The manifest supports new attributes.
    • Event “name”: non-localized event name.
    • Event “attributes”: additional key-value metadata for an event such as filename, line number, component name, function name.
    • Event “tags”: 28-bit value with user-defined semantics (per-event).
    • Field “tags”: 28-bit value with user-defined semantics (per-field – can be appliedto “data” or “struct” elements).
  • You can now define “provider traits” in the manifest (for example, provider group). If you use provider traits in the manifest, the EventRegister[ProviderName] macro automatically registers them.
  • MC now report an error if a localized message file is missing a string. (Previously MC would silently generate a corrupt message resource.)
  • MC can now generate Unicode (utf-8 or utf-16) output with the -cp utf-8 or -cp utf-16 parameters.

MSIX Support

The Windows SDK tooling has been updated to support the new MSIX format. You can now use the MakeAppx tool to package your application with MSIX, and validate your MSIX package using the Windows App Certification Kit.

VM State Dump

VmSavedStateDumpProvider.dll exposes a set of APIs to help extract dump-related content from a saved-state file for a Hyper-V virtual machine. You can now access the APIs by using the included VmSavedStateDumpProvider.lib.

For more information, see the documentation .

Windows Debugger


A released version of WinDbg Preview is available for download. Follow the Debugging Tools for Windows blog for updates on KDNET IPv6 support and documentation.

New debugger data model API

A new object-oriented debugger data model interface to support debugger automation is now available by using the dbgmodel.h header. The debugger data model is an extensible object model that's central to the way new debugger extensions (including those in JavaScript, NatVis, and C++) work- both how they consume information from the debugger and how they produce information that can be accessed from the debugger and from other extensions. Constructs written to the data model APIs are available both in the debugger's dx expression evaluator and from JavaScript extensions or C++ extensions. Documentation will be available at: Overview of the Debugger Data Model C++ Interface and dbgmodel.h header.

Windows Performance Toolkit

With the latest version of Windows Performance Recorder (WPR), WPR Profiles (WPRP) with Custom Events in TraceMergeProperties now work as intended: if a custom WPRP contains an TraceMergeProperties XML element with an empty set of Custom Events, this will no longer include the default set of Custom Events (ImageIDs, WinSat, and other defaults).

If you want the latest WPR to behave the same way as with previous versions, include the following attribute as part of the TraceMergeProperties element: Base=”TraceMerge_Default”

With the latest version of Windows Performance Analyzer (WPA), the Microsoft .NET Framework 4.5.2 is required for certain components when running on Windows 8 installations. To ensure proper use of WPA, install the latest version of .NET can be installed from


Windows 10 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 10 devices. An adapative 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 Dynamically detecting features with API contracts (10 by 10). For the latest release notes or issues with tools, see the Windows Developer Forum.