Udostępnij przez

Kontrola błędów 0x139: KERNEL_SECURITY_CHECK_FAILURE

Sprawdzanie błędów KERNEL_SECURITY_CHECK_FAILURE ma wartość 0x00000139 i wskazuje, że jądro wykrywa uszkodzenie krytycznej struktury danych.

Ważne

Ten artykuł jest przeznaczony dla programistów. Jeśli jesteś klientem, który otrzymuje kod błędu niebieskiego ekranu podczas korzystania z komputera, zobacz Rozwiązywanie problemów z błędami niebieskiego ekranu.

Sprawdzanie błędów 0x139 KERNEL_SECURITY_CHECK_FAILURE parametrów

Parametr Opis
1 Rodzaj korupcji. Aby uzyskać więcej informacji, zobacz poniższą tabelę.
2 Adres ramki pułapki dla wyjątku, który spowodował sprawdzenie błędu
3 Adres rekordu wyjątku dla wyjątku, który spowodował sprawdzenie błędu
4 Zarezerwowana

W poniższej tabeli opisano możliwe wartości parametru 1.

Parametr 1 Opis
0 Bufor oparty na stosie jest zastępowany (starsze /GS naruszenie).
1 Kod instrumentacji VTGuard wykrył próbę użycia niedozwolonej tabeli funkcji wirtualnych. Zazwyczaj obiekt C++ jest uszkodzony, a następnie wywołanie metody wirtualnej próbowało użyć uszkodzonego obiektu tego wskaźnika.
2 Kod instrumentacji plików cookie stosu wykrył przepełnienie buforu opartego na stosie (naruszenie /GS).
3 LIST_ENTRY jest uszkodzony (na przykład podwójne usunięcie). Aby uzyskać więcej informacji, zobacz następującą sekcję Przyczyna.
4 Zarezerwowana
5 Nieprawidłowy parametr został przekazany do funkcji, która uważa nieprawidłowe parametry za krytyczne.
6 Moduł ładujący nie zainicjował poprawnie pliku cookie zabezpieczeń plików cookie stosu. To sprawdzenie usterek jest spowodowane utworzeniem sterownika do uruchomienia tylko w systemie Windows 8 i próbą załadowania obrazu sterownika we wcześniejszej wersji systemu Windows. Aby uniknąć problemu, należy skompilować sterownik do uruchomienia we wcześniejszej wersji systemu Windows.
7 Zażądano krytycznego zakończenia programu.
8 Sprawdzanie granic tablicy wstawione przez kompilator wykryło nielegalną operację indeksowania tablicy.
9 Wywołanie elementu RtlQueryRegistryValues zostało wykonane określając RTL_QUERY_REGISTRY_DIRECT bez RTL_QUERY_REGISTRY_TYPECHECK, a wartość docelowa nie znajdowała się w zaufanej gałęzi systemu.
10 Pośrednia kontrola funkcji Call Guard wykryła nieprawidłowy transfer sterowania.
11 Sprawdzanie ochrony przed zapisem wykryło nieprawidłowy zapis pamięci.
12 Podjęto próbę przełączenia się na nieprawidłowy kontekst światłowodu.
13 Podjęto próbę przypisania nieprawidłowego kontekstu rejestru.
14 Liczba odwołań do obiektu jest nieprawidłowa.
18 Podjęto próbę przełączenia się na nieprawidłowy kontekst jmp_buf.
19 Wprowadzono niebezpieczną modyfikację danych tylko do odczytu.
20 Autotest kryptograficzny nie powiódł się.
21 Wykryto nieprawidłowy łańcuch wyjątków.
22 Wystąpił błąd biblioteki kryptograficznej.
23 Wykonano nieprawidłowe wywołanie z poziomu DllMain.
24 Wykryto nieprawidłowy adres podstawowy obrazu.
25 Napotkano nieodwracalną awarię podczas ochrony opóźnionego importu obciążenia.
26 Wykonano połączenie z niebezpiecznym numerem wewnętrznym.
27 Została wywołana przestarzała usługa.
28 Wykryto dostęp do bufora poza zakresem.
29 Wpis RTL_BALANCED_NODE RBTree jest uszkodzony.
37 Wywołano wpis tabeli przeskoków przełącznika poza zakresem.
38 Podjęto próbę wykonania polecenia longjmp do nieprawidłowego celu.
39 Nie można ustawić celu połączenia z pominięciem eksportu jako prawidłowego celu połączenia.

Przyczyna

Korzystając z tabeli parametru 1 i pliku zrzutu, można zawęzić przyczynę wielu testów błędów tego typu.

LIST_ENTRY uszkodzenie może być trudne do wytropić. Ta kontrola usterek wskazuje, że niespójność została wprowadzona do podwójnie połączonej listy (wykryto, gdy pojedynczy element wpisu listy został dodany do listy lub usunięty z listy). Niestety, niespójność niekoniecznie jest wykrywana w momencie, gdy doszło do uszkodzenia, więc może być konieczne wykonanie pewnych prac detektywistycznych w celu zidentyfikowania głównej przyczyny.

