Windows SDK 8.0 fails on certain configurations

[erikvanbrakel]

When trying to install on windows server 2012R2 (specifically in AWS), the windows SDK (and potentially other packages) fail because the installer somehow fails to build the correct download URL.

Partial logs (the part where the download fails) are attached.

Notable part is the URL:
http://download.microsoft.com/download/F/1/3/F1300C9C-A120-4341-90DF-8A52509B23AC/standalonesdk/hes/8.59.29750/Windows Software Development Kit-x86_en-us.msp
http://download.microsoft.com/download/F/1/3/F1300C9C-A120-4341-90DF-8A52509B23AC/standalonesdk/Patches/8.59.29750/Windows Software Development Kit-x86_en-us.msp

It seems that for some reason, the first four characters of the relative path are being removed. Similar things happen on mwrock/Chocolatey-Packages#20

I'm going to try to find out why this happens. A possible workaround is to download the files explicitly, but I'd prefer to find the root cause if at all possible.

windows-sdk-8.0.txt
windows-sdk-8.0-failed.txt

[absolutejam]

Is there a workaround to this for now?

[patrickmaurer]

After taking a look at mwrock/Chocolatey-Packages#20 I think this is due to the same (yet unknown) root cause.
The suggested fix might work here too. However, I expect the list of files to download individually to be significantly longer.
So, before trying to get this workaround running, it would be interesting to see if the problem is related to chocolatey or if its only Win Server 2012 (R2) independent of chocolatey.
Could anyone of you do the following and post me the log files?
This is what the chocolatey package is doing (see package source):

1. Download this file: http://download.microsoft.com/download/F/1/3/F1300C9C-A120-4341-90DF-8A52509B23AC/standalonesdk/sdksetup.exe
2. In a cmd.exe (as administrator) run this command: /Quiet /NoRestart /Log %TEMP%\windows-sdk-8.0.log

If this fails too, could you also test if it suceeds if the installer is run manually?

[Musashi178]

I tested this on Win Server 2012 R2. Installing it via downloading and cmd worked.
windows-sdk-8.0.log.txt

[icnocop]

Hi.

Thank you for the Windows SDK Chocolatey packages.

I'm also experiencing this with the Microsoft Windows SDK for Windows 10 and .NET Framework 4.6 10.0.26624 (Windows 10 SDK v10.0.10240) Chocolatey package https://community.chocolatey.org/packages/windows-sdk-10.0 on Windows 10 x64.

It's not an issue with Chocolatey, as I was able to reproduce the issue without using Chocolatey.
It's not an issue with the operating system, as I was able to reproduce the issue on a different operating system.

The underlying issue is caused by the bootstrapper and occurs when building the download URLs and caused by using a short (8.3) path name to execute sdksetup.exe.

Install-ChocolateyPackage will download sdksetup.exe and run it from $env:TEMP.

Powershell resolves $env:TEMP to a short (8.3) path name.
For example, C:\Users\ADMINI~1\AppData\Local\Temp.

The sdksetup.exe bootstrapper uses the short (8.3) path name to extract the relative download file path, but uses the length of the long path as the starting index and this is why some characters are getting stripped.

In order to resolve this issue, I had to expand $env:TEMP to it's full name and use that to execute sdksetup.exe.

For example, (Get-Item $env:TEMP).FullName in PowerShell will return the long form of the path, C:\Users\Administrator\AppData\Local\Temp and using that path to execute sdksetup.exe resolves the issue.

The short path can be seen in the logs when the installation fails:

Burn v3.7.3503.0, Windows v10.0 (Build 18363: Service Pack 0), path: C:\Users\ADMINI~1\AppData\Local\Temp\sdksetup.exe, cmdline: '/features + /q  -burn.unelevated BurnPipe.{CBD3A39C-0CDA-46CC-BD81-837BA8306B70} {6B138406-A9A2-4B37-9CDF-BCAB35730CA7} 1196'
Setting string variable 'WixBundleLog' to value 'C:\Users\ADMINI~1\AppData\Local\Temp\standalonesdk\Windows_Software_Development_Kit___Windows_10.0.26624_20220626152134.log'
Setting string variable 'WixBundleOriginalSource' to value 'C:\Users\ADMINI~1\AppData\Local\Temp\sdksetup.exe'
Setting string variable 'WixBundleOriginalSourceFolder' to value 'C:\Users\ADMINI~1\AppData\Local\Temp\'

