Ошибка при установке visual studio 2015

Время на прочтение
8 мин

Количество просмотров 119K

Решили мы как-то перевести свой проект на Visual Studio 2015 — там ведь столько захватывающих фич! Вчера вот только решили, а уже сегодня утром я запустил её инсталлятор. Небо было безоблачным, ничто не предвещало беды. Ну что, в самом деле, может пойти не так? Сколько уже этих Visual Studio переставлено — не счесть (я, помнится, ещё 6.0 когда-то ставил). Кто бы мог подумать, что эта тривиальнейшая задача может вылиться в весьма неожиданный забег по граблям длинной почти в целый рабочий день.

Похрустев немного жестким диском, красивый инсталятор показал мне совершенно некрасивое сообщение об ошибке. Вот такое:

Хм. Не поставился значит, Team Explorer и ещё пару минорных пакетов. Ну ок. Закрываем, переустанавливаем. Не помогает. Удаляем студию, перезагружаемся, устанавливаем — та же ошибка. Лезем в Гугл с вопросом об ошибке установки Visual Studio 2015 на этапе инсталляции компонента Team Explorer и понимаем, что проблема это массовая — десятки ссылок с тем же описанием:
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

Отвечают на все эти вопросы специалисты первой линии техподдержки Microsoft, советы которых сводятся к «отключите антивирус», «проверьте чексуму образа со студией», «проверьте диск на ошибки». Ничего из этого, конечно, не помогает, о чём им и рассказывают, после чего они пропадают и больше не отвечают. Очень дружелюбная пользовательская поддержка, ничего не скажешь.

Ну что же, пора включать голову, брать в руки инструменты и разбираться. Поехали.

Итак, всё что у нас есть, это входная точка ошибки — проблема с Team Explorer. И ссылочка на лог-файл на приведённом выше скриншоте. Ну ок, давайте пойдём почитаем что там лог-файл думает о нашей ошибке.

[15FC:1A18][2015-11-26T17:30:17]i000: MUX:  ExecutePackageBegin PackageId: vs_teamExplorerCore
[2118:2240][2015-11-26T17:30:17]i301: Applying execute package: vs_teamExplorerCore, action: Install, path: C:ProgramDataPackage Cache{791295AE-3B0A-3222-9E69-26C8C106E8D1}v14.0.23102packagesTeamExplorerCorevs_teamExplorerCore.msi, arguments: ' MSIFASTINSTALL="7" USING_EXUIH="1"'
[15FC:1A18][2015-11-26T17:31:06]i000: MUX:  ExecuteError: Package (vs_teamExplorerCore) failed: Error Message Id: 1722 ErrorMessage: There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.  
[2118:2240][2015-11-26T17:31:09]e000: Error 0x80070643: Failed to install MSI package.
[2118:2240][2015-11-26T17:31:09]e000: Error 0x80070643: Failed to execute MSI package.
[15FC:1A18][2015-11-26T17:31:09]e000: Error 0x80070643: Failed to configure per-machine MSI package.
[15FC:1A18][2015-11-26T17:31:09]i000: MUX:  Installation size in bytes for package: vs_teamExplorerCore MaxAppDrive: 0  MaxSysDrive: 440487936  AppDrive: 0  SysDrive: 263573504
[15FC:1A18][2015-11-26T17:31:09]i000: MUX:  Return Code:0x80070643 Msi Messages:There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.   Result Detail:0 Restart:None
[15FC:1A18][2015-11-26T17:31:09]i000: MUX:  Set Result: Return Code=-2147023293 (0x80070643), Error Message=There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.  , Result Detail=, Vital=True, Package Action=Install, Package Id=vs_teamExplorerCore
[15FC:1A18][2015-11-26T17:31:09]i000: Setting string variable 'BundleResult' to value '1603'
[15FC:1A18][2015-11-26T17:31:09]i319: Applied execute package: vs_teamExplorerCore, result: 0x80070643, restart: None
[15FC:1A18][2015-11-26T17:31:09]e000: Error 0x80070643: Failed to execute MSI package.

Всё, что можно понять из этого лога, это то что компонент ставился-ставился, да что-то не поставился. Бывает, мол, чего уж там. Ну, спасибо большое за информацию!

Ладно, давайте зайдём с другой стороны. Team Explorer это (как и почти всё в современных версиях Visual Studio) — VSIX (компонент, расширение). Ставится отдельно от ядра студии специальной программой VSIXInstaller.exe, которая живёт в C:Program Files (x86)Microsoft Visual Studio 14.0Common7IDE и умеет при установке этих самых VSIX-компонентов писать во временную папку (ну, ту, которая %TEMP%) логи о том, как всё прошло. Идём в %TEMP%, находим по времени ошибки из лога выше файлик, соответствующий установке Team Explorer. Вот он:

