Ответ 1

Доступен альтернативный ответ

UPDATE: Существует более короткий, более "ориентированный на решение" ответ, возможно, попробуйте сначала. Этот ответ фокусируется на "понимании саморемонта", а не на объяснении шагов, предпринимаемых для устранения проблемы. Вы также можете прочитать первый раздел этого ответа.

Непредвиденные проблемы с самообслуживанием установщика Windows - быстрое исправление?

Эта "статья" стала большой и несколько нечитаемой. Вот недавно написанная преамбула - короткая обходная версия для исправления неожиданного самовосстановления (часто встречающаяся в VB6, Visual Studio, MS Office, MS Outlook, AutoCAD и т.д.)

• Если вы испытываете неожиданный самообслуживание, , первое, что вы можете попробовать, - это вручную создать ярлык на рабочем столе непосредственно в исполняемом приложении вы запускаете, когда возникает проблема. Это обходит самый распространенный триггер самовосстановления, рекламируемый ярлык. Если это работает, ваша проблема "решена" (или избегается). Вот краткое объяснение.
• Если проблема по-прежнему возникает или ваша проблема связана с загрузкой MS Office, надстройки MS Outlook или аналогичной (которую вы не можете запустить через ярлык), то у вас, скорее всего, есть конфликт регистрации COM в вашей системе, и исправление гораздо более активно. Простейший, чтобы попробовать отключить любые добавления, которые вам не нужны в диалоговом окне дополнительных приложений рассматриваемого приложения, и посмотреть, удастся ли это решить проблему.
• Если вы все еще видите проблемы, вам чаще всего нужно отлаживать подлинный конфликт регистрации COM (или конфликтующие ассоциации файлов /MIME или командные глаголы). Обычно это включает (по крайней мере) два конфликтующих приложения в вашей системе, которые "борются с ним", обновляя реестр при каждом запуске после запуска другого приложения (всегда запуск одного из приложений не приведет к самообучению - конфликт возникает, когда вы чередуетесь между приложениями). Также возможно, что проблемы с разрешением приводят к тому, что одно и то же приложение не может обновить систему, и оно постоянно пытается бесконечно выполнять самообслуживание. И есть дополнительные возможности, более подробная информация ниже
  • " реальное исправление" означает связаться с обоими поставщиками приложений и с запросом об устранении проблемы (так как для исправления часто требуется исправление обоих MSI поставщиков), но по моему опыту это редко бывает успешным. Попробуйте это, хотя, так как это способ помочь каждому с давним раздражением! Я лично предоставил установку с исправлениями для развертывания банка и был очень рад, что проблема решена в моем пакете.
  • Чтобы отлаживать себя, вам нужно получить инструмент для открытия кэшированных файлов MSI в системе, и вам нужно "взломать" базу данных - очень сложная задача , требующая навыков специалиста, вы бы рекомендуется обратиться за помощью к специалисту по установке, если проблема очень серьезная для вашей среды рабочего стола. Он может работать, но не ожидайте чудес.
  • Для получения более подробной информации о получении инструмента для просмотра и изменения файлов MSI см. раздел ниже Поиск триггера или виновника самообслуживания.

В остальной части статьи подробно описываются проблемы самовосстановления. Есть много других потенциальных причин самовосстановления, чем то, что описано в этом "коротком" разделе.

Общая проблема: отладка и самообслуживание разработчиков

Установщик Windows - это технология развертывания, его задача - установить указанные файлы и параметры реестра и сохранить их в указанных местах установки и убедиться, что они правильные версии - самовосстановление или отказоустойчивость - это механизм для этой цели. Его работа конфликтует с тем, что разработчики должны обмениваться файлами "на лету" для отладки, разработки и тестирования.

Соответственно, многие самообслуживание (отказоустойчивость) запускаются просто разработчиками, которые пытаются отлаживать их установленное приложение и файлы с возможностью "горячей" замены на лету. См. Раздел 2 в разделе "Некоторые типичные сценарии проблем самовосстановления" ниже для того, как справиться с этим. В других случаях в MSI имеются ошибки которые должны быть исправлены или ловушки системного администрирования, которые приводят к самовосстановлению - и иногда источник ошибок может быть трудно найти.

