How to programmatically detect and locate the Windows 10 SDK?

Question

TL;DR

Is there a Windows registry key (or other easily-programmable way) to find & detect the Windows SDK, which works for SDK V10.0?

---

I am doing something similar to this, i.e. making use of some of the tooling accompanying the Windows 10 SDK.

I am looking for a programatic way to detect and locate the Windows SDK. This technique must work for (at least) version 10.0 (current as of this question). Preferably, I would like a technique that works for all versions (and world peace would be nice too).

Previous versions (at least up to V8.1A - as was included with Visual Studio 2013) were detectable via the windows registry. (Although V<7.0 may not have been).

For 64-bit installations: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows (note the bolded difference from 32-bit).

While for 32-bit installs: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows, and HKEY_CURRENT_USER\SOFTWARE\Microsoft\Microsoft SDKs\Windows

(More on that at the MSDN Windows SDK blog).

However, V10.0 (or V10.0A as is included with Visual Studio 2015) does not make a registry key as did previous versions!

There are techniques using compiler macros to detect the SDK version. However, these are not practical simply for SDK tool use (xsd.exe, etc), as they would require an entire compilation step - AND this would not necessarily yield a path to the SDK's tool directory!

Ideally, this should be achievable using PowerShell or a batch script or some other simple means that can be included in a build script or other automated environment (they are programming tools after all).

---

Note:

Yes there are ways to do this by interrogating the file-system, (i.e. programmatically listing subdirectories of %ProgramFiles(x86)%\Microsoft SDKs\Windows\, parsing out the 'V' and 'A'-s and selecting the max() of the numbers listed (10.0, etc)...

HOWEVER, these approaches have a number of drawbacks:

1. Quite clunky (filesystem access, string parsing, etc)
2. Error prone, an empty folder leftover from an incorrectly uninstalled SDK could brake said clunky directory parsing.
3. Subject to path differences, by platform (i.e. %ProgramFiles(x86)% on x64, but %ProgramFiles% on 32-bit), and by SDK version; SDK<7 locates tooling inside a Bin directory, while SDK>7 uses bin\NETFX X.X tools (note the lowercase 'b', just for added inconsistency).
4. Also subject to user installation choices ("clever" sys admin installed the SDK in C:\Stuff\WinSDK\V10.0\, for example).

Hence it would be MUCH better to achieve this programmatically, such as via the registry (as is possible for previous Windows SDK versions)

---

This question is not a duplicate of this one, as this question is both asking about a different SDK version, and is also asking about a programmatic (i.e. registry, etc) way to find the SDK path.

Nor is it a duplicate of this, as that question was dealing specifically with cmake and involved a build-number mismatch.

Answer 1

As of now, the best way I've found is to look at how Visual Studio's dev command does it. Currently (2019) this is found in winsdk.bat under .\Common7\Tools\vsdevcmd\core\ in your Visual Studio directory. This should help if things are changed again in the future. Even if winsdk.bat is renamed or reorganised, hopefully similar scripts will still be included.

On my system the relevant section currently looks like this:

:GetWin10SdkDir

call :GetWin10SdkDirHelper HKLM\SOFTWARE\Wow6432Node > nul 2>&1
if errorlevel 1 call :GetWin10SdkDirHelper HKCU\SOFTWARE\Wow6432Node > nul 2>&1
if errorlevel 1 call :GetWin10SdkDirHelper HKLM\SOFTWARE > nul 2>&1
if errorlevel 1 call :GetWin10SdkDirHelper HKCU\SOFTWARE > nul 2>&1
if errorlevel 1 exit /B 1
exit /B 0


:GetWin10SdkDirHelper

@REM `Get Windows 10 SDK installed folder`
for /F "tokens=1,2*" %%i in ('reg query "%1\Microsoft\Microsoft SDKs\Windows\v10.0" /v "InstallationFolder"') DO (
    if "%%i"=="InstallationFolder" (
        SET WindowsSdkDir=%%~k
    )
)

@REM `get windows 10 sdk version number`
setlocal enableDelayedExpansion

@REM `Due to the SDK installer changes beginning with the 10.0.15063.0 (RS2 SDK), there is a chance that the
@REM Windows SDK installed may not have the full set of bits required for all application scenarios.
@REM We check for the existence of a file we know to be included in the "App" and "Desktop" portions
@REM of the Windows SDK, depending on the Developer Command Prompt's -app_platform configuration.
@REM If "windows.h" (UWP) or "winsdkver.h" (Desktop) are not found, the directory will be skipped as
@REM a candidate default value for [WindowsSdkDir].`
set __check_file=winsdkver.h
if /I "%VSCMD_ARG_APP_PLAT%"=="UWP" set __check_file=Windows.h

if not "%WindowsSdkDir%"=="" for /f %%i IN ('dir "%WindowsSdkDir%include\" /b /ad-h /on') DO (
    @REM `Skip if Windows.h|winsdkver (based upon -app_platform configuration) is not found in %%i\um.`
    if EXIST "%WindowsSdkDir%include\%%i\um\%__check_file%" (
        set result=%%i
        if "!result:~0,3!"=="10." (
            set SDK=!result!
            if "!result!"=="%VSCMD_ARG_WINSDK%" set findSDK=1
        )
    )
)

Answer 2

I don't have an authoritative source for it, but it traces back from the uninstaller of the Windows 10 SDK, and it checked out on a couple of machines I looked at:

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows Kits\Installed Roots
KitsRoot10="C:\Program Files (x86)\Windows Kits\10\"

The exact version is a bit trickier to guess, since for example 10.0.10150.0, 10.0.10240.0 and 10.0.10586.0 are all subdirectories under C:\Program Files (x86)\Windows Kits\10\Include.