Do najczęstszych przyczyn uszkodzenia wpisów listy należą:

  • Sterownik uszkodził obiekt synchronizacji jądra, taki jak KEVENT (na przykład podwójne inicjowanie KEVENT, podczas gdy wątek nadal czekał na tej samej KEVENT lub zezwalał na wyjście z zakresu KEVENT opartego na stosie, podczas gdy inny wątek używał tego KEVENT). Ten rodzaj sprawdzania błędów zwykle odbywa się w nt! Ke* lub nt! Kod Ki*. Może się to zdarzyć, gdy wątek zakończy oczekiwanie na obiekt synchronizacji lub gdy kod próbuje umieścić obiekt synchronizacji w stanie sygnalizowanym. Zazwyczaj sygnalizowany obiekt synchronizacji jest obiektem, który jest uszkodzony. Czasami weryfikator sterowników ze specjalną pulą może pomóc w śledzeniu winowajcy (jeśli uszkodzony obiekt synchronizacji znajduje się w bloku puli, który został już uwolniony).
  • Sterownik uszkodził okresowe KTIMER. Ten rodzaj sprawdzania błędów zwykle odbywa się w nt! Ke* lub nt! Kod Ki* i polega na sygnalizowaniu timera lub wstawianiu lub usuwaniu timera z tabeli timera. Czasomierz, który jest manipulowany, może być uszkodzony, ale może być konieczne sprawdzenie tabeli czasomierza za pomocą !czasomierza (lub ręcznego chodzenia linków listy czasomierza) w celu zidentyfikowania, który czasomierz jest uszkodzony. Czasami weryfikator sterowników ze specjalną pulą może pomóc w śledzeniu winowajcy (jeśli uszkodzony KTIMER znajduje się w bloku puli, który jest już uwolniony).
  • Kierowca źle zarządzał wewnętrzną listą połączoną w stylu LIST_ENTRY. Typowym przykładem może być dwukrotne wywołanie RemoveEntryList tego samego wpisu listy bez ponownego wstawiania wpisu listy między dwoma wywołaniami RemoveEntryList . Możliwe są inne warianty, takie jak dwukrotne wstawienie wpisu do tej samej listy.
  • Sterownik zwolnił strukturę danych zawierającą LIST_ENTRY bez usuwania struktury danych z odpowiedniej listy, powodując później wykrycie uszkodzenia po ponownym użyciu starego bloku puli.
  • Sterownik używał listy w stylu LIST_ENTRY w sposób współbieżny bez odpowiedniej synchronizacji, co spowodowało rozdartą aktualizację listy.

W większości przypadków uszkodzoną strukturę danych można zidentyfikować, przesuwając połączoną listę zarówno do przodu, jak i do tyłu (polecenia dl i dlb są przydatne w tym celu) i porównując wyniki. Miejsce, w którym lista jest niespójna między przejściem do przodu i do tyłu, jest zwykle lokalizacją uszkodzenia. Ponieważ operacja aktualizacji listy połączonej może modyfikować łącza listy sąsiedniego elementu, należy uważnie przyjrzeć się sąsiadom uszkodzonego wpisu listy, ponieważ to oni mogą być głównym winowajcą.

Ponieważ wiele składników systemu wewnętrznie korzysta z list LIST_ENTRY, różne typy nieprawidłowego zarządzania zasobami przez sterownik korzystający z systemowych interfejsów API mogą powodować uszkodzenie listy połączonej na liście połączonej zarządzanej przez system.

Rezolucja

Określenie przyczyny problemów z uszkodzeniem wpisu listy zwykle wymaga użycia debugera do zbierania innych informacji. Należy zbadać wiele plików zrzutu, aby sprawdzić, czy kod zatrzymania ma podobne cechy, takie jak kod uruchomiony po wyświetleniu kodu zatrzymania.

Aby uzyskać więcej informacji, zobacz Analiza zrzutu awaryjnego przy użyciu debugerów systemu Windows (WinDbg),Korzystanie z rozszerzenia !analyze i !analyze.

Użyj dziennika zdarzeń, aby sprawdzić, czy występują zdarzenia wyższego poziomu prowadzące do kodu zatrzymania.

Te ogólne wskazówki dotyczące rozwiązywania problemów mogą być pomocne.

  • Jeśli niedawno do systemu został dodany sprzęt, spróbuj go usunąć lub zastąpić. Możesz też skontaktować się z producentem, aby sprawdzić, czy są dostępne jakieś poprawki.

  • Jeśli ostatnio dodano nowe sterowniki urządzeń lub usługi systemowe, spróbuj je usunąć lub zaktualizować. Spróbuj określić, co zmieniło się w systemie, co spowodowało pojawienie się nowego kodu sprawdzania błędów.

  • Sprawdź dziennik systemu w Podglądzie zdarzeń pod kątem innych komunikatów o błędach, które mogą pomóc w określeniu urządzenia lub sterownika powodującego błąd. W dzienniku systemu poszukaj błędów krytycznych, które wystąpiły w tym samym oknie czasowym, co niebieski ekran.

  • Zajrzyj do Menedżera urządzeń , aby zobaczyć, czy jakieś urządzenia są oznaczone wykrzyknikiem (!). Przejrzyj dziennik zdarzeń wyświetlany we właściwościach sterownika dla każdego sterownika, który powoduje błąd. Spróbuj zaktualizować powiązany sterownik.

  • Uruchom program wykrywania wirusów. Wirusy mogą zainfekować wszystkie typy dysków twardych sformatowanych dla systemu Windows, a wynikające z tego uszkodzenie dysku może generować kody sprawdzania błędów systemu. Upewnij się, że program do wykrywania wirusów sprawdza główny rekord rozruchowy pod kątem infekcji.

  • Aby uzyskać bardziej ogólne informacje dotyczące rozwiązywania problemów, zobacz Analizowanie danych z niebieskim ekranem sprawdzania błędów.

Zobacz także

Analiza zrzutu awaryjnego przy użyciu debugerów systemu Windows (WinDbg)

Analiza pliku zrzutu Kernel-Mode za pomocą WinDbg

  • Last updated on