Я написал о проблеме саморемонта в ответе на serverfault.com. Немного разные слова, предназначенные для системных администраторов, и теперь, читая его, это может быть более доступное объяснение, чем этот длинный (предназначенный для разработчиков). В stackoverflow также есть еще один более короткий ответ: Почему установщик MSI реконфигурирует, если я удалю файл? (это, вероятно, самый короткий один и самый простой для понимания). И, наконец, я нашел очень хорошую статью о саморемонте Вадим Рапп: Как исправить Установщик Windows Installer для себя -Ремонт. Эта статья заслуживает внимания.

Самостоятельный ремонт не произойдет, если установщик Windows определит, что запущенный продукт правильно установлен. Когда саморемонт происходит, в системе необходимо что-то изменить для правильной работы приложения.

Основные причины самообучения

Детали представлены ниже в разделе "Некоторые типичные сценарии проблем самовосстановления", но как быстрый, предзнавательный список - основные причины:

1. Плохо упакованные корпоративные файлы MSI или недостатки дизайна MSI от поставщика (сам пакет MSI плохо разработан и неожиданно запускает самовосстановление по разным причинам)

• Чрезмерное или ошибочное использование файлов для пользователей или разделов реестра для каждого пользователя часто с ошибочными путями ключей, заданными в профиле пользователя (вместо HKCU). См. Раздел 5 ниже для получения дополнительной информации (и цветной иллюстрации такой ситуации).
• Помехи пакетов из ошибочной регистрации COM-сервера (особенно VB6 COM файлов или файлов и библиотек VBA из таких продуктов, как AutoCAD от Autodesk и аналогичных продуктов).
  • Два пакета MSI регистрируют один и тот же COM файл (ActiveX/OCX) из двух разных мест и "самовосстанавливающийся бой" при каждом запуске приложения, чтобы сохранить их версию правильно зарегистрированной.
  • Последнее приложение для запуска помещает реестр для себя, и оно продолжается до тех пор, пока другое приложение не будет запущено и не сделает то же самое. Как только вы чередуетесь между приложениями, проблема возникает. См. Раздел раздела 7 ниже для получения более подробной информации о самообслуживании VB/COM.
• Путь к компонентному ключу устанавливается в пустую папку, которую установщик Windows удаляет при самостоятельном ремонте (запускает бесконечный цикл удаления и последующего самовосстановления)
• Проблемы с блокировкой ACL (при входе в систему пользователь не может получить доступ к ключевому файлу, а триггеры Windows Installer повторно работают). Это также может быть вызвано изменениями ACL, выполненными извне, но часто выполняется самим MSI.
• Вот работающий сервер serverfault.com, описывающий общие недостатки дизайна MSI.

2. Файлы или ключи реестра удаляются из-за внешних причин, начиная от сценариев входа (logon) до стандартных функций ОС, вирусов, программного обеспечения безопасности и т.д.

• Временные файлы автоматически удаляются Windows после ошибочной установки в папку temp пакетом MSI
• Вмешательство из плохих протоколов запуска и запуска счастливых очистки и
• Антивирусные приложения блокировать или удалять файлы или ключи реестра, чтобы установщик Windows больше не мог их обнаружить или получить.
• Компьютерные вирусы изменение или удаление файлов и параметров реестра
• Overactive computer tinkerers и пользователи удаляют файлы и настройки, которые они не понимают.

3. Изменения дизайна Windows, недостатки или ограничения, которые приводят к ошибочному или проблемному развертыванию

