Управление помощником по совместимости программ Windows 7 (PCA)

Впервые опубликовано в MSDN 22 ноября 2011 г.

Я хотел задокументировать немного подробностей об управлении программой Помощник по совместимости, небольшая технология, которую мы добавили для Windows Vista и с тех пор улучшали — я подумал, что, вероятно, пришло время выпустить обновление для Windows 7. Причиной этого была серия разговоров, в которых участвовало несколько человек. рекомендовали хорошо управляемому предприятию полностью отключить эту функцию. Это рекомендация, с которой я в целом не согласен (хотя, безусловно, могут быть очень специализированные сценарии, в которых это хорошая рекомендация). Скорее, я предпочитаю настраивать его, когда есть проблема. По этой причине я также хотел привлечь внимание к тому факту, что существует совершенно отдельная область групповой политики (по причинам, которые я полностью не могу объяснить), которая предоставляет отдельные ручки для многих сценариев PCA, реализованных в Windows 7. Если вы Если у вас проблемы с определенным сценарием, то лучше отключить этот конкретный сценарий, чем выбросить ребенка с водой в ванне. Имея это в виду, ниже, когда я опишу различные сценарии групповой политики, я также включу переключатель групповой политики этого сценария, если он есть, а также причины, по которым вы можете отключить обнаружение для этого сценария. Но прежде чем мы начнем, Коротко о СПС. Идея состоит в том, чтобы попытаться добраться до «длинного хвоста» экосистемы приложений Windows. Имейте в виду, несмотря на то, что у нас фантастическая команда тестировщиков и множество ручных и автоматических тестов, мы все еще тестируем программное обеспечение порядка 10 3 . Бета-тестирование помогает больше, но бета-тестеры не намного больше довольны сбоями приложения, чем любой другой пользователь. Итак, мы стремимся автоматизировать часть работы, выполняемой командой разработчиков приложений. Что мы ищем сегодня и как это можно настроить?