26.11.2015 17:31:01 - Microsoft VSIX Installer
26.11.2015 17:31:01 - -------------------------------------------
26.11.2015 17:31:01 - Initializing Install...
26.11.2015 17:31:01 - Extension Details...
26.11.2015 17:31:01 - 	Identifier      : Microsoft.VisualStudio.TeamFoundation.TeamExplorer.Extensions
26.11.2015 17:31:01 - 	Name            : Team Foundation Team Explorer Extensions
26.11.2015 17:31:01 - 	Author          : Microsoft
26.11.2015 17:31:01 - 	Version         : 14.0.23102
26.11.2015 17:31:01 - 	Description     : Team Foundation extensions for Team Explorer
26.11.2015 17:31:01 - 	Locale          : en-US
26.11.2015 17:31:01 - 	MoreInfoURL     : 
26.11.2015 17:31:01 - 	InstalledByMSI  : False
26.11.2015 17:31:01 - 	SupportedFrameworkVersionRange : [0.0,2147483647.2147483647]
26.11.2015 17:31:01 - 
26.11.2015 17:31:06 - 	SignedBy        : Microsoft Corporation
26.11.2015 17:31:06 - 	Certificate Info : [Subject]
  CN=Microsoft Corporation, OU=MOPR, OU=OPC, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

[Issuer]
  CN=Microsoft Code Signing PCA 2010, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

[Serial Number]
  33000000A81581DB462EBDD9480000000000A8

[Not Before]
  05.03.2015 1:42:40

[Not After]
  05.06.2016 2:42:40

[Thumbprint]
  EFCF3B47C17854AB6E4C63821DE31A59B24D62B2

26.11.2015 17:31:06 - 	Supported Products : 
26.11.2015 17:31:06 - 		Microsoft.VisualStudio.IntegratedShell
26.11.2015 17:31:06 - 			Version : [14.0]
26.11.2015 17:31:06 - 		Microsoft.VisualStudio.Express_All
26.11.2015 17:31:06 - 			Version : [14.0]
26.11.2015 17:31:06 - 
26.11.2015 17:31:06 - 	References      : 
26.11.2015 17:31:06 - 
26.11.2015 17:31:06 - Searching for applicable products...
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)
   at VSIXInstaller.SupportedSKUs.AddInstalledIsolatedShells(Version vsVersion)
   at VSIXInstaller.SupportedSKUs..cctor()
   --- End of inner exception stack trace ---
   at VSIXInstaller.SupportedSKUs.get_SupportedSKUsList()
   at VSIXInstaller.App.InitializeInstall(Boolean isRepairSupported)
   at VSIXInstaller.App.OnStartup(StartupEventArgs e)
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)
   at VSIXInstaller.SupportedSKUs.AddInstalledIsolatedShells(Version vsVersion)
   at VSIXInstaller.SupportedSKUs..cctor()
   --- End of inner exception stack trace ---
   at VSIXInstaller.SupportedSKUs.get_SupportedSKUsList()
   at VSIXInstaller.App.OnExit(ExitEventArgs e)

Ну, тут уже побольше всякого интересного написано, конечно. Нас интересует первый момент, когда что-то пошло не так. Вот он:

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)


Хм, произошла ошибка при попытке загрузить сборку Microsoft.VisualStudio.Settings.14.0.dll. Первой моей мыслью было то, что студия как-то запуталась в порядке установки своих компонентов и пытается использовать при установке что-то, что ещё не установилось куда надо. Так, есть у нас в системе такая библиотека?

Оказалось — есть. Лежит в GAC, там где ей и положено лежать:

Так, что же получается? Сборка есть, она находится там, где нужно, но не загружается. Может быть, битая? Берём IL DASM, загружаем — всё ок.

Может быть умельцы из Microsoft сумели написать такой инсталлятор, у которого иногда получается не найти сборку в GAC? Берём Process Monitor, добавляем в него фильтр на открытие файлов и снова запускаем инсталлятор студии. Доходим до ошибки, смотрим логи.

Так, инсталлятор ищет Microsoft.VisualStudio.Settings.14.0.dll и находит её ровно там, где она и должна быть — в GAC. Ок, что же не так?
Читаем ещё раз сообщение об ошибке: «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.». Так, если сама Microsoft.VisualStudio.Settings.14.0.dll есть и валидна — может быть дело в одной из её зависимостей? Возвращаемся в Process Monitor и смотрим что там загружается непосредственно после нашей сборки.

Ага, vcruntime140.dll загружается. Это redistributable-библиотека от Visual Studio 2015. Ну, она-то точно должна была поставиться на одном из первых этапов установки! Но давайте проверим, чем уже чёрт не шутит.