• объявленный AD-пакет MSI не может быть установлен (может быть отменен, так как требуется слишком много времени для установки) и продолжает прослушивать людей. Это, строго говоря, не самовосстановление, а объявленная установка, которая прервана, но результат тот же: бесконечная переустановка
• Сервер терминаловосложнения. Самообслуживание вообще отключается на терминальных серверах. Это обычно не вызывает проблем с самовосстановлением, но приложение устанавливается без необходимых файлов для каждого пользователя или ключей реестра, которые могут быть добавлены посредством доброкачественного использования самовосстановления (см. Ниже). После этого пользовательские файлы и ключи реестра пользователя просто отсутствуют и возникают проблемы.
• UAC, отказ в проверке сертификата и другие проблемы, возникающие в результате изменений дизайна Windows. Для каждой версии функций безопасности Windows такие, как эти, добавляются и обычно в конечном итоге добавляют новые препятствия для надежного развертывания.
• Даже некоторые Обновления Windows (обновления, обновления для системы безопасности, исправления и т.д.) могут кардинально изменить порядок обеспечения безопасности пакетов MSI и, следовательно, вызвать крайне проблематичное поведение
  • Хотя это относится к созданию MSI, а не к их использованию конечным пользователем, Windows Update KB3004394, который обновляет способ проверки Windows отозванные корневые сертификаты, ломает устаревшую версию сборки командной строки Installshield (для настроек, которые были цифровой подписью). Во многом разрешенная проблема к настоящему времени, но иллюстрация того, как Microsoft продолжает менять основные функции MSI.
  • Аналогичным образом Installshield разбился для многих пользователей после установки обновления Microsoft MS14-037 "Обновление безопасности для версий 6, 7, 8, 9, 10 и 11" (KB2962872)
  • чрезвычайно проблематичное изменение в базовых функциях установщика Windows произошло после установки kb2918614 (Vista). Внезапные полномочия администратора потребовались для простой операции ремонта MSI. Это полностью устранило основное преимущество MSI: способность обычных пользователей запускать утвержденные установки с временными правами администратора. Были также обнаружены другие проблемы MSI после установки этого исправления. Появляется другое обновление для Windows, которое устраняет проблемы: kb3008627 (позже заменен на kb3072630)

Об автономном ремонте

Установщик Windows предназначен для установки ваших двоичных файлов приложений, файлов настроек и данных и их установки и обеспечения правильности их версий. Самообслуживание - это механизм для этой цели. Общая концепция называется отказоустойчивость - то есть сломанная установка запускает саморемонт до запуска приложения.

Устойчивость, или саморемонт, является встроенной первичной концепцией установщика Windows и не может быть отключена любым способом это безопасно. Обычно люди совершают самые невероятные вещи, например отключить весь механизм установщика Windows, чтобы остановить их саморемонт. Это, очевидно, никогда не будет сделано. Причина ремонта должна быть идентифицирована, и проблема решена вместо создания новых или взлома системы.

Каждый раз, когда вы запускаете рекламируемый ярлык (по существу специальный ярлык, указывающий на функцию установщика Windows и не напрямую в файл), установщик Windows проверит установку, проверив " путь к компонентам компонента" для вашего продукта. Если обнаружено несоответствие, для устранения неполной установки запускается ремонт. "Ключи основных компонентов" - это "ключевые файлы", указанные для компонентов внутри вашей MSI - для каждого компонента есть один. Саморемонт также может быть инициирован кем-то, создающим экземпляр COM-сервера (или попытки), кто-то активирует файл через расширение файла или MIME-регистрацию и несколько других способов. Вот всеобъемлющая статья от Symantec по теме "точки входа в саморемонт": Инициирование функций самообслуживания и рекламы с точкой входа.

Если файлы удаляются, перемещаются или просто перезаписываются (вручную пользователем или каким-то образом автоматически), может возникнуть самовосстановление (если параметр файла или реестра не установлен как автозапуск ключа, он не запускается).

Поиск триггера или виновника самообслуживания

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

• Щелкните правой кнопкой мыши "Мой компьютер"
• Нажмите "Управление"
• Нажмите "продолжить", если вы получите приглашение UAC
• Перейдите в раздел "Просмотр событий" и проверьте журналы Windows

В качестве альтернативы вы можете: Начать = > Выполнить... = > eventvwr.exe только для просмотра событий. Если вы не видите запуск в стартовом меню, нажмите WINKEY + R.

• Посмотрите в разделе Application журнала событий, и вы должны найти предупреждения из источника событий "MsiInstaller" с идентификаторами 1001 и 1004
• В образце, снятом выше , код продукта отображается внутри красной рамки
• Чтобы определить, для какого продукта предназначен код продукта, вы можете найти имя продукта с помощью процедуры, описанной здесь: Как можно Я нашел GUID продукта установленной установки MSI?
• Если вы действительно хотите углубиться и проверить фактический контент MSI файла, вы должны получить инструмент, способный просматривать файл MSI (, например Orca, Installshield, Advanced Installer или аналогичный). Затем вы откроете пакет, указанный в списке путей "LocalPackage", как показано на снимке экрана, найденном в ответе, связанном с предыдущей точкой маркера.
• Фактическая модификация системного кэшированного MSI файла и/или реестра для удаления рекламируемых точек входа, таких как (рекламируемые) ярлыки, регистрация COM, ассоциации файлов, ассоциации MIME или командные глаголы - это задание специалистов. Это очень сложная и не очень хорошая практика, но это единственное "последнее средство", о котором я знаю.
• Наконец, приложение может явно вызвать Windows Installer для запуска самообслуживания для общих компонентов - например, проверки орфографии. Я считаю, что несколько версий Microsoft Access сделали это, и это поведение не может быть изменено или проработано, насколько мне известно.

