Как определить, что вызывает повторный автозапуск установщика Windows?

  • Как я могу регистрировать только изменения, вызвавшие файл MSI, сделанный Installshield 2008, для переустановки через « саморемонт »?
  • В чем причина саморемонта?
  • Как отключить самообслуживание MSI с помощью Installshield 2008?

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

    ОБНОВЛЕНИЕ : существует более короткий, более «ориентированный на решение» ответ , возможно, сначала попробуйте его. Этот ответ фокусируется на «понимании саморемонта», а не на объяснении шагов, предпринимаемых для устранения проблемы. Возможно, вы захотите также прочитать первый раздел этого ответа.


    Неожиданные проблемы с самовосстановлением установщика 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 для самообучения. Эта статья заслуживает внимания.

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


    Основные причины саморемонта

    Подробности приведены ниже в разделе « Некоторые типичные сценарии саморемонтных проблем », но как быстрый, предзнавательный список – основными причинами являются:

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

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

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

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

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

    • Объявленный AD-пакет MSI не может быть установлен (может быть отменен, так как он слишком длительный для установки) и продолжает прослушивать людей. Это, строго говоря, не самовосстановление, а объявленная установка, которая прервана, но результат тот же: бесконечная переустановка
    • Устранение терминального сервера . Самообслуживание вообще отключается на терминальных серверах. Это обычно не вызывает проблем с самовосстановлением, но приложение устанавливается без необходимых файлов для каждого пользователя или ключей реестра, которые могут быть добавлены посредством доброкачественного использования самовосстановления (см. Ниже). Пользовательские файлы и ключи реестра пользователя просто отсутствуют и возникают проблемы.
    • UAC , отказ в проверке сертификата и другие проблемы, связанные с изменениями дизайна Windows . Для каждой версии функций безопасности Windows такие, как эти, добавляются и обычно в конечном итоге добавляют новые препятствия для надежного развертывания
    • Даже некоторые обновления Windows (обновления, обновления для системы безопасности, исправления и т. Д.) Могут кардинально изменить порядок обеспечения безопасности пакетов MSI и, следовательно, вызвать крайне проблемное поведение
      • Хотя это связано с созданием MSI, а не только с их конечным пользователем, Windows Update KB3004394, который обновляет способ проверки Windows для отозванных корневых сертификатов , разбивает старую версию сборки командной строки Installshield (для настроек, которые были с цифровой подписью). В настоящий момент проблема решена, но показывается, как Microsoft продолжает менять основные функции MSI
      • Аналогичным образом, после установки Microsoft update MS14-037 «Обновление безопасности для Internet Explorer версии 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

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

    введите описание изображения здесь

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

    У MSI-эксперта и MVP Стефана Крюгера есть статья о той же проблеме самовосстановления. И он критически обсуждает фактические записи журнала событий и то, что они означают. Пожалуйста, прочитайте о фактической процедуре отладки .


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

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

    1. Путь к компонентному ключу устанавливается в пустую папку, которую установщик Windows удаляет при самообслуживании (запускает бесконечный цикл удаления и последующего самовосстановления). Это решается путем добавления папки в таблицу CreateFolder вместо ( эквивалент Wix ). По моему опыту, это самый распространенный сценарий для нежелательного самообслуживания. Очень часто .
    2. Многие проблемы с саморемонтом на самом деле вызваны тем, что разработчики пытаются отлаживать свои приложения , заменяя файлы «на лету», удаляя файлы или переименовывая их. Или они могут использовать сценарии реестра очистки и / или пакетные скрипты для отмены регистрации и регистрации COM-файлов, COM-Interop, файлов GAC, ассоциаций файлов или других общих задач отладки и разработки разработчиков.

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

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

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

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

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

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

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

      • Хотя я никогда не отлаживал такие проблемы VB6 очень подробно, казалось бы, проблемы возникают из приложений, устанавливающих общие элементы управления , COM-файлы VB6 , шаблоны и файлы и библиотеки VBA, которые конфликтуют с существующими файлами и параметрами реестра и регистрациями на ящике, или какой-либо отдельный раздел реестра пользователя или файл пользовательского профиля, возможно, необходимо добавить один раз для каждого пользователя (позвольте самовосстановлению завершить один раз и посмотреть, не исчезла ли проблема). В частности, я слышал об этих таинственных проблемах самовосстановления при запуске AutoCAD (от Autodesk), Visual Basic 6 и нескольких других продуктов (часто с автоматизацией VBA, доступной в инструменте).
      • Некоторые приложения даже ошибочно устанавливают биты и fragmentы из среды выполнения VB6 самостоятельно, что приводит к «вырыванию» этих параметров при удалении этих приложений. Это может привести к срабатыванию самовосстановления, чтобы исправить теперь (частично?) Нарушение времени работы VB6. Существует несколько вариантов этой проблемы, и решение «поймать все», вероятно, является полной деинсталляцией и переустановкой среды выполнения VB6. Ниже приведено описание очень распространенной «конкретной» проблемы, связанной с несколькими ключами реестра COM . Это хорошо иллюстрирует, что происходит в этом сценарии.
      • Если при запуске VB6 , AutoCAD , Visual Studio или других продуктов вы испытываете неожиданный саморемонт, вы можете сначала попробовать обходной путь, чтобы предотвратить этот неожиданный самообслуживание в первую очередь (это не решает проблему, но может обойти его симптомы): почему программа установки Windows запускается каждый раз, когда я запускаю визуальный базовый 6
      • См. Мой комментарий к вопросу в этом разделе для одного из наиболее типичных самостоятельных ремонтов стиля VB6: Почему мое приложение запускает установщик другого приложения? (Элемент управления ActiveX зарегистрирован дважды из двух разных мест на диске).
      • На мой взгляд, « общее исправление », которое всегда должно работать – для проблем самовосстановления VB-COM, заключается в том, чтобы заставить продавца обновить свой проект, чтобы использовать последний официальный и правильно установленный и общий доступ к ActiveX-controllerу / OCX, и не полагаться на свою собственную версию, установленную избыточно и зарегистрированную в неправильном месте.
    8. Особым случаем ремонта или самообучения установщика Windows, который стоит упомянуть для полноты, была проблема с Microsoft Office несколько лет назад, когда был вызван саморемонт , и вас попросят вставить установочный носитель Microsoft Office (в в эти дни CD-ROM или DVD-диски – сегодня, возможно, большие диски). Насколько я помню, это связано с ошибочным вызовом встроенного стандартного действия установщика Windows « ResolveSource », который неожиданно (и излишне) вызвал приглашение для установочного носителя. Очень общий звонок поддержки в тот же день и упоминается здесь для полноты. Важно отметить, что эта проблема все еще может возникать всякий раз, когда MS Office устанавливается с любого съемного носителя (а не на лучший вариант сетевого ресурса ). Это происходит, когда MS Office обнаруживает, что ему необходимо установить дополнительные, необязательные (и обычно общие) компоненты продукта, которые не были установлены первоначально. Например, необычные проверки орфографии, различные шаблоны или конкретные и редко используемые инструменты. Эти компоненты можно установить для «установки при первом использовании» (рекламируемые функции – это правильный термин установщика Windows).

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

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

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

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

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