Automatyczne kontrole

Weryfikator sterowników przeprowadza następujące kontrole za każdym razem, gdy weryfikuje co najmniej jeden sterownik. Nie można aktywować ani dezaktywować tych testów. Począwszy od systemu Windows 10 w wersji 1709, te automatyczne kontrole zostały przeniesione do odpowiednich flag standardowych. W związku z tym użytkownicy włączający weryfikator sterowników z flagami standardowymi nie powinni widzieć żadnej redukcji zastosowanych kontroli.

Monitorowanie procedur IRQL i pamięci

Weryfikator sterownika monitoruje wybrany sterownik dla następujących akcji zabronionych:

• Podnoszenie poziomu IRQL przez wywołanie KeLowerIrql

• Podnoszenie poziomu IRQL przez wywołanie KeRaiseIrql

• Żądanie alokacji pamięci o zerowym rozmiarze

• Przydzielanie lub zwalnianie stronicowanej puli przy użyciu APC_LEVEL IRQL >

• Przydzielanie lub zwalnianie puli niestronicowanej przy użyciu DISPATCH_LEVEL IRQL >

• Próba zwolnienia adresu, który nie został zwrócony z poprzedniej alokacji

• Próba zwolnienia adresu, który został już zwolniony

• Uzyskiwanie lub wydawanie szybkiego mutexu za pomocą APC_LEVEL IRQL >

• Uzyskiwanie lub zwalnianie blokady spinowej z IRQL różne od DISPATCH_LEVEL

• Podwójne zwolnienie spinlocka.

• Należy oznaczyć żądanie alokacji jako MUST_SUCCEED. Żadne takie żądania nigdy nie są dopuszczalne.

Jeśli weryfikator sterowników nie jest aktywny, naruszenia te mogą nie spowodować natychmiastowej awarii systemu we wszystkich przypadkach. Weryfikator sterownika monitoruje zachowanie sterownika i sprawdza usterkę 0xC4, jeśli wystąpi jakiekolwiek z tych naruszeń. Aby uzyskać listę parametrów kodu błędu, zobacz Kod błędu 0xC4 (DRIVER_VERIFIER_DETECTED_VIOLATION).

Monitorowanie przełączania stosu

Weryfikator sterowników monitoruje użycie stosu przez weryfikowany sterownik. Jeśli sterownik przełącza swój stos, a nowy stos nie jest ani stosem wątku, ani stosem DPC, zostanie wystawiona kontrola błędów. (Będzie to sprawdzanie błędów 0xC4 z pierwszym parametrem równym 0x90). Stos wyświetlany przez polecenie debugera KB zwykle ujawnia sterownik, który wykonał tę operację.

Sprawdzanie zwolnienia sterownika

Po zakończeniu weryfikacji sterownika, weryfikator sterownika wykonuje kilka sprawdzeń, aby upewnić się, że sterownik usunął zbędne elementy.

W szczególności weryfikator sterowników szuka:

• Nieusunięte czasomierze

• Oczekujące wywołania procedury odroczonej (DPC)

• Nieukończone listy lookaside

• Nieukończone wątki robocze

• Nieukończone kolejki

• Inne podobne zasoby

Problemy, takie jak te, mogą spowodować, że kontrole błędów systemowych będą pojawiać się jakiś czas po wyładowaniu sterownika, a przyczyna tych kontroli błędów może być trudna do ustalenia. Gdy weryfikator sterownika jest aktywny, takie naruszenia spowodują natychmiastowe wystawienie błędu kontrolnego 0xC7 po usunięciu sterownika. Aby uzyskać listę parametrów kodu 0xC7 sprawdzania błędów, zobacz Kod Sprawdzania Błędów 0xC7 (TIMER_OR_DPC_INVALID).

Monitorowanie użycia deskryptora pamięci (MDL)

W systemie Windows Vista weryfikator sterowników monitoruje również wybrany sterownik dla następujących zabronionych akcji:

• Wywoływanie elementu MmProbeAndLockPages lub MmProbeAndLockProcessPages w języku MDL, który nie ma odpowiednich flag. Na przykład niepoprawne jest wywoływanie MmProbeAndLockPages dla MDL utworzonej przy użyciu MmBuildMdlForNonPagedPool.

• Wywoływanie elementu MmMapLockedPages w języku MDL, który nie ma odpowiednich flag. Na przykład niepoprawne jest wywołanie funkcji MmMapLockedPages dla MDL, który jest już zmapowany na adres systemowy lub dla MDL, który nie jest zablokowany.

• Wywoływanie MmUnlockPages lub MmUnmapLockedPages na częściowym MDL, czyli na MDL utworzonym przy użyciu IoBuildPartialMdl.

• Wywoływanie elementu MmUnmapLockedPages w języku MDL, który nie jest mapowany na adres systemowy.

