Wysłany: 2008-03-11, 18:53 Jak zdebugować system po wystąpieniu błędu zatrzymania......
Jak zdebugować system po wystąpieniu błędu zatrzymania IRQL_NOT_LESS_OR_EQUAL (0xA)
Streszczenie
W tym artykule opisano sposób użycia przykładowej sesji debugowania w celu ustalenia, który sterownik powoduje występowanie następującego komunikatu o błędzie:
Stop Error IRQL_NOT_LESS_OR_EQUAL (0xA)
Symptomy
Gdy zostanie zainstalowany sterownik, system przestaje odpowiadać i pojawia się następujący komunikat o błędzie w funkcji nt!KiActivateWaiterQueue+0x27:
Stop Error IRQL_NOT_LESS_OR_EQUAL (0xA)
Wstępne śledzenie stosu wskazuje na to, że przyczyną problemu jest sterownik Fast Fat.
Przyczyna
Ten problem występuje zwykle wtedy, gdy przed wykonaniem elementu pracy sterowniki wywołają dwa razy funkcję IoQueueWorkItem() lub ExQueueWorkItem() tego samego elementu pracy.
Problem ten dotyczy szczególnie sterowników urządzeń, które przydzielają strukturę IO_WORKITEM lub strukturę WORK_QUEUE_ITEM w sposób statyczny. Takie sterowniki urządzeń muszą zagwarantować, że nie zezwolą na użycie statycznie przydzielonego elementu, który znajduje się w kolejce.
Więcej informacji
Aby zdebugować system, który przestał odpowiadać po wystąpieniu błędu opisanego w sekcji „Symptomy”, wykonaj następujące kroki:
1. Załóżmy na przykład, że został zainstalowany sterownik o nazwie Xyz.sys, system przestał odpowiadać i pojawił się błąd zatrzymania 0xA, o którym wspomniano wcześniej.
2. Uruchom debugera przy użyciu poprawnych symboli, a następnie wykonaj przykładowe debugowanie, które opisano dalej w tym artykule.
W tym przykładzie użyto debugera jądra. Można użyć programu KD lub WinDbg. Z tej metody można również skorzystać, włączając weryfikator sterowników.
3. Polecenie kv debugera wyświetla stos. Poniższy ślad stosu wskazuje, że kolejka WORKER_QUEUE została uszkodzona.
Ślad stosu:
4. Po przejrzeniu stosu przedstawionego w kroku 3 można dojść do wniosku, że przyczyną problemu jest sterownik Fast Fat. Jednak w strukturze KQUEUE znajduje się uszkodzony element LIST_ENTRY:
5. Cofnięcie odwołania do struktury BLINK przesuwa wskaźnik stosu na element WORK_QUEUE_ITEM (czyli faktycznie pierwszy parametr w elemencie pracy IO_WORKITEM).
Uwaga Dostęp do definicji struktury elementu pracy IO_WORKITEM można uzyskać przy użyciu serwera symboli dla systemu Windows XP i jego nowszych wersji. W starszych wersjach systemu Windows struktura jest taka sama, ale symbole są niedostępne.
Uwaga Na podstawie zawartości obiektu urządzenia nie można określić, czy jest on prawidłowy. Zawartość pola Context jest jednak prawidłowa, a polecenie !pool wyświetla wartość pooltag znacznika Culprit Pool Tag.
6. Aby ustalić, czy adres procedury jest prawidłowy, użyj polecenia ln, podając adres puli. Jeśli istnieją symbole, wynikiem użycia polecenia ln na adresie puli będzie odpowiedni adres sterownika culprit. Dlatego można przypuszczać, że element pracy IO_WORKITEM odpowiada pewnemu urządzeniu, które zostało utworzone przez sterownik znacznika puli.
7. W poniższym kodzie kolejka pracy zawiera pojedynczy element. Z tego względu łatwo jest go odnaleźć, cofając odwołanie do struktury BLINK. Ponieważ kolejka pracy może zawierać wiele elementów, należy cofać odwołania do struktur BLINK każdego z elementów pracy, aż do odnalezienia elementu pracy, którego struktura BLINK wskazuje na kolejkę KQUEUE.
Kod:
kd> !pool 81f4a14c
Pool page 81f4a14c region is Nonpaged pool
*81f4a140 size: 2b8 previous size: 8 (Allocated) *Culprit Pool Tag
Rozwiązanie
Aby zapobiec zatrzymaniu systemu po wystąpieniu tego błędu zatrzymania, wyłącz nieprawidłowo działający sterownik urządzenia, który został wykryty podczas sesji debugowania, i zastąp go innym.
Nie możesz pisać nowych tematów Nie możesz odpowiadać w tematach Nie możesz zmieniać swoich postów Nie możesz usuwać swoich postów Nie możesz głosować w ankietach Nie możesz załączać plików na tym forum Nie możesz ściągać załączników na tym forum