Средство проверки приложений— часто задаваемые вопросы (часто задаваемые вопросы)

Статья
10/23/2024

Общие вопросы

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

Что такое средство проверки приложений?

Средство проверки приложений — это средство проверки среды выполнения, используемое для поиска ошибок в приложениях Microsoft Windows. Так как это средство среды выполнения, код приложения необходимо выполнить для проверки. Поэтому хорошее покрытие теста является важным.

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

Разделы справки удалить средство проверки приложений?

Чтобы удалить средство проверки приложений, откройте панель управления, нажав кнопку "Пуск", выберите "Добавить или удалить программы", а затем удалите программу, нажмите кнопку "Проверка приложений" и нажмите кнопку "Удалить".

Разделы справки запустить средство проверки приложений?

После установки средства проверки приложений его можно запустить, получив доступ к нему в списке программ ИЛИ введя Appverif.exe в командной строке. Для этого перейдите в командную строку или поле "Запуск" меню "Запуск". Введите appverif.exe и нажмите клавишу ВВОД. Откроется средство проверки приложений.

Двоичный файл Appverifer.exe установлен в системном каталоге и используется для настройки средства.

Где хранятся журналы?

Журналы хранятся в %USERPROFILE%\AppVerifierLogs

Что делать, если при использовании средства проверки приложений возникают проблемы?

Убедитесь, что вы используете последний выпуск. Попробуйте использовать одно и то же приложение на другом компьютере или даже версии Windows.

Проверяет ли проверятель приложений управляемый код?

AppVerifier заботится об интерфейсах между операционной системой и приложением. В результате, если управляемый код не выполняет взаимодействие с собственными API, которые связаны с кучами, дескрипторами, критически важным разделом и т. д. тестовые случаи не будут предоставлять вам никакого взаимодействия с проверенными интерфейсами.

Мы рекомендуем использовать помощники по управляемой отладке для проверки управляемого кода. Дополнительные сведения см. в статье об отладке управляемого кода с помощью отладчика Windows.

Поддерживается ли ARM64EC?

Средство проверки приложений не поддерживает ARM64EC.

Вопросы отладчика

Ниже приведен список вопросов, полученных в отношении отладчика.

Почему я получил сообщение об ошибке, сообщая мне, что мне нужен отладчик?

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

Разделы справки запустить приложение под отладчиком?

См. разделы по установке и настройке отладчика. Начало работы с отладкой Windows

Разделы справки расширение стека тестов без каких-либо других инструментирования?

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

Например, вызов CreateFileA будет вызовом appvocre! NS_SecurityChecks::CreateFileA, которые могут вызывать appvcore! NS_FillePaths::CreateFileA, которые могут вызывать ядро32! CreateFileA, который может вызвать средство проверки! AVrfpNtCreateFile, который будет вызывать ntdll! NtCreateFile. Вы можете увидеть, что инструментирование добавило еще 3 вызова функций с накоплением, каждый из них может использовать больше стека.

В приведенном ниже случае LH-verifier.dll имеет значение "thunking" для каждой библиотеки DllMain, а путь кучи инструментированного кучи будет добавлять больше использования стека. Так как внедренный поток от отладчика не использует значения по умолчанию IMAGE_NT_HEADERS, изначально зафиксированный стек не будет достаточно для завершения состояния APC потока (поток в состоянии APC выполнял код инициализации).

Если вы хотите использовать Stack-Ckecs, вероятно, единственный другой уровень проверки, который следует использовать, если FirstChanceAccessViolation.

При использовании расширения !avrf я получаю "Средство проверки приложений не включено для этого процесса..."

Получена полная ошибка: Application verifier is not enabled for this process. Use appverif.exe tool to enable it.

Возможно, у вас есть только уровни проверки схима и /или куча в режиме pure. Это некоторые из возможных причин.

Вопросы о сценарии тестирования

Ниже приведен список вопросов, полученных в различных сценариях тестирования.

Как включить средство проверки приложений в службе, но не другие?

Создайте копию svchost.exe в каталоге System32 и вызовите копию Mysvchost.exe.

С помощью regedit откройте HKLM\System\CurrentControlSet\Services\MyService.

Измените значение ImagePath, которое будет иметь значение "%SystemRoot%\system32\svchost.exe -k myservice" и измените svchost.exe на "Mysvchost.exe".

Добавьте "Mysvchost.exe" в список AppVerifier и проверьте необходимые тесты.

Перезапуск.

Разделы справки запустить средство проверки приложений в 64-разрядном приложении, запущенном из 32-разрядного приложения, работающего в WOW64?

Простая версия: золотое правило для включения параметров проверяющего элемента в данном приложении — это соответствие битового значения средства и целевого процесса. То есть используйте 32-разрядную appverif.exe для 32-разрядного приложения (как работающего в WoW64), так и используйте 64-разрядную AppVerif.exe для собственного 64-разрядного целевого объекта.

Длинная версия: параметры средства проверки приложений являются правильным объединением параметров "core" и "shim".

