Incorrect hash value when installing Visual Studio 2013 Update 2

Visual Studio 2013 Update 2 RC introduces some cool new features and adds an option to slipstream the install of VS2013 RTM with Update 2 RC, but some attempts to download it have had the following problem.

Problem

When installing VS2013 Update 2 you see the error or warning message, “The hash value is not correct.” This will show up as either an error or a warning depending on the package.

If you open the log file by clicking on the link in the Finish page, you may see an error like the following,

[1543:4DC8][2014-04-03T13:05:00]e000: Error 0x80091007: Hash mismatch for path: C:\ProgramData\Package Cache\.unverified\tfs_objectmodelcore_x64
[1543:4DC8][2014-04-03T13:05:00]e000: Error 0x80091007: Failed to verify hash of payload: tfs_objectmodelcore_x64

Workaround

Try saving the setup executable, e.g. VS2013.2.exe, to a different location and running setup again. If you created an offline layout with the /layout switch as described in our administrator guide, trying creating a layout in a different, empty directory.

More Information

So far we have only been able to reproduce this problem when the location of the setup executable already contains an offline layout. An example of when we see this problem is when, say, the VS2013.2 RC setup executable is downloaded to a folder with an existing layout for CTP1.

Burn, the setup chainer we use from WiX, validates the Authenticode signature of payloads but also verifies the raw file hash. The Authenticode verification tells Burn the file has not been tampered with and came from Microsoft, but the raw file hash tells Burn that the payload is the correct payload for the current install. So if the setup source location contains files with the same name and a valid Authenticode signature but for a previous install (whether VSUpdate or even VS RTM), you will see this error for some packages or their payload.

If this describes your situation, please try the workaround above.

If this does not describe your situation, please consider filing a bug on Connect with logs from our log collection tool to help us diagnose other possible causes of this problem. For example, while a bad download could yield such a result and in some possible cases pass Authenticode verification (for non-impactful runtime changes, but which invalidates the raw file hash), since we attempt to download several times using different mechanisms a repeat failure for the same package seems unlikely. Understanding more about your network environment could prove useful to preventing this issue.