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

Статья
06/14/2023

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. статьи об установке и установке отладчика— начало работы с помощью отладки Windows.

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

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

Например, вызов CreateFileA будет вызовом appvocre! NS_SecurityChecks::CreateFileA, который может вызывать appvcore! NS_FillePaths::CreateFileA, который может вызывать kernel32! 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.

Вероятно, вы включили только уровни проверки оболочки и /или кучу в режиме "чистый". Вот некоторые из возможных причин.

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

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

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

Создайте копию 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-разрядного собственного целевого объекта.

Длинная версия. Параметры средства проверки приложений — это правильное объединение основных и параметров оболочки.

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

Значение "Отладчик" считывается из запускающего приложения. Таким образом, если вы хотите, чтобы 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 с именем Debugger и задайте для этого значения путь, по которому находится отладчик. Он должен содержать полный путь, а не только имя отладчика. Команда должна включать параметр –server и определенный порт или диапазон портов, который должен прослушивать отладчик. Например, c:\debuggers\ntsd.exe –server tcp:port=5500:5600 –g –G.

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

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

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

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

Имейте в виду, что ObsoleteAPICalls просто выплевает предупреждение для каждого вызова, который он видит в API, который указан как устаревший или нерекомендуемый в MSDN. Следует в индивидуальном порядке решить, важно ли для вашего приложения переходить на новые API. Некоторые API опасны, а некоторые просто заменены более новым API с дополнительными вариантами. Дополнительные сведения см. в разделе "Опасные API" статьи Написание безопасного кода, 2-е дополнение.

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

Тестовые вопросы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как насчет размера зарезервированного стека?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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