Основные параметры. Основные параметры хранятся в разделе "Параметры выполнения файла образа".

Значение "Отладчик" считывается из запуска приложения. Таким образом, если требуется 32-разрядная devenv.exe запуска 64-разрядной my.exe и его запуск в отладчике, необходимо использовать 32-разрядный раздел реестра в разделе WoW6432Node. Другие значения для 32-разрядного процесса считываются из обоих мест, как собственный IFEO, так и WoW6432Node.

Причина заключается в следующем: 32-разрядный процесс, выполняющийся в WoW, является 64-разрядным процессом, выполняющим цикл эмуляции Wow64. Таким образом, каждый 32-разрядный процесс сначала является 64-разрядным процессом, а затем 32-разрядным процессом. 64-разрядная версия IFEO включает средство проверки в коде Wow64cpu.dll, а 32-разрядная ВЕРСИЯ IFEO включает средство проверки в 32-разрядном коде.

С точки зрения конечного пользователя verifier.dll загружается дважды (один раз в 64-разрядном мире, один раз в 32-разрядном мире). Так как большинство людей не заботятся о проверке wow64cpu.dll, наиболее приемлемое поведение для 32-разрядных процессов заключается только в проверке 32-разрядной части. Именно поэтому применяется золотое правило "всегда соответствовать бит-ness".

Разделы справки отладка службы, которая выполняется в неинтерактивной станции окон

Чтобы выполнить отладку службы, работающей в неинтерактивной станции окон, выполните следующие действия (применяется только при использовании ntsd/windbg):

Добавьте раздел в реестр в разделе HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options. Имя этого ключа должно быть именем процесса (service.exe).

Создайте значение REG_SZ с именем Отладчик и задайте для этого значения путь, в котором находится отладчик. Он должен содержать полный путь, а не только имя отладчика. Команда должна включать параметр –server и определенный порт или диапазон портов, в который должен прослушивать отладчик. Примером является c:\debuggers\ntsd.exe –server tcp:port=5500:5600 –g –G.

Подключитесь к серверу отладчика, запустив отладчик с параметром –remote. Пример: windbg.exe –remote tcp:=localhost,port=55xxx, где "xx" — это некоторое число от 00 до 99, если вы использовали диапазон на сервере.

Выполняет ли AppVerifier обнаружение утечки? В Windows 7 и более поздней версии есть параметр проверки утечки, который будет обнаруживать, когда процесс утечки памяти. В более ранних операционных системах AppVerifier не тестирует приложение для обнаружения утечки, но ищет другие проблемы с памятью.

Какие тесты рекомендуется использовать для проблем безопасности?

Кучи
Дескрипторы
Блокировки
Стеки (только для служб и важных процессов, которые могут отложить компьютер)

Имейте в виду, что УстаревшиеAPICalls просто спливают предупреждение для каждого вызова, который он видит в API, который указан как устаревший или устаревший в MSDN. Если приложение важно переключиться на новые API, следует принять решение по конкретному случаю. Некоторые ИЗ API опасны, и некоторые из них просто были заменены более новым API с дополнительными параметрами. Дополнительные сведения см. в разделе "Опасные API", посвященном написанию защищенного кода.

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

Тестирование конкретных вопросов

Ниже приведен список вопросов о тестировании. Щелкните вопрос, чтобы просмотреть ответ:

Важны ли утечки критических разделов?

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

Если ваш процесс должен оставаться в живых долго, то эти утечки могут укусить вас. Так как исправления очень просты в 99% случаев (разработчик просто забыл вызвать RtlDeleteCriticalSection), вы должны обратиться к ним.

Можем ли мы программно работать с переполнением стека?

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

Тест LoaderLock дает ошибку при вызове DestroyWindow. Почему я не могу вызвать DestroyWindow в DllMain? Вы не контролируете, какой поток будет отсоединяться. Если это не тот же поток, который создал окно, невозможно уничтожить окно. Таким образом, вы утечете окно и при следующем получении окна сообщение завершается сбоем, так как Wndproc был выгружен.

Прежде чем получить отсоединение процесса, необходимо уничтожить окно. Опасность заключается не в том, что пользователь32 будет выгружен. Опасность заключается в том, что вы выгрузили. Таким образом, следующее сообщение о том, что окно получит сбой процесса, так как user32 доставляет сообщение в Wndproc, которое больше не существует.

Операционная система Microsoft Windows имеет сходство потоков. Отсоединение процесса не выполняется. Блокировка загрузчика на самом деле не является большой проблемой; проблема — Dllmain. Отсоединение процесса — это последний раз, когда библиотека DLL получает код выполнения. Прежде чем вернуться, необходимо избавиться от всего. Но так как Windows имеет сходство потоков, вы не можете очистить окно, если вы находитесь в неправильном потоке.

Блокировка загрузчика вставляется в рисунок, если у кого-то установлен глобальный крючок (например, шпион++ работает). В этом случае вы вводите потенциальный сценарий взаимоблокировки. Опять же, решение состоит в том, чтобы уничтожить окно, прежде чем получить отсоединение процесса.