В этом сценарии мы проверяем, определяется ли вы как установщик, используя обнаружение установщика UAC. Если это так, мы сравним ключ реестра Uninstall до и после запуска установщика. Если ничего нового не появляется, мы предполагаем, что вы, возможно, потерпели неудачу, и отображаем приглашение PCA. Если вы принимаете исправление, мы применяем слой WINXPSP2. Обнаружение сбоев при установке приложений отключает эту проверку, хотя обычно она не представляет опасности. Раньше у нас было много проблем с этим, поскольку мы все равно запускали его, даже если у вас был манифест UAC, указывающий какInvoker (довольно хороший признак, что вы не установщик), и вы пытались установить уровень VISTARTM, но на основе ваших отзывов Я успешно провел кампанию по удалению этого в Центре обновления Windows за февраль 2010 г. Это не влияет на обычных пользователей, которые в любом случае не могут устанавливать программное обеспечение. В этом сценарии мы просто отслеживаем событие ETW для STATUS_ELEVATION_REQUIRED (0xC000042C). Мы почти всегда правы в этом вопросе, поскольку исправление всегда заключается в применении прокладки ELEVATECREATEPROCESS, поэтому мы просто идем дальше и делаем это.. (Я понятия не имею, почему мы все еще пытаемся показать вам диалоговое окно. Очевидно, кто-то не читал записку.) Обнаружение приложений, которые не могут запускать установщики под UAC, отключает эту проверку, хотя я не могу придумать причину, по которой вы буду хотеть. Да, это приводит к запросу UAC, но ваша альтернатива — ошибка — по крайней мере, подсказка сообщает вам, что происходит. Этот сценарий просто реализует проверку ole32 по жесткому списку устаревших библиотек DLL. Когда мы находим его, мы даем пользователю возможность проверить решение в Интернете. Обнаружение сбоев приложений, вызванных устаревшими COM-объектами, отключает эту проверку, и я как бы нахожусь на заборе этого со стандартными пользователями. Да, он указывает им на решение, которое позволяет им потенциально найти установщик, который они не могут использовать, но, по крайней мере, ваш звонок в службу поддержки предлагает решение, а не просто неотлаженный сбой. Я бы подумал о том, чтобы оставить этот вариант включенным, я просто не слышал никаких сообщений о том, что он проблематичен, и он может решить некоторые проблемы, которые обычно требуют от ботаников времени, проводящего с зависимым.exe. В этом сценарии реализована простая проверка (в ntdll) устаревших библиотек DLL, что опять же противоречит жестко заданному списку. Еще раз, мы здесь довольно точны, и решение состоит в том, чтобы дать вам веб-ссылку, которая может помочь вам в отладке. Обнаружение сбоев приложений, вызванных устаревшими библиотеками DLL Windows или COM-объектами, отключает эту проверку, и снова я бы подумал о том, чтобы оставить ее включенной, если вы не столкнетесь с конкретной проблемой с ней. Опять же, я не слышал о таком сценарии, но это не значит, что его не существует. Этот сценарий ищет приложения, которые не обнаружены как настройки при обнаружении настройки UAC, но которые пытаются создать новую папку в Program Files (которые мы обнаруживаем с помощью событий виртуализации UAC, поэтому виртуализация UAC должна быть включенным для удовлетворения этого сценария). Еще в Windows Vista мы также требовали, чтобы вы попытались перетащить dll или exe в созданную вами папку, но в Windows 7 это уже не так. Если мы обнаружим это, мы дадим пользователю возможность применить оба VISTASETUP. и RUNASADMIN в приложение. Обнаружение установщиков приложений, которые необходимо запускать от имени администратора, отключает эту проверку, что может потребоваться для обычных пользователей. Если пользователь выберет неправильный вариант в качестве стандартного пользователя, он лишится возможности снова запустить приложение, что было бы неоптимально для ложных срабатываний. Поскольку здесь нет реальной выгоды и потенциального недостатка, это единственный сценарий, который я рекомендую отключать чаще всего. В этом сценарии даже нет эвристики. По сути, если вы являетесь апплетом панели управления и у вас нет манифеста, мы каждый раз спрашиваем: «Эй, как это прошло?» Если вы говорите, что все прошло плохо, мы применяем RUNASADMIN. В этом сценарии нет групповой политики, контролирующей его. Во времена Vista я видел это время от времени, но я не видел ни одного уже несколько лет.. Когда я находил их в организации, я обычно добавлял запись в базу данных прокладок, которая делает правильный выбор для пользователя. Этот сценарий в значительной степени противоположен сбоям установки, хотя он имеет более надежную точку запуска (выполнение панели управления добавлением/удалением, а не эвристика установки), не обнаруживающая изменений в разделе реестра Uninstall. Если вы это сделаете, мы применим уровень VISTARTM (если у вас есть манифест UAC) или уровень WINXPSP2 (если у вас его нет). В этом сценарии также нет групповой политики, управляющей им, но, по моему опыту, он мягкий и безопасный оставить включенным. Поскольку мы не разрешаем вам загружать неподписанные драйверы в 64-битной Windows, но некоторые люди все равно пытаются скрыть их, вручную переворачивая разделы реестра, мы отслеживаем изменения в разделе реестра и отключаем их, если они добавляются сюда. Уведомление о заблокированных драйверах отключает эту проверку, но, если вы не разработчик драйверов, нет смысла отключать ее. На самом деле это довольно сложный сценарий. Если вы запускаете сценарий сбоя установщика, и пользователь решил перевести вас в режим совместимости, мы отмечаем ярлыки, созданные установщиком. Затем, когда вы запускаете один из этих ярлыков, после выхода мы спрашиваем, работает ли приложение для вас, и даем вам возможность запустить средство устранения неполадок совместимости программ. Причина здесь в том, что если установщику требуется VISTARTM или WINXPSP2 для установки, то может быть и само приложение. В этом сценарии нет групповой политики, но отключение сценария «Ошибка установщика» повлечет за собой отключение и этой проверки. Это наш самый занудный сценарий. Мы сделали шанс в подсистеме работы с окнами, которая изменила способ обработки исключений в функциях обратного вызова. Когда в пользовательском режиме запускается исключение, в более старых версиях Windows возникает проблема, выходящая из пользовательского режима -> режима ядра -> границы пользовательского режима. Нативное 64-битное приложение просто не могло распространить это исключение обратно, если оно не было обработано до выполнения этого перехода. Итак, если ваш поток создает окно, и это окно вызывает исключение, вы не можете обработать это в коде, который создал окно и получил исключение. Итак, у нас был выбор: мы могли либо вывести приложение из строя при возникновении исключения, либо просто проглотить его и надеяться на лучшее. Из соображений совместимости приложений мы проглатываем это и надеемся на лучшее. Мы изменили это для Windows 7, так как просто проглатывание исключений на самом деле не очень хорошая идея с точки зрения отладки или качества приложения и позволяет исключениям проходить для 64-битных систем. процессы на x64. Итак, если приложение раньше генерировало исключение, но по пути ему приходилось переходить в режим ядра, мы просто проглатывали его раньше. Теперь мы передаем его обратно в стек. Я уверен, что вы можете видеть, к чему это идет: приложения, которые должны были давать сбой в более ранних версиях ОС, в соответствии с их собственным кодом, получали карту бесплатного выхода из тюрьмы и не падали, потому что они случилось пройти через режим ядра. Теперь у них больше нет этой карты, и если они не обработают исключение, приложение выйдет из строя. Этот сценарий определяет, что исключение прошло обратный вызов пользователя (ntdll! KiUserCallbackDispatcherContinue), и если это исключение приведет к сбою приложения, потому что оно не было обработано, мы возвращаемся к предыдущему поведению, применяя DISABLEUSERCALLBACKEXCEPTION.

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

Вы видите здесь тенденцию? Ранние сценарии PCA, которые существовали еще во времена Vista, представляют собой широкую эвристику, в первую очередь ориентированную на серьезное препятствие UAC и работу от имени стандартного пользователя. То, что мы добавили для Windows 7, было гораздо более целенаправленным, более точным, и вы действительно хотели бы работать в фоновом режиме, исправляя ошибки в уголках приложений, которые вы еще не нашли. По мере того, как в будущем их будет больше, вы хотите убедиться, что вы выбираете, поэтому я всегда рекомендую людям оставить эту функцию включенной и, самое большее, отключать проблемные сценарии, если они действительно становятся проблемными.

Оцените статью
Botgadget.ru
Добавить комментарий