Debugowanie stoiska przetwarzania

Zacznij od znalezienia odpowiedniego numeru PIN. W hipotetycznym przypadku odpowiedni pin przechwytywania wideo ma adres 8160DDE0, więc używamy polecenia rozszerzenia !ks.dump na tym adresie, aby uzyskać więcej informacji:

kd> !ks.dump 8160DDE0 7
Pin object 8160DDE0 [CKsPin = 8160DD50]
    DeviceState    KSSTATE_RUN
    ClientState    KSSTATE_RUN
    CKsPin object 8160DD50 [KSPIN = 8160DDE0]
        State                    KSSTATE_RUN
        Processing Mutex         8160DFD0 is not held
        And Gate &               8160DF88
        And Gate Count           1

Najpierw ustal, czy pin jest w odpowiednim stanie i czy mutex przetwarzania jest blokowany przez inny wątek. W tym przypadku stan pinu jest KSSTATE_RUN, jak powinno być, a mutex przetwarzania nie jest trzymany, więc użyjemy następnie rozszerzenia !ks.dumpqueue aby ustalić, czy są dostępne ramki.

kd> !ks.dumpqueue 8160DDE0 7
Queue 8172D5D8:
 Frames Received  : 763
    Frames Waiting   : 5
...<this part of display not shown>...
Queue 8172D5D8:
 Frame Header 81B77E60:
        Irp = 816EE008
        Refcount = 1
    Frame Header 81A568D0:
        Irp = 816DE008
        Refcount = 0
    Frame Header 81844ED8:
        Irp = FFA0F650
        Refcount = 0
    Frame Header 8174B0B0:
        Irp = FFABB460
        Refcount = 0
    Leading Edge:
        Stream Pointer 8183EA58 [Public 8183EA90]:
            Frame Header = 81B77E60
...<this part of display not shown>...

W powyższym częściowym wyświetleniu danych wyjściowych !ks.dumpqueue widzimy, że jest pięć ramek oczekujących lub dostępnych. Czy te ramki są przed lub za krawędzią wiodącą? W wyświetlaczu !ks.dumpqueue ramki są zawsze wyświetlane od najstarszych do najnowszych. Nagłówek ramki krawędzi wiodącej jest zgodny z pierwszą wyświetloną ramką, najstarszą ramką. W związku z tym wszystkie dostępne ramki wyprzedzają krawędź wiodącą.

Jeśli tak nie było, a zamiast tego wszystkie ramki znajdowały się za czołową krawędzią i miały licznik odniesień ze względu na wskaźniki klonowania, problemy najprawdopodobniej pochodzą z samego sprzętu lub z programowania tego sprzętu przez sterownik. Upewnij się, że sprzęt sygnalizuje ukończenie buforu (sprawdź przerwania i kontrolery DPC) i określ, czy sterownik odpowiada odpowiednio na te powiadomienia (usuwając klony po zakończeniu buforu, na przykład).

Jeśli, podobnie jak w naszym przykładzie, wszystkie ramki wyprzedzają czołówkę, problem jest prawie na pewno związany z oprogramowaniem. Dalsze informacje można uzyskać, patrząc na bramę And pin.

Interpretowanie bramy And

Bramki "And" pinów kontrolują przetwarzanie. Jeśli liczba bramek wynosi jedna, można rozpocząć przetwarzanie. Uzyskaj bieżący stan bramy And przy użyciu rozszerzenia !ks.dump :

kd> !ks.dump 8160DDE0 7
Pin object 8160DDE0 [CKsPin = 8160DD50]
    DeviceState    KSSTATE_RUN
    ClientState    KSSTATE_RUN
    CKsPin object 8160DD50 [KSPIN = 8160DDE0]
        State                    KSSTATE_RUN
        Processing Mutex         8160DFD0 is not held
        And Gate &               8160DF88
        And Gate Count           1

Ponieważ liczba bramek jest jedna, bramka And jest otwarta. W takim przypadku zbadaj następujące potencjalne przyczyny zatrzymania przetwarzania:

• Wysyłanie procesu niepoprawnie zwróciło STATUS_PENDING.

• Brakuje wywołania KsPinAttemptProcessing w przypadku dostępności danych.