Bug 14053

Summary: Установка 1С83 зависает после вычисления доступного места
Product: [Сторонние программы (Other programs)] 1С:Предприятие 8 Reporter: Vitaly Lipatov <lav>
Component: ОбщаяAssignee: BUGS@Etersoft <bugs>
Status: NEW --- QA Contact:
Severity: minor    
Priority: P4    
Version: 8.3   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Whiteboard:
Заявки RT: Связано с: 14024
Дата напоминания:

Description Vitaly Lipatov 2019-07-08 14:11:08 MSK 
Версия 1С 8.3.12 и выше. Особенность данной сборки в том что в комплекте идёт установка vcrun2015, пропустить которую нельзя. Проблема проявляется при установке в wine.

После запуска setup.exe и установки vcrun2015 появляется окно установки 1С. И после этапа вычисления доступного места установка зависает.

Основная разница возникает при выполнении MSI custom action с именем "checkOSVersion": установщик 1С там проверяет две переменные окружения "VersionNT" и "ServicePackLevel", значения которых выглядят вполне разумно, после проверки которых для Windows 7 сразу создается wbemprox запрос, а для Windows 8.1 MSI custom action просто завершает работу.

Создана тестовая программа, которая создает новый объект MSIHANDLE,
устанавливает для него свойства "VersionNT"="601" и "ServicePackLevel"="1",
загружает сохраненную DLL, содержащую MSI custom action, получает из нее
адрес процедуры "checkOSVersion" и вызывает ее. Под Windows этот вызов
виснет наглухо, судя по всему в цикле вызывая IEnumWbemClassObject_Next(),
полностью аналогично тому, что происходит в Wine.

Проверка работы этой тестовой программы под Wine подтвердила,
что вызов "checkOSVersion" ведет к вызову
в бесконечном цикле IEnumWbemClassObject_Next().

Это означает, что создатели установщика 1С действительно просто не тестировали
код процедуры "checkOSVersion", проверяющего наличие установленного KB2999226
(и возможно просто отключили его выполнение под Windows 8.1+).
Comment 1 Vitaly Lipatov 2019-07-09 13:37:19 MSK 
CoSetProxyBlanket() - это ключевой API, позволяющий
выполнять запросы WMI из MSI custom action. Согласно MSDN
https://docs.microsoft.com/en-us/windows/win32/wmisdk/setting-the-security-levels-on-a-wmi-connection
"After you retrieve a pointer to an IWbemServices proxy, you must set
the security on the proxy to access WMI through the proxy. You must
set the security because the IWbemServices proxy grants access to an
out-of-process object."
Но создатели установщика 1С просто забыли добавить вызов
CoSetProxyBlanket(), если бы они это сделали, то установщик 1С начал бы
наглухо виснуть, вызывая в цикле ::Next(), так как вместо WBEM_E_ACCESS_DENIED
он начал бы возвращать WBEM_S_FALSE.
Comment 2 Vitaly Lipatov 2019-07-10 16:32:00 MSK 
Суть проблемы можно описать примерно так:

MSI custom action "checkOSVersion" выполняет WMI запрос
"SELECT * FROM Win32_QuickFixEngineering WHERE HotFixID=\"KB2999226\""
и после этого в цикле вызывает hr = IEnumWbemClassObject::Next(). Условием
выхода из цикла видимо является конструкция вида FAILED(hr), однако ::Next()
возвращает WBEM_S_FALSE при завершении перечисления элементов, возвращенных
WMI запросом, и FAILED() не работает для этого кода возврата, так как он
проверят старший бит (0x80000000), а WBEM_S_FALSE = 1. В Windows данная
конструкция работает только потому, что ::Next() возвращает код ошибки
WBEM_E_ACCESS_DENIED (0x80041003), так как для того, чтобы WMI запрос
работал из MSI custom action необходимо вызвать CoSetProxyBlanket() после
вызова IWbemLocator::ConnectServer() и получения адреса прокси, чего MSI
custom action "checkOSVersion" не делает. Как результат проверка на то,
установлено ли исправление для KB2999226 просто не работает.