MSI-expert и MVP Stefan Krüger есть статья о том же вопрос самовосстановления. И он принципиально обсуждает фактические записи журнала событий и что они означают. Пожалуйста, прочитайте о текущей процедуре отладки.

Некоторые типичные сценарии проблем самовосстановления:

Это "подробное объяснение" нескольких сценариев проблем саморемонта, уже описанных в обзоре выше.

• Компонент ключевой путь установлен в пустую папку, которую установщик Windows удаляет при самообслуживании (запускает бесконечный цикл удаления и последующего самовосстановления). Это можно решить, добавив папку в таблицу CreateFolder вместо этого (эквивалент Wix). По моему опыту, это самый распространенный сценарий для нежелательного самообслуживания. Очень часто.

• Многие проблемы с самовосстановлением на самом деле вызваны тем, что разработчики пытаются отлаживать свои приложения, заменяя файлы "на лету", удаляя файлы или переименовывая их. Или они могут использовать cleanup скрипты реестра и/или пакетные скрипты, чтобы отменить регистрацию и регистрацию COM файлов, COM-Interop, файлов GAC, ассоциаций файлов или других общих отладочных разработок разработчиков задачи.

  • Эта горячая замена может запускать самообучение при запуске приложения через рекламируемый ярлык.

  • Верхний совет для разработчиков, борющийся с самообслуживанием во время отладки приложений не запустите приложение из рекламируемого ярлыка, но для запуска основного EXE непосредственно из проводника Windows или из созданного вручную ярлыка. Это обходит наиболее распространенную " точку авторемонта "- рекламируемый ярлык. Самовосстановление может по-прежнему возникать из-за нарушенных данных COM, рекламируемых ассоциаций файлов и нескольких других особых случаев (прочитать эту статью Symantec для информации о точке входа).

• Другие приложения или, скорее, другие пакеты MSI могут нарушить установку и привести к самовосстановлению, вмешавшись в данные реестра - обычно настройки COM, но также и с другими настроек и файлов. Это могут быть некоторые из самых сложных дел для решения, поскольку приложения в основном борются с ним, а последний из них будет обновлять реестр каждый раз. Как правило, файлы MSI должны быть переработаны для приложений, работающих на одном компьютере. Или, как и порядок дня, все приложение может быть виртуализировано (например: виртуальные пакеты Microsoft App-V) и запустить его собственная песочница, которая, как представляется, все больше и больше делается в компаниях в эти дни. Этот сценарий ошибок часто встречается с набором плохо переупакованных приложений в корпоративной среде. COM-фрагменты из разных пакетов перезаписывают путь к диску COM-сервера из другого пакета, и самозарядное сражение происходит при каждом запуске приложения через рекламируемый ярлык. Одно и то же имя файла с разными версиями файлов также может быть зарегистрировано из разных мест файлов и совместно использовать некоторые параметры реестра, которые мешают. Насколько я помню, как минимум 7 переменных или параметров в файловой системе и в реестре должны быть синхронизированы, чтобы сервер COM был правильно запущен. См. Раздел раздела 7 ниже для более специализированного описания COM-помех в контексте приложений VB6 и VBA.

• Путь компонентного ключа указывает на временный файл, который был удален приложением, или он будет удален системой в конечном итоге через какой-то механизм очистки (также может быть инструмент очистки, такой как ccleaner). Это характерно для файлов в самой папке temp. Это решается, не устанавливая временный файл, или помещая файл в другое место и делая его постоянным. Я видел эту ошибку чаще всего в мире переупаковки корпоративных приложений, где некорректная очистка захваченного изображения приводит к установке временного файла, который вообще не должен был быть включен в пакет. Часто они могут быть временными файлами, ожидающими перезагрузки, чтобы быть установленными в их предполагаемое, возможно защищенное место, и перезагрузка никогда не выполнялась - общая ошибка упаковки приложения. В меньшей степени я видел его в автоматически созданных пакетах, выходящих из автоматизированных систем сборки.

