Другие проверки

Параметр "Другие проверки" средства проверки драйверов отслеживает драйвер для распространенных ошибок, которые вызывают сбой драйвера или системы, например освобождение памяти, которая по-прежнему содержит активные объекты ядра.

В частности, параметр "Прочие проверки" ищет следующее неправильное поведение драйвера:

• Активные рабочие элементы в свободной памяти. Драйвер вызывает ExFreePool для освобождения блока пула, содержащего рабочие элементы, которые были в очереди с помощью IoQueueWorkItem.

• Активные ресурсы в свободной памяти. Драйвер вызывает ExFreePool для освобождения блока пула, содержащего активные структуры ERESOURCE. Драйвер должен вызвать ExDeleteResource для удаления объектов ERESOURCE перед вызовом ExFreePool.

• Активные списки lookaside в свободной памяти. Драйвер вызывает ExFreePool для освобождения блока пула, который по-прежнему содержит активные списки lookaside (NPAGED_LOOKASIDE_LIST или PAGED_LOOKASIDE_LIST структуры. Драйвер должен вызвать ExDeleteNPagedLookasideList или ExDeletePagedLookasideList , чтобы удалить списки lookaside перед вызовом ExFreePool.

• Проблемы с регистрацией инструментария управления Windows (WMI) и трассировки событий для Windows (ETW). К таким проблемам, обнаруженным проверятелем драйверов, относятся:

  • Драйвер, который пытается выгрузиться, не отменяя регистрацию обратного вызова WMI.

  • Драйвер, который пытается удалить объект устройства, который не был зарегистрирован из WMI.

  • Драйвер, который пытается выгрузить без отмены регистрации поставщиков режима ядра ETW.

  • Драйвер, который пытается отменить регистрацию поставщика, который уже незарегистрирован.

• Обработка ошибок ядра. (Windows Vista и более поздние версии) Включение параметра "Прочие проверки" также активирует трассировку дескрипторов для системного процесса, чтобы помочь в расследовании утечек дескрипторов ядра и в устранении ошибок в Bug Check 0x93: INVALID_KERNEL_HANDLE. При включенной трассировке операций с дескрипторами ядро будет собирать трассировки стека для последних операций открытия и закрытия. Трассировки стека можно отобразить в отладчике ядра с помощью расширения отладчика !htrace . Дополнительные сведения о !htrace см. в документации по средствам отладки для Windows.

• Дескриптор пользовательского режима с доступом к режиму ядра Начиная с Windows 7 при выборе параметра "Другие проверки", средство проверки драйверов также проверяет вызовы ObReferenceObjectByHandle. Невозможно передать дескриптор режима пользователя с доступом к режиму ядра. Если такая операция происходит, Driver Verifier выдает проверку ошибок 0xC4 с параметром 1 значением 0xF6.

• UserMode ожидает, когда объекты синхронизации выделены в стеке ядра

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

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

  Однако, если драйверы вызывают API-интерфейсы, такие как KeWaitForSingleObject или KeWaitForMultipleObjects, чтобы ожидать объекты, выделенные в стеке, они должны указывать для параметра WaitMode API значение KernelMode. Когда все потоки процесса ожидаются в режиме UserMode , этот процесс становится доступным для переключения на диск. Таким образом, если драйвер указал UserMode в качестве параметра WaitMode, операционная система может выгрузить текущий процесс, если все остальные потоки в том же процессе также ожидают в режиме UserMode. Выгрузка всего процесса на диск включает выгрузку его стеков ядра по страницам. Ожидание объекта синхронизации, который был выгружен операционной системой, является некорректным. В какой-то момент поток должен появиться и дать сигнал объекту синхронизации. Сигнализация объекта синхронизации включает манипуляцию объектом ядром Windows на уровне IRQL = DISPATCH_LEVEL или выше. Попытка доступа к выгруженной из памяти или обменянной памяти на уровне DISPATCH_LEVEL или выше приводит к сбою системы.

  Начиная с Windows 7, при выборе параметра "Другие проверки" средство проверки драйверов удостоверяется, что объекты синхронизации, которые проверяемый драйвер использует для ожидания в UserMode, не выделяются на стеке ядра текущего потока. Когда программа Driver Verifier обнаруживает такое неправильное ожидание, она выдает проверку ошибок 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION со значением параметра 1 равным 0x123.

• Неправильные ссылки на дескриптор ядра

  Каждый процесс Windows имеет таблицу дескрипторов. Таблицу дескрипторов можно рассматривать как массив записей дескрипторов. Каждое допустимое значение дескриптора ссылается на допустимую запись в этом массиве.

  Дескриптор ядра — это дескриптор, который является допустимым для таблицы дескрипторов системного процесса. Пользовательский дескриптор, допустимый для любого процесса, кроме системного процесса.

  В Windows 7 средство проверки драйверов обнаруживает попытки ссылаться на значения обработчика ядра, которые являются неверными. Эти дефекты драйвера отображаются как Bug Check 0x93: INVALID_KERNEL_HANDLE, если включена опция "Разные проверки" в Driver Verifier. Как правило, этот тип неправильной ссылки на дескриптор означает, что драйвер уже закрыл этот дескриптор, но всё ещё пытается его использовать. Этот тип дефекта может привести к непредсказуемым проблемам для системы, так как значение дескриптора, на которое ссылается ссылка, возможно, уже было повторно использовано другим не связанным драйвером.

  Если драйвер ядра недавно закрыл дескриптор ядра и позже ссылается на закрытый дескриптор, средство проверки драйверов принудительно проверяет ошибку, как описано ранее. В этом случае выходные данные расширения отладчика !htrace предоставляют трассировку стека для пути кода, закрывающего этот дескриптор. Используйте адрес системного процесса в качестве параметра для !htrace. Чтобы найти адрес системного процесса, используйте команду !process 4 0 .

  Начиная с Windows 7 проверяющий драйвер добавляет проверку в ObReferenceObjectByHandle. Теперь запрещено передавать дескриптор пространства пользовательского режима с доступом в режим ядра. Если такое сочетание обнаружено, Средство проверки драйверов выдает ошибку 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION с параметром 1 со значением 0xF6.

Активация этого параметра

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

• В командной строке

  В командной строке параметр "Прочие проверки" представлен битом 11 (0x800). Чтобы активировать другие проверки, используйте значение флага 0x800 или добавьте 0x800 в значение флага. Рассмотрим пример.

  verifier /flags 0x800 /driver MyDriver.sys
  

  Параметр будет активным после следующей загрузки.

  В Windows Vista и более поздних версиях Windows можно также активировать и деактивировать другие проверки без перезагрузки компьютера, добавив в команду параметр /volatile . Рассмотрим пример.

  verifier /volatile /flags 0x800 /adddriver MyDriver.sys
  

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

  Параметр "Прочие проверки" также включен в стандартные параметры. Рассмотрим пример.

  verifier  /standard /driver MyDriver.sys
  

• Использование диспетчера проверки драйверов

  1. Запустите диспетчер проверки драйверов. В окне командной строки введите средство проверки .

  2. Выберите "Создать настраиваемые параметры" (для разработчиков кода) и нажмите кнопку "Далее".

  3. Выберите отдельные параметры из полного списка.

  4. Выберите "Другие проверки".

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

Просмотр результатов

Чтобы просмотреть результаты параметра "Прочие проверки", используйте расширение !verifier в отладчике ядра. (Сведения о !verifier см. в документации по инструментам отладки для Windows.)

В следующем примере опция "Прочие проверки" выявила активную структуру ERESOURCE в памяти, которую драйвер пытался освободить, что привело к проверке ошибок 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION. Отображение проверки ошибок 0xC4 включает адрес ERESOURCE и затронутую память.

1: kd> !verifier 1

Verify Level 800 ... enabled options are:
 Miscellaneous checks enabled

Summary of All Verifier Statistics

RaiseIrqls                             0x0
AcquireSpinLocks                       0x0
Synch Executions                       0x0
Trims                                  0x0

Pool Allocations Attempted             0x1
Pool Allocations Succeeded             0x1
Pool Allocations Succeeded SpecialPool 0x0
Pool Allocations With NO TAG           0x0
Pool Allocations Failed                0x0
Resource Allocations Failed Deliberately   0x0

Current paged pool allocations         0x0 for 00000000 bytes
Peak paged pool allocations            0x0 for 00000000 bytes
Current nonpaged pool allocations      0x0 for 00000000 bytes
Peak nonpaged pool allocations         0x0 for 00000000 bytes

Driver Verification List

Entry     State           NonPagedPool   PagedPool   Module

8459ca50 Loaded           00000000       00000000    buggy.sys



*** Fatal System Error: 0x000000c4
 (0x000000D2,0x9655D4A8,0x9655D468,0x000000B0)


        0xD2 : Freeing pool allocation that contains active ERESOURCE.
               2 -  ERESOURCE address.
               3 -  Pool allocation start address.
               4 -  Pool allocation size.

Чтобы исследовать выделение пула, используйте расширение отладчика !pool с начальным адресом выделения пула 9655D468. (Флаг 2 отображает сведения о заголовке только для пула, содержащего указанный адрес. Сведения о заголовке для других пулов подавляются.)

1: kd> !pool 9655d468  2
Pool page 9655d468 region is Paged pool
*9655d468 size:   b0 previous size:    8  (Allocated) *Bug_

Чтобы найти сведения об ERESOURCE, используйте расширение отладчика !locks (!kdext*.locks) с указанием адреса структуры.

1: kd> !locks 0x9655D4A8     <<<<<- ERESOURCE @0x9655D4A8 lives inside the pool block being freed

Resource @ 0x9655d4a8    Available
1 total locks

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

1: kd> kb
ChildEBP RetAddr  Args to Child
92f6374c 82c2c95a 00000003 92f68cdc 00000000 nt!RtlpBreakWithStatusInstruction
92f6379c 82c2d345 00000003 9655d468 000000c4 nt!KiBugCheckDebugBreak+0x1c
92f63b48 82c2c804 000000c4 000000d2 9655d4a8 nt!KeBugCheck2+0x5a9
92f63b6c 82e73bae 000000c4 000000d2 9655d4a8 nt!KeBugCheckEx+0x1e
92f63b88 82e78c32 9655d4a8 9655d468 000000b0 nt!VerifierBugCheckIfAppropriate+0x3c
92f63ba4 82ca7dcb 9655d468 000000b0 00000000 nt!VfCheckForResource+0x52
92f63bc8 82e7fb2d 000000b0 00000190 9655d470 nt!ExpCheckForResource+0x21
92f63be4 82e6dc6c 9655d470 92f63c18 89b6c58c nt!ExFreePoolSanityChecks+0x1fb
92f63bf0 89b6c58c 9655d470 00000000 89b74194 nt!VerifierExFreePoolWithTag+0x28
92f63c00 89b6c0f6 846550c8 846550c8 846e2200 buggy!MmTestProbeLockForEverStress+0x2e
92f63c18 82e6c5f1 846e2200 846550c8 85362e30 buggy!TdDeviceControl+0xc4
92f63c38 82c1fd81 82d4d148 846550c8 846e2200 nt!IovCallDriver+0x251
92f63c4c 82d4d148 85362e30 846550c8 84655138 nt!IofCallDriver+0x1b
92f63c6c 82d4df9e 846e2200 85362e30 00000000 nt!IopSynchronousServiceTail+0x1e6
92f63d00 82d527be 00000001 846550c8 00000000 nt!IopXxxControlFile+0x684
92f63d34 82cb9efc 0000004c 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
92f63d34 6a22b204 0000004c 00000000 00000000 nt!KiFastCallEntry+0x12c