Требуется ли увеличить начальные фиксации стека, чтобы избежать переполнения?

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

Давайте посмотрим, что будет стоить сделать все службы, работающие в svchost.exe маркерной защиты. На тестовом компьютере я получаю 9 svchost.exe процессов, имеющих в общей сложности 139 потоков. Если установить стек по умолчанию для каждого потока в 32K, нам потребуется примерно 32K x 200 ~ 6,4 МБ файлового пространства страницы, чтобы зафиксировать все стеки заранее.

Это довольно небольшая цена для оплаты надежности.

Что такое зарезервированный размер стека?

Существуют интересные элементы, такие как отправка исключений в IA64/AMD64, для которых требуется дополнительный стек "непредвиденный". В рабочих потоках RPC может возникнуть некоторая обработка, требования к стеку которых были в прошлом разумными попытками оценить их.

Во-первых, вы должны получить представление обо всех пулах потоков, живущих в процессе. Пул NT-Thread-Pool с потоком ожидания оповещений иногда специальный, так как, например, если вы используете компонент базы данных из SQL, он будет использовать оповещенные спящие режимы через поток, который является целью пользователя-APC. Это может привести к проблемам с вложенными вызовами.

После того как вы знаете все пулы потоков, получите представление о том, как управлять требованиями к стеку. Например, RPC считывает раздел реестра для фиксации стека. Потоки насоса WDM получают это из образа. Для других пулов потоков может отличаться миля.

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

Существуют ли рекомендации по выбору подходящего размера для LINKER_STACKCOMMITSIZE=?

Значение должно быть делимо по размеру страницы (4k/8k в зависимости от ЦП). Ниже приведены некоторые рекомендации по определению нужного размера:

Преобразуйте все рекурсивные функции с потенциальной несоответной глубиной (или, по крайней мере, высокой глубиной пользователя) в итеративную.
Сокращение использования alloca. Используйте кучу или безопасное лопа.
Выполните предварительную проверку размера стека (например, 8 кб). Исправьте эти функции, помеченные как использование слишком большого стека.
Установите фиксацию стека на 16 кб.
Запустите в отладчике кучу тестов с помощью проверки приложений "Stacks" (Стеки).
Когда вы видите переполнение стека определите худших правонарушителей и исправьте их. (См. шаг 5.)
Если вы не можете уменьшить использование стека больше на 8 кб. Если вы > 64k есть что-то неправильное, уменьшите до 64k и просмотрите шаг 6. В противном случае перейдите к шагу 5.

Каковы требования к памяти для теста кучи?

Для полных тестов кучи вам потребуется 256 МБ ОЗУ и по крайней мере 1 ГБ-файл страницы. Для обычных тестов кучи потребуется не менее 128 МБ ОЗУ. Нет конкретных требований к процессору или диску.

Почему я получаю ALL_ACCESS остановку?

Любое приложение, использующее _ALL_ACCESS отрисовывает объект, к которому он обращается, недоступно, так как журнал аудита не будет отражать то, что вы на самом деле сделали с объектом— только то, что вы попросили сделать с объектом.

Это условие создает камуфляж для более сомнительной атаки. Администратор, сканирующий действие атаки, не увидит ничего плохого с пользователем, запрашивающим ALL_ACCESS на ключ X, так как конкретное приложение всегда делает это. Администратор будет думать, что "человек, вероятно, просто работает Word". Администратор не может сказать, что хакер проник в мою учетную запись и теперь проверит систему, чтобы определить, какой доступ у меня есть, который он может использовать для его отвратительных целей. Возможности безграничны.

Проблема ACL с ALL_ACCESS заключается в том, что вы всегда должны быть предоставлены ему. Если мы хотели, чтобы когда-нибудь запретить доступ DELETE к определенному ключу, мы не смогли бы. Несмотря на то, что вы на самом деле не удалили ключ, мы разорвали приложение, так как запросите доступ к удалению.

Почему я не получаю журналы из кучи и тестов блокировки?

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

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

Почему внедрение ошибок не работает?

Вероятность внедрения сбоя была изменена на части на миллион в сборках AppVerifier, выпущенных после февраля 2007 года на основе отзывов клиентов. Таким образом, вероятность 0n20000 составляет 2%, 0n500000 составляет 50% и т. д.

Расширение отладчика !avrf –flt можно использовать для изменения вероятности на лету в отладчике. Однако для работы с этим процессом следует включить проверку низкой симуляции ресурсов.

Расширение отладчика !avrf является частью exts.dll, которая поставляется с пакетом отладчика. Изменения в !avrf, поддерживающие изменение вероятности, находятся в последнем пакете отладчика. Если у вас возникли проблемы с внедрением ошибок, обновите отладчики и пакет AppVerifier.

Почему средство проверки утечки не сообщает о некоторых утечках ресурсов?

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

Чтобы проверить ресурсы, выделенные загруженной библиотекой DLL или EXE, используйте расширение отладчика !avrf -leak.