When a long path is used, the installation succeeds:

Burn v3.7.3503.0, Windows v10.0 (Build 18363: Service Pack 0), path: C:\Users\Administrator\AppData\Local\Temp\sdksetup.exe, cmdline: '/features + /q -burn.unelevated BurnPipe.{12687B91-E633-4878-82FE-196D5B129E27} {B8743B19-206D-480A-80B4-DA27BE75E329} 7540'
Setting string variable 'WixBundleLog' to value 'C:\Users\ADMINI~1\AppData\Local\Temp\standalonesdk\Windows_Software_Development_Kit___Windows_10.0.26624_20220626163801.log'
Setting string variable 'WixBundleOriginalSource' to value 'C:\Users\Administrator\AppData\Local\Temp\sdksetup.exe'
Setting string variable 'WixBundleOriginalSourceFolder' to value 'C:\Users\Administrator\AppData\Local\Temp\'

Here is an example of what the erroneous code which builds the download URL would look like :

void Main()
{
	string shortLocalSourcePath = @"C:\Users\ADMINI~1\AppData\Local\Temp\"; // WixBundleOriginalSourceFolder
	string longLocalSourcePath = @"C:\Users\Administrator\AppData\Local\Temp"; // ex. local download path
	
	string downloadRootUrl = "https://download.microsoft.com/download/E/1/F/E1F1E61E-F3C6-4420-A916-FB7C47FBC89E/standalonesdk/";
	string relativeLocalFilePath = @"Installers\Application Verifier x64 External Package-x64_en-us.msi";
	
	string shortLocalFilePath = Path.Combine(shortLocalSourcePath, relativeLocalFilePath);
	Console.WriteLine(shortLocalFilePath); // C:\Users\ADMINI~1\AppData\Local\Temp\Installers\Application Verifier x64 External Package-x64_en-us.msi
	string localSourceFolder = Path.GetDirectoryName(shortLocalSourcePath);
	Console.WriteLine(localSourceFolder); // C:\Users\ADMINI~1\AppData\Local\Temp
	
	string relativeDownloadFilePath = shortLocalFilePath.Substring(longLocalSourcePath.Length); // <-- this is the erroneous logic
	Console.WriteLine(relativeDownloadFilePath); // allers\Application Verifier x64 External Package-x64_en-us.msi
	
	string downloadUrl = downloadRootUrl + relativeDownloadFilePath.Replace("\\", "/");
	Console.WriteLine(downloadUrl); // https://download.microsoft.com/download/E/1/F/E1F1E61E-F3C6-4420-A916-FB7C47FBC89E/standalonesdk/allers/Application Verifier x64 External Package-x64_en-us.msi
}

[patrickmaurer]

@icnocop don't you think this issue should be addressed in choco itself, probably something like this: patrickmaurer/choco@0e8fb85

[icnocop]

I think this issue was fixed in chocolatey v0.10.0, released on August 11, 2016, and newer versions, see chocolatey/choco#840 and https://docs.chocolatey.org/en-us/choco/release-notes#august-11-2016, but I have yet to confirm.

I was also preparing a fix for this in choco.

But I wanted to confirm this is still an issue in the latest version before creating a pull request, etc.

[icnocop]

I have verified this on Windows 10.0 64-bit build 10240 (Version 1507), where %TEMP% expands to C:\Users\ADMINI~1\AppData\Local\Temp:

1. Failure, as expected, with the 8.3 path indicated in the log file, with an older version of chocolatey:
   a. Install chocolatey 0.9.8.28
   b. Run choco install windows-sdk-8.0 -y

2. Success, with a newer version of chocolatey:
   a. Install chocolatey 0.10.0
   b. Run choco install windows-sdk-8.0 -y --allowEmptyChecksums

So this issue can be closed in my opinion since this is already "fixed" in (at least) chocolatey 0.10.0.

[patrickmaurer]

Thanks for testing and letting me know!