• Проблемы с разрешением: если файл ключа для компонента установлен в место, недоступное для пользователя, который вызывает приложение. Установщик Windows не может "видеть" установленный путь к файлу/ключу или не может добавить файл в папку. Эти проблемы могут быть более экзотическими для отладки, и часто это может произойти не так часто. Существует несколько вариантов этой проблемы:

  • Примером этого является установление файла на путь % USERPROFILE%, а затем забудьте указать путь к ключу реестра HKCU и вместо этого укажите путь к папке% USERPROFILE%/файл. Обычно это дает недоступный жестко закодированный путь ключа, который зависит от пользователя: C:\Documents and settings\user1\Desktop. Этот путь не будет найден для входа в систему другого пользователя, а самовосстановление выполняется по кругу. Вот цветные иллюстрации.
  • Еще один пример - это путь к папкам, которые не могут быть записаны для учетной записи системы. Это может показаться экзотическим, но может возникнуть из-за ошибочной модификации MSI системных записей ACL или от странной настройки безопасности системного администратора или любого другого нестандартного дескриптора ACL/Security.

• Другой класс проблем с саморемонтом возникает в отношении терминальных серверов и Citrix. Целую службу установщика Windows можно заблокировать, поэтому любой саморемонт, вызванный для добавления на данные пользователя, может потерпеть неудачу, и, следовательно, самовосстановление может потерпеть неудачу или, скорее всего, не будет работать вообще. Это является достаточным основанием для того, чтобы не полагаться на саморемонт как способ добавления пользовательских данных, как это делают некоторые файлы MSI, и такие конструкции должны быть заменены развертыванием приложений пользовательскими файлами, скопированными из локальных машин или менее эффективными a href= "https://stackoverflow.com/info/1423687/updating-every-profiles-registry-on-windows-server-2003/1424819" > ActiveSetup из Microsoft, которая запускается один раз для каждого пользователя.

• Приложения VB6и приложения VBA, которые сильно основаны на COM с огромным потенциалом для COM-помех (параметры COM, переписывающие друг друга и становящиеся противоречивыми), были известны чтобы вызвать несколько таинственных проблем саморемонта, большинство из которых не были должным образом объяснены. Это также может произойти при запуске Visual Basic 6 (VB6) или Visual Studio (и многих других приложений). Общим знаменателем является то, что некоторая ошибка в текущем состоянии установки вызвала самовосстановление, и вы можете отслеживать продукт виновника и компонент, выполнив шаги, описанные в разделе выше, называемом Поиск триггер или виновник саморемонта. Обязательно сообщайте о своих результатах здесь (я больше никогда не использую VB6 или VBA - ваши подробные данные могут помочь другим с давней досадой).

  • Хотя я никогда не отлаживал такие проблемы VB6 очень подробно, казалось бы, проблемы возникают из приложений, которые устанавливают общие элементы управления, COM файлы VB6, шаблоны и файлов и библиотек VBA, которые конфликтуют с существующими файлами и параметрами реестра и регистрациями в окне, или может потребоваться добавить один раз для каждого раздела реестра пользователя или файла пользовательского файла один раз для пользователя ( позвольте самовосстановлению завершить один раз и посмотреть, не исчезла ли проблема). В частности, я слышал об этих таинственных проблемах самовосстановления при запуске AutoCAD (от Autodesk), Visual Basic 6 и нескольких других продуктов ( часто с автоматизацией VBA, доступной в инструменте).
  • Некоторые приложения даже ошибочно устанавливают биты и фрагменты из среды выполнения VB6 самостоятельно, вызывая их "разрывание" при удалении этих приложений. Это может привести к срабатыванию самовосстановления, чтобы исправить теперь (частично?) Нарушение времени работы VB6. Существует несколько вариантов этой проблемы, и решение "поймать все", вероятно, является полной деинсталляцией и переустановкой среды выполнения VB6. Вот описание очень распространенной "конкретной" проблемы, связанной с несколькими разделами реестра COM. Это хорошо иллюстрирует, что происходит в этом сценарии.
  • Если при запуске VB6, AutoCAD, Visual Studio или других продуктах произошел неожиданный самовосстановление, вы можете сначала попробовать обходной путь, чтобы предотвратить этот неожиданный самообслуживание в первую очередь (это не решает проблему, но может обойти его симптомы): почему Windows Installer запускается каждый раз, когда я запускаю визуальный базовый 6
  • Посмотрите мой комментарий к вопросу в этом разделе для одного из наиболее типичных самообслуживаний VB6: Почему мое приложение запускает установщик другого приложения? (элемент управления ActiveX дважды зарегистрирован из двух разных мест на диске).
  • По-моему, " общее исправление", которое должно всегда работать - для проблем самовосстановления VB-COM, заключается в том, чтобы заставить продавца обновить свой проект, чтобы использовать последние официальные и правильно установленный и доступный элемент управления ActiveX/OCX, а также не полагаться на собственную версию, установленную избыточно и зарегистрированную в неправильном месте.

