1

I am trying to install Windows 10 SDK and alternatively the Standalone Developmet Kit on two separate windows 10 PC's and it failes on either...

In both cases the log says: "Hash mismatch for path: C:\ProgramData\Package Cache....

It happened multiple times, even after deleting all files in "package Cache" folder. Is there any solution to this? It seem it's just impossible to download WDK at all... Is there any resolution to this? Is there anyway I can just download the ISO and install from there?

ivan_pozdeev
  • 1,897
  • 18
  • 34
rubmz
  • 113
  • 7
  • Could you copy the entire message here, and any relevant mesages? It's important which package it is. – ivan_pozdeev Dec 03 '16 at 14:40
  • Error 0x80091007: Hash mismatch for path: C:\ProgramData\Package Cache\.unverified\package_WindowsSDKDesktopHeadersLibsMetadata_x86_en_us, expected: 4B624A71D3DC56B824AF9848D1633604E8D77B9C, actual: CD7071D65A0539FBCF12AEE16599A2609E1EDA80 – rubmz Dec 03 '16 at 17:15
  • 1
    Same problem with WDK, – Yuriy Vasylenko Jul 13 '18 at 09:47

2 Answers2

1

Other reports on this error (1,2,3) testify that it is caused by corrupt downloads. You can very well get these consistenty if your network is unreliable and the downloading software is not sophisticated enough to deal with interrupted transfers or large delays (I had such problems with Mercurial).

You can download a standalone version of SDK as per Windows 10 sdk offline installer?, but M$ only offers to download with its own program, so it's subject to the same problems.

Another possible reason is a bug in the downloader, as RC1 Error 0x80091007: Hash mismatch for path: DotNetVersionManager_x64 · Issue #1085 · aspnet/Home, the 2nd link above, suggests: hashes are checked against files from a different version if they happen to be present. You fix that by deleting whatever the checks are done against - temporary files and any MSIs in the directory you're downloading to (or just download to an empty folder).

Community
  • 1
ivan_pozdeev
  • 1,897
  • 18
  • 34
  • 1
    This is clearly not a corrupt download... Unless the source is corrupt. From what I gather, this is a stupid mechanism were the hashes are installed by one program (Version XX) and is checked against another (version yy)... They got to employ the greatest and the brightest if they made it happen only on the "community" edition – rubmz Dec 03 '16 at 17:10
  • @rubmz Well, you can use some tools like 7-Zip or Orca to check the file's integrity manually. – ivan_pozdeev Dec 03 '16 at 18:00
  • 1
    @rubmz if that's the faulty checking then, according to https://github.com/aspnet/Home/issues/1085 , you fix that by deleting whatever the checks are done against - temporary files and any MSIs in the directory you're downloading to (or just download to an empty folder). – ivan_pozdeev Dec 03 '16 at 18:03
  • MAN! YOU ARE GOD! They have the right solution!! JUST PUT THE DAMN FILE IN A CLEAN FOLDER. STUPID STUPID BUG MS – rubmz Dec 03 '16 at 18:13
  • @rubmz I can see the mechanism for this bug: it checks if a file is present but doesn't check if it belongs to the current distribution. It's nontrivial to do that (it's impossible to reliably tell if it's "foreign" or just corrupt), so I can see why they didn't bother as long as there's a workaround. – ivan_pozdeev Dec 03 '16 at 18:38
  • 1
    NO. I DON'T SEE THE LOGIC. THAT'S JUST BUG. – rubmz Dec 03 '16 at 18:49
0

Just so the answer is clearer: You download sdksetup.msi TO A CLEAN FOLDER - WITH NO OTHER FILE/FOLDER IN IT Now it should work. What a shameful bug! Unbelievable...

rubmz
  • 113
  • 7