Версия 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+).
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.
Суть проблемы можно описать примерно так: 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 просто не работает.