• Частным случаем ремонта установщика Windows или саморемонтом, который стоит упомянуть для полноты, была проблема с Microsoft Office несколько лет назад, когда был запущен самообслуживание, и вам будет предложено вставить установочный носитель Microsoft Office (в те дни CD-ROM или DVD-диски - сегодня, возможно, большие диски). Насколько я помню, это связано с ошибочным призывом к встроенному стандарту Windows Installer " ResolveSource", который неожиданно (и без необходимости) вызвал приглашение для установочного носителя. A очень распространенный вызов поддержки в тот же день и упомянут здесь для полноты. Важно отметить, что эта проблема все еще может возникать, когда MS Office устанавливается с любого сменного носителя (вместо лучшего варианта сетевого ресурса . > ). Это происходит, когда MS Office обнаруживает, что ему необходимо установить дополнительные, необязательные (и обычно общие) компоненты продукта, которые не были установлены первоначально. Например, необычные проверки орфографии, различные шаблоны или конкретные и редко используемые инструменты. Эти компоненты можно установить для "установки при первом использовании" (рекламируемые функции - это правильный термин установщика Windows).

• Существует много других возможных сценариев. Чтобы упомянуть несколько:

  • a плохой вход script может удалить вещи в системе и запустить самообслуживание
  • рекламируемый пакет AD может выйти из строя, чтобы установить и продолжать прослушивать людей
  • два приложения могут запускать сражаться за те же ассоциации файлов
  • компьютер tinkerers, и хакеры могут вручную удалять данные, которые запускают самообслуживание.
  • антивирус может помещать в карантин файлы и настройки реестра, которые запускают восстановление
  • вирус может изменять или удалять вещи и запускать самообслуживание
  • инструмент очистки диска и реестра, например ccleaner, может удалять файлы и запускать самообслуживание
  • и, без сомнения, множество других сценариев...

Доброкачественное использование для саморемонта

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

• Саморемонт иногда используется для добавления данных для каждого пользователя в HKCU и профиля пользователя. Этот дизайн в основном работает, но ухудшается для каждой версии Windows, поскольку новые возможности препятствуют развертыванию. Во-первых, саморемонт обычно вообще не работает на серверах терминалов, что делает установку неполной. Хотя это и не относится к этой дискуссии, лучше иметь копии файлов приложения для каждого пользователя. Другая проблема - UAC. Другие проблемы появляются с каждой новой версией Windows и даже с некоторыми обновлениями Windows, как описано выше (перенаправления виртуальных папок, приглашений по сертификатам, ранее несуществующих ограничений пути пути и т.д.).
• Если для настройки пользовательских данных требуется самостоятельный ремонт, может потребоваться так много времени, чтобы пользователь прервал его и продолжал делать это. Это приводит к тому, что самовосстановление появляется снова, пока не будет разрешено его завершение. Общий вызов службы поддержки.
• Также возможно установить продукт с рекламируемые функции ", которые предназначены для установки" по требованию ", вызванный во время использования приложения. Немногие приложения используют это, но когда он используется, может выполняться длительный" самовосстановительный стиль", который может выполняться - вытаскивание необходимых файлов и настроек. Если этот процесс отменен, установка функции отменяется, и ее можно запустить снова. Эта установка может быть медленной для нескольких причин:
  • Если установщик использовал большие сжатые CAB файлы, которые были сначала загружены, а затем извлечен локально на медленном диске , где антивирус начинает сканирование всей кабины, а затем каждый извлеченный файл может занять много времени.
  • Операция также может быть медленной, если сетевое соединение беспроводное, и есть множество небольших файлов для загрузки (высокая латентность), и снова антивирус может замедлить работу.
  • Если вы установили со съемных носителей, вы можете получить приглашения вставить исходный носитель, чтобы разрешить копирование файлов. Очень распространенный вызов поддержки, если съемный носитель используется в офисной среде (не должно быть - используйте admin install на сетевом ресурсе)
  • Etc...