Jeśli weryfikator sterowników nie jest aktywny, naruszenia te mogą nie spowodować, że system przestanie odpowiadać natychmiast we wszystkich przypadkach. Weryfikator sterownika monitoruje zachowanie sterownika i sprawdza usterkę 0xC4, jeśli wystąpi jakiekolwiek z tych naruszeń. Aby uzyskać listę parametrów kodu błędu, zobacz Kod błędu 0xC4 (DRIVER_VERIFIER_DETECTED_VIOLATION).

Alokacja obiektu synchronizacji z pamięci NonPagedPoolSession

Począwszy od systemu Windows 7, weryfikator sterowników sprawdza obiekty synchronizacji z pamięci sesji.

Obiekty synchronizacji muszą być niestronicowalne. Muszą również istnieć w globalnej, wirtualnej przestrzeni adresowej dla całego systemu.

Sterownik graficzny może przydzielić pamięć sesji przez wywołanie interfejsów API, takich jak EngAllocMem. W przeciwieństwie do globalnej przestrzeni adresowej przestrzeń adresowa sesji jest zwirtualizowana dla każdej sesji serwera terminali. Oznacza to, że ten sam adres wirtualny używany w kontekście dwóch różnych sesji odnosi się do dwóch różnych obiektów. Jądro systemu Windows musi mieć dostęp do obiektów synchronizacji z dowolnej sesji serwera terminali. Próba odwołania się do adresu pamięci sesji z innej sesji ma nieprzewidywalne wyniki, takie jak awarie systemu lub dyskretne uszkodzenie danych innej sesji.

Począwszy od systemu Windows 7, gdy zweryfikowany sterownik inicjuje obiekt synchronizacji, wywołując interfejsy API, takie jak KeInitializeEvent lub KeInitializeMutex, Driver Verifier sprawdza, czy adres obiektu znajduje się wewnątrz wirtualnej przestrzeni adresowej sesji. Jeśli weryfikator sterownika wykryje tego rodzaju niepoprawny adres, generuje Sprawdzanie błędów 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION, z wartością parametru 1 równą 0xDF.

Licznik odwołania do obiektu zmienia się z 0 na 1

Począwszy od systemu Windows 7, weryfikator sterowników sprawdza dodatkowe klasy niepoprawnych odwołań do obiektów.

Gdy menedżer obiektów jądra systemu Windows tworzy obiekt, taki jak obiekt File lub obiekt wątku, licznik odwołania nowego obiektu jest ustawiony na 1. Licznik odwołań jest zwiększany przez wywołania interfejsów API, takich jak ObReferenceObjectByPointer lub ObReferenceObjectByHandle. Licznik odwołań jest dekrementowany przez każde wywołanie obDereferenceObject dla tego samego obiektu.

Gdy licznik odwołań osiągnie wartość 0, obiekt może zostać zwolniony. Menedżer obiektów może go zwolnić natychmiast lub zwolnić go później. Wywoływanie ObReferenceObjectByPointer lub ObDereferenceObject i zmiana licznika odwołania z 0 na 1 oznacza zwiększenie licznika odwołania już zwolnionego obiektu. Jest to zawsze nieprawidłowe, ponieważ może to spowodować uszkodzenie alokacji pamięci innej osoby.

Bloki lub opóźnienia zamykania systemu

Począwszy od systemu Windows 7, Weryfikator sterowników wywołuje przerwanie w debugerze jądra, jeśli zamknięcie systemu nie zakończy się 20 minut po jego rozpoczęciu. Weryfikator sterowników określa początek wyłączania systemu jako moment, gdy jądro Windows rozpoczyna zamykanie różnych podsystemów, takich jak Rejestr, Plug And Play lub podsystemy menedżera we/wy.

Jeśli debuger jądra nie jest dołączony do systemu, Weryfikator Sterowników wystawia błąd sprawdzenia 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION przy wartości parametru 1 równej 0x115, zamiast tego punktu przerwania.

Często zamykanie systemu, które nie może zakończyć się w mniej niż 20 minut, wskazuje, że jeden z sterowników uruchomionych w tym systemie działa nieprawidłowo. Uruchomienie !analyze -v z debugera jądra wyświetla ślad stosu systemowego wątku roboczego, który odpowiada za zamknięcie. Należy zbadać ten ślad stosu i określić, czy wątek zamknięcia jest blokowany przez jeden z testowanych sterowników.

Czasami system nie może zostać zamknięty, ponieważ podlega testom przeciążeniowym, mimo że wszystkie sterowniki działają prawidłowo. Użytkownik może wybrać kontynuowanie wykonywania po tym punkcie przerwania Driver Verifier i sprawdzić, czy system ostatecznie się wyłączy.