151,72
рейтинг
27 ноября 2015 в 00:44

Разработка → Расследование ошибки установки Visual Studio 2015 tutorial

Решили мы как-то перевести свой проект на 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:\ProgramData\Package Cache\{791295AE-3B0A-3222-9E69-26C8C106E8D1}v14.0.23102\packages\TeamExplorer\Core\vs_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.0\Common7\IDE и умеет при установке этих самых 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:\Windows\SysWOW64\:



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


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



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



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

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


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

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
....


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



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

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

Happy end.



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

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

Комментарии (23)

  • 0
    Чтобы установить MS VS 2013 с последним SP нужно было качать кастомный инсталлятор, патч, и англофикатор. (И это при использовании лицензионного продукта)
    • –1
      А что бы обновить MS VS 2013 с sp 4 до sp 5. Потребовалось запустить веб-инсталяшку. Подождать пока она скачает и установит sp 5.
      Запустить MS VS 2013 и увидеть ошибку «A problem occurred when loading the Microsoft Visual Menu» (и совет выполнить «devenv /resetsetting»).
      devenv /resetsetting не помогает. Гуглинг помог найти решение «devenv.exe /setup». И оно помогло.
      Получается накатка sp 5 ломает Microsoft Visual 2013.
  • +11
    Вот такой вот бред реально бесит. Я про мучения, конечно, пост сам годный.
  • +4
    Ацкий дебаг банальных вещей, как и всё у МС, а главное результат в /dev/null — они же не поправят: надо быть бронебойным дятлом или знать сразу кому именно писать.
  • +4
    что только люди не делают без syslog/messages
    • +2
      В винде есть журнал событий. Если бы еще приложения туда хоть что-то полезное писали… :)
    • +3
      Да уж скорее без strace и gdb. Но под Windows набор Debug View + Process Monitor + Api Monitor + WinDbg делаёт всё то же самое и даже больше.
  • +5
    Переход на новую версию VS, .NET и прочего — большой риск.
    У новичков всегда буря эмоций по этому поводу
    • +1
      Это касается любого продукта любой фирмы. JAVA поэтому и сидит на 6-7 версии и боятся переходить. Там даже несовместимость есть, чего нельзя сказать про .NET.
  • +12
    > он просто ставит 64-битные версии рантайм-библиотек и в папку для 64-битных библиотек (C:\Windows\System32) и в папку для 32-битных (c:\windows\SysWOW64\)

    А почему папка для 64-битных приложений имеет в названии 32, а для 32-битных — 64? Где логика? И почему они обе не называются System32 и System64 например?
    • +9
      Так сложилось исторически: System32 — это Главная Системная Папка, там лежат файлы «главной» разрядности, ее не стали переименовывать чтобы не порушить обратную совместимость.

      WOW64 — это слой совместимости, он расшифровывается как Windows on Windows 64
      • +1
        Странно и довольно костыльно.
        В MS уже не раз делали перенаправление со «старых» имён на «новые» через Junction.
        Для создания более логичной структуры каталогов, ИМХО, могли как раз воспользоваться ими.
  • 0
    tangro а как ставили саму студию? Веб-инсталятором или из образа?

    Подобные ошибки в инсталяторе наводят на мысль о том, что этот баг прошел мимо тестеров.
    • +1
      Из образа (чек-суму проверил).
  • 0
    Не далее как в начале недели поставил студию 2015, так отвалилась 2013, установленная на той же машине — все проекты открывались с ошибкой. Глубоко лезть не стал, так как тупой ремонт 2013й помог (запустил установщик последнего сервис-пака, он и отремонтировал).
    Вообще когда я налетаю на такие грабли, я пробую ставить продукт на чистый Windows в виртуалке — у меня всегда образ голой ОС в VMWare под рукой со всеми установленными апдейтами. Не факт, что бага не в самой студии, а в одном из предшествующих продуктов (весьма популярном, судя по количеству репортов), который бросил файл в неверную папку, либо что-то в реестре поменял. Если бы это поведение воспроизводилось на голой системе, то Студию вообще никто поставить бы не мог. Судя по всему, там что-то уже было в системе, что и вызвало такое поведение. Но и инсталляшка могла бы уж проверить разрядность файла и тупо его переписать. Эх, похоже DLL-hell всё ещё с нами в полный рост.
    • 0
      Да к примеру компоненты от Telerik 2015.Q2 не уживались с MS VS 2013 sp4 и IDE падала при запуске. А Telerik 2015.Q3 уже не крешат IDE.
      Иногда проблему помогает решить чтение Activity.xml
    • 0
      У меня только что 2015 update2 выдал такую же ошибку на свежей win10(полчаса назад поставленной).
      А перед этим поставился нормально.

  • +2
    Как бы мне пригодилась эта статья два дня назад! :) Проделал ровно весь тот же самый путь, заканчивая ProcessMonitor'ом и проклятиями в адрес собственной лени (видел решение с SO, но не проверил сразу, поможет или нет) и криворуких авторов инсталлятора, которые не могут починить это уже пол года. Но зато ещё раз убедился, что против русского программиста с инструментом ничто не устоит :) Репорты об этой баге почти всегда не содержат нужной диагностики (это заметно в обсуждениях на Connect): все останавливаются просто на том, что не ставится Team Explorer, только один товарищ, кажется, добрался до незагружающейся Settings.dll, а про неправильные редисты никто так и не написал.
  • 0
    Сюрприз — на сайте Microsoft версия правильная

    Версии идентичные, так что проблема где-то в установщике VS либо окружение вызывает баг при тихой установке.
    • 0
      Более того, как я выяснил — можно было даже для уже установленного студией redistributable в панели управления нажать repair и он восстановил бы 32-битную библиотеку.
  • 0
    Привет из 2016 года.
    Свежескачанная Visual Studio Community Edition.
    Абсолютно та же самая проблема и целый вечер битья головой об стену.
    Нашел ответ на SO в виде ссылки на эту статью.
  • 0
    Статья все еще актуальна. Cтояла Visual Studio 2015 Update 1, поставил Update 2. Словил аналогичную проблему, сперва слетел NuGet, потом студия перестала запускаться дальше Splash Screen-а, откатившись назад на Update 1 не ставился extension Connected Services. Помогла эта статья и установка из образа, вместо web installer.
  • 0
    8 мая, 4 утра. Тыкался пару часов и вышел на эту статью через SO. Тому кто в майкрософте тестированием занимается нужно глаз на жопу натянуть. И еще: кто-нибудь понимает почему установка идет ТАК ДОЛГО? Что там мать его происходит, она что считает биткоины? Это же просто копирование файлов по большому счету. Я очень огорчен.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка