Investigation of the installation error Visual Studio 2015

We decided to somehow translate your project to Visual Studio 2015 - there are so many exciting features ! Yesterday they just decided, and this morning I launched its installer. The sky was cloudless, nothing foretold trouble. Well, in fact, can go wrong? How many of these Visual Studio has been rearranged - do not count (I, I remember, even 6.0 once put). Who would have thought that this trivial task could turn into a very unexpected race on a rake almost a whole working day.

Crackling a little hard drive, a beautiful installer showed me a completely ugly error message. Here it is:


Hm Not set means Team Explorer and a couple of minor packages. Well, OK. Close, reinstall. Does not help. Delete the studio, reboot, install - the same error. We climb into Google with a question about the installation error of Visual Studio 2015 during the installation phase of the Team Explorer component and we understand that the problem is massive - dozens of links with the same description:
1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 10 , 11 , 12 , 13 , 14 , 15 , 16 , 17
')
Microsoft's first-line technical support specialists answer all these questions; their advice comes down to “disable antivirus”, “check the studio image”, “check the disk for errors”. None of this, of course, helps, which is what they are told about, after which they disappear and no longer respond. Very friendly user support, you will not say anything.

Well, it's time to turn on your head, pick up the tools and figure it out. Go.

So, all we have is the entry point of the error — a problem with Team Explorer. And a reference to the log file in the above screenshot. Well, ok, let's go read what the log file thinks about our error.



All that can be understood from this log is that the component was installed, installed, but something was not installed. It happens, they say, what is already there. Well, thanks a lot for the info!

Okay, let's go on the other side. Team Explorer is (like almost everything in modern versions of Visual Studio) - VSIX (component, extension). It is installed separately from the studio's core by the special program VSIXInstaller.exe, which lives in C: \ Program Files (x86) \ Microsoft Visual Studio 14.0 \ Common7 \ IDE and can write to the temporary folder when installing these same VSIX components (well, % TEMP%) logs about how it went. Go to% TEMP%, find the time error from the log above the file corresponding to the installation Team Explorer. Here he is:



Well, there is already more interesting written, of course. We are interested in the first moment when something went wrong. Here he is:

26.11.2015 17:31:06 - System.TypeInitializationException: The type initializer for 'VSIXInstaller.SupportedSKUs' threw an exception. ---> System.BadImageFormatException: Could not load file or assembly 'Microsoft.VisualStudio.Settings.14.0.dll' or one of its dependencies. is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)


Hmm, an error occurred while trying to load the Microsoft.VisualStudio.Settings.14.0.dll assembly. My first thought was that the studio was somehow entangled in the order of installing its components and trying to use something that was not yet installed when installing. So, do we have such a library in our system?

It turned out - there is. It lies in the GAC, where it is supposed to lie:



So what happens? The assembly is there, it is where it is needed, but it does not load. Maybe broken? We take IL DASM, we load - everything is ok.



Maybe the craftsmen from Microsoft managed to write such an installer, who sometimes fails to find the assembly in the GAC? We take Process Monitor, add a filter for opening files to it and run the studio installer again. We reach the error, look at the logs.



So, the installer is looking for Microsoft.VisualStudio.Settings.14.0.dll and finds it exactly where it should be - in the GAC. Ok, what's wrong?
We read again the error message: "System.BadImageFormatException: Could not load file or assembly 'Microsoft.VisualStudio.Settings.14.0.dll' or one of its dependencies . is not a valid Win32 application. ”. So, if Microsoft.VisualStudio.Settings.14.0.dll itself is valid, can it be in one of its dependencies? We return to Process Monitor and see what is loaded there immediately after our build.



Aha, vcruntime140.dll is loading. This is a redistributable library from Visual Studio 2015. Well, it definitely should have been installed at one of the first stages of installation! But let's check what the devil is not joking.

Check times - in the list of installed programs:



Check two - in the folder C: \ Windows \ SysWOW64 \:



Check three is, in fact, “SUCCESSS” in the Process Monitor log:


The last check is generally a reinforced concrete argument: see, searched, tried to open, opened successfully - then the file was found. Everything, suspicions are removed, we go further. So, what kind of library does the VSIX installer try to load next with the Process Monitor logs?



How is it again vcruntime140.dll already in another folder ?! It turns out, having found the vcruntime140.dll in the C: \ Windows \ SysWOW64 \ folder and successfully opened it (and we know that this was the case in the logs above!), The dependency loader, for some reason, found it not good enough and dropped it. How so?! Is this a non-Microsoft library? Look at the properties:



No, normal library. Why didn't it boot? Let's take a closer look at it. For this, any version of Visual Studio has an excellent dumpbin utility. Run it with these keys:

 dumpbin /headers c:\windows\SysWOW64\vcruntime140.dll 

and look at the results:

 Microsoft (R) COFF/PE Dumper Version 10.00.40219.01 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file c:\windows\SysWOW64\vcruntime140.dll PE signature found File Type: DLL FILE HEADER VALUES 8664 machine (x64) 7 number of sections 558CE2FF time date stamp Fri Jun 26 08:28:31 2015 0 file pointer to symbol table 0 number of symbols F0 size of optional header 2022 characteristics Executable Application can handle large (>2GB) addresses DLL .... 

Wait-wait ... And why is it you, the library, 64-bit ?! You are in the folder C: \ windows \ SysWOW64 \, where in general there is only 32-bit libraries! Well let's see what then lies in C: \ Windows \ System32?



And the same thing (who does not believe in size - you can check with some WinMerge, they are identical). You have already caught, what is the point? The error crept into the installer of the Redistributable components included in the installer of Visual Studio 2015 — it simply puts the 64-bit versions of the runtime libraries and the folder for 64-bit libraries (C: \ Windows \ System32) and the folder for 32-bit (c : \ windows \ SysWOW64 \). As a result, if you further try to use the 64-bit version, everything will be ok, but when you try to download the 32-bit version, you will see what we saw when installing Team Explorer - mysterious errors in general without mentioning the vcruntime1.dll and Redistributable packages. And do what you want.

And what do we want to do? And remove the x86-part of the Redistributable-package Visual Studio 2015, download it separately from the Microsoft website and reinstall. Surprise - on the Microsoft website the correct version, it installs the 32-bit version of the library in C: \ windows \ SysWOW64, after which you can restart the installation of Visual Studio 2015 and it will reach the end successfully!

Happy end.



It remains to explain somehow to the authorities why I installed Visual Studio all day long if the children in the third grade were coping in an hour. In general, this article was written for this purpose, and I don’t know why you read it :)

PS For the sake of justice, it should be noted that a search for the same problem with the mention of the words “redistributable” and “vcruntime140” still brings to the lonely question on the side of Stackoverflow with the correct answer (someone went the same way as me!) which, due to its low rating ("+ 1" at the time of writing), is not perceived by people as a real solution to the problem. We will not take the palm of primacy from the author of that answer and produce unnecessary entities if the problem described in the article touched you, and the proposed solution helped - you can vote for this answer on Stackoverflow.