Проверка раз — в списке установленных программ:

Проверка два — в папке C:WindowsSysWOW64:

Проверка три — это, собственно, «SUCCESSS» в логе Process Monitor:

Последняя проверка — вообще железобетонный аргумент: видите, поискали, попробовали открыть, открылось успешно — значит файл найдён. Всё, подозрения снимаются, идём дальше. Так, какую-же библиотеку инсталлятор VSIX пытается подгрузить следующей по логами Process Monitor?

Как это опять vcruntime140.dll уже в другой папке?! Получается, найдя vcruntime140.dll в папке C:WindowsSysWOW64 и успешно её открыв (а мы знаем что так и было по логам выше!) загрузчик зависимостей всё-же почему-то счёл её недостаточно хорошей и отбросил. Как же так?! Это что — не майкрософтовская библиотека? Смотрим свойства:

Да нет, нормальная библиотека. Почему же не загрузилась? Давайте посмотрим на неё внимательнее. Для этого в составе любой версии Visual Studio есть отличная утилита dumpbin. Запускаем её с вот такими ключами:

dumpbin /headers c:windowsSysWOW64vcruntime140.dll

и смотрим на результаты:

Microsoft (R) COFF/PE Dumper Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file c:windowsSysWOW64vcruntime140.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
....

Подождите-подождите… А почему это ты, библиотечка, 64-битная?! Ты же лежишь в папке C:windowsSysWOW64, где вообще-то место только 32-битным библиотекам! А ну-ка давайте посмотрим, что же тогда лежит в C:WindowsSystem32?

А то же самое (кто не верит в размер — можете проверить каким-нибудь WinMerge, они идентичны). Вы уже уловили, в чём суть? Ошибка закралась в инсталятор Redistributable-компонентов, входящий в инсталятор Visual Studio 2015 — он просто ставит 64-битные версии рантайм-библиотек и в папку для 64-битных библиотек (C:WindowsSystem32) и в папку для 32-битных (c:windowsSysWOW64). В итоге при дальнейшей попытке использования 64-битной версии всё будет ок, а вот при попытке загрузки 32-битной версии будет то, что мы увидели при установке Team Explorer — загадочные ошибки вообще без упоминания библиотеки vcruntime140.dll и Redistributable-пакета. И делай, что хочешь.

А что же мы хотим делать? А удалить x86-часть Redistributable-пакета Visual Studio 2015, скачать её отдельно с сайта Microsoft и переустановить. Сюрприз — на сайте Microsoft версия правильная, она установит 32-битную версию библиотеки в C:windowsSysWOW64, после чего можно перезапустить установку Visual Studio 2015 и она успешно дойдёт до конца!

Happy end.

Осталось как-то объяснить начальству почему это я целый день устанавливал Visual Studio, если с этим дети в третьем классе за час справляются. В общем-то ради этой цели и была написана данная статья, а уж зачем вы её прочли — я не знаю

P.S. Справедливости ради следует отметить, что поиск по той же проблеме с упоминанием слов «redistributable» и «vcruntime140» всё-таки выводит на одиноко валяющийся на обочине Stackoverflow вопрос с правильным ответом (кто-то прошел тот же путь, что и я!), который в виду своей низкой оценки(«+1» на момент написания статьи) не воспринимается людьми, как настоящее решение проблемы. Не будем забирать у автора того ответа пальму первенства и плодить лишние сущности, если описанная в статье проблема коснулась и вас, а предложенное решение помогло — вы можете проголосовать за этот ответ на Stackoverflow.

i apologize up front: this is not going to directly answer the OP’s question, but when i searched around for «a setup package is either missing or damaged» while trying to offline-install (from unpacked ISO) VS2105 on my (corporate, internet-starved) build server, there were lots of others with same problem with very little help, and this was the top 1 google hit for that dreaded error message…

here’s the deal: i was setting up TFS build agent on corporate server with all kinds of security lock down (including access to internet) from an MSDN subsription VS2015w/U3 ISO (unpacked). ran installer — got the error. after rifling through not-so-helpful SO/MS Connect/etc postings, i was able to glean that the digital signatures on some of the sub-packages were failing validation.

if you know anything about PKIs, read this paragraph if you want, if not skip. there was mention that certain CRLs and CA chains were pushed out via Windows updates/patches. who knows if this server has been patched… it certainly could not do it through automatic win updates. in a nut shell, i needed some way to get those missing items so that the digital signature verification would pass. i thought to myself «why would it work on my local machine, because it is on the same patching schedule as the server (presumably, i don’t know for sure)». then it occurred to me that one reason MS offers web installers is just this problem… it then occurred to me that they might have a «best effort» kind of strategy for resolving this kind of thing in their offline installer.

(preface: bear in mind that while this worked in a fairly common corporate set up, they’re all different and this might not work for everyone)

what i needed was the ability to run the installer on the server, but somehow get it internet access. so i opened Fiddler, allowed other machines to connect to it, configured the server’s internet connection settings >> LAN settings to use my machine as a proxy. first make sure that HTTPS is enabled in Fiddler, then open it up, turn in on, go back to your server (that you configured to proxy via your machines IP address and the port that Fiddler uses; default is 8888) and run the installer. you can actually watch the PKI activity in the request captured by Fiddler, among other http-based traffic). the key of this proxy approach is that the server can get what it need from the web, while all that traffic appears to be coming from your machine, from the network firewall’s point of view.

anyhow, i hope this saves someone else the 2 days of pain it caused me.

(I encountered the identical issue. After many tries I SOLVED it and located the MY ROOT CAUSE. I keep my try path here but you can skip to the end if you want.)

I want to point it out that BE VERY CAREFUL WITH enden’s solution 2. Some other programs may cache installation packages in the C:ProgramDataPacakges Cache folder. If you remove data from that folder, you may jeopardize other programs installation/uninstallation.

I encountered this multiple failures during install VS2015. And after I remove all the content from the C:ProgramDataPacakges Cache, both my VS2013 and VS2015 stuck in the Programs and Features window and I cannot change/repair/uninstall them.

To fix the change/repair/uninstall failure, I have to go to below 2 registry keys:

First of all: BACKUP YOUR REGISTRY BEFORE YOU DO ANYTHING TO IT.

[HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeMicrosoftWindowsCurrentVersionUninstall]

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionUninstall]

And remove every key whose InstallLocation points to the C:ProgramDataPacakges Cache AND whose DispalyName looks related to Visual Studio 2013/2015 (this may requrie some experience/intuition).

Then, the stuck items of VS2013/2015 in Program & Features window are gone. And now I am able to re-install the VS2013.

But I still cannot install VS2015 with the installer. The error is still as below:

But at least I can change/repair/uninstall VS2015 in the Prgram & Features window. So I choose to repair it. But the repair doesn’t work. I still got the same error as above.

Then I uninstalled the failed VS2015 and tried to repair the VC++2015 redist as said in TimVdG‘s marked answer. And then reinstall VS2015 with the installer.

Still failed.

Then I tried Brian Swart’s solution to install VS2015 without Update 1. But it still failed with TeamExplorer. I checked the log and found this:

MSI (s) (48:A0) [14:53:34:997]: Windows Installer installed the
product. Product Name: Team Explorer for Microsoft Visual Studio 2015.
Product Version: 14.0.23102. Product Language: 1033. Manufacturer:
Microsoft Corporation. Installation success or error status: 1603.

And I googled a bit about 1603 error. Now I am trying to add full control to the C:Program Files (x86)Microsoft Visual Studio 14.0 folder and try again.

Still doesn’t work.

Some refs:

Remove Stuck Entries from Programs and Features

https://support.microsoft.com/en-us/help/247501/how-to-manually-remove-programs-from-the-add-remove-programs-list

https://superuser.com/questions/401511/how-to-remove-a-broken-program-from-the-programs-and-features-list-in-windows-7

=========> The Final Solution <=========

So in my scenario, it has nothing to do with the VC2015 redistributables.

My root cause is the incorrect .NET version number in the registry.

On a 64bit Windows, .NET version is stored in 2 places in registry:

HKLMSoftwareMicrosoftNET Framework SetupNDPv4FullVersion

HKEY_LOCAL_MACHINESOFTWARE**WOW6432Node**MicrosoftNET Framework
SetupNDPv4FullVersion

Below is what my box has:

Note that leading character v in the Version? I don’t know who put it there. But once I removed it, my VS2015 with Update 3 can be installed smoothly!

So you may wonder how could I find this. Well, since I couldn’t install VS2015, I turned to VS2017. But after intalled VS2017 successfully, I couldn’t launch it. It says this:

So I decided to check the installed .NET version and saw the interesting difference above. Once I removed the leading v, VS2017 can be started.

But anyway, I still don’t know who put the v there… Shame on it!

Last but not the least: Please also make sure the Release, Version registry key value are consistent and can work with your Windows version. Refer to below:

.NET and Windows version dependencies.

how to determine the installed .NET version.

Windows 10 version info

Add some more findings:

After I finished this install sequence: VS2017 -> VS2015 -> VS2013, I noticed that there’s even no VC++2015 redist on my box:

Because both VC++ 2015 and VC++2017 redists are 14.xxx. So having the higher version is enough. When I try to manually install VC++ 2015 redist, it says this: