Seite 7 von 7 ErsteErste ... 3 4 5 6 7
Ergebnis 91 bis 94 von 94

Thema: Bluescreens von ntoskrnl.exe nach Upgrade auf Win 8.1

  1. #91
    Quintus
    kennt sich schon aus

    AW: Bluescreens von ntoskrnl.exe nach Upgrade auf Win 8.1

    Das Spiel, das ich zu dem Zeitpunk offen hatte war Old School Runescape.

    Ich werde es mal deinstallieren und ein anderes offen lassen, um zu testen ob es das war.

  2. #92
    Quintus
    kennt sich schon aus

    AW: Bluescreens von ntoskrnl.exe nach Upgrade auf Win 8.1

    Nabend Leute,

    bin mal wieder da, mit zwei komplett neuen Crashes. Weiterhin ntoskrnl dabei:

    Welche Software nutzt ihr eigentlich um die Teile auszulesen/herauszufinden, welches Programm oder Treiber zuletzt aktiv war? Vielleicht sollte ich mir das Mal antrainieren.

    Hier die Dumps:

    DMP 13.02.2020.zip

  3. #93
    Silver Server
    gehört zum Inventar Avatar von Silver Server

    AW: Bluescreens von ntoskrnl.exe nach Upgrade auf Win 8.1

    Filde 021220-24781-01.dmp
    verborgener Text:
    SYMBOL_NAME: NETwew00+1ee979

    MODULE_NAME: NETwew00

    IMAGE_NAME: NETwew00.sys

    STACK_COMMAND: .thread ; .cxr ; kb

    BUCKET_ID_FUNC_OFFSET: 1ee979

    FAILURE_BUCKET_ID: 0x1E_c0000005_R_STACKPTR_ERROR_NETwew00!unknown_function
    Der Treiber des Wireless WiFi Link Adapter hat den Fehler ausgelöst.

    ---------------------

    File 021320-21375-01.dmp

    verborgener Text:
    RVPOWERSTATE_SUBCODE: 3

    IMAGE_NAME: usbhub.sys

    MODULE_NAME: usbhub

    FAULTING_MODULE: fffff80154200000 usbhub

    CUSTOMER_CRASH_COUNT: 1

    PROCESS_NAME: System
    Der Standardhubtreiber für USB Treiber hat hier den Fehler ausgelöst.

    _______________________________________________

    Hier findest Du erste Informationen wie man die Dumpfile auswertet.
    https://www.informationsarchiv.net/articles/2179/

  4. #94
    Ari45
    gehört zum Inventar Avatar von Ari45

    AW: Bluescreens von ntoskrnl.exe nach Upgrade auf Win 8.1

    Guten Abend zusammen!
    Die Infgormationen aus der Dumpfile 021320-21375-01.dmp lassen sich noch etwas konkreter darstellen, denn es läßt sich ein konkreter USB-Treiber ermitteln.
    verborgener Text:
    Code:
    DRIVER_POWER_STATE_FAILURE (9f)
    A driver has failed to complete a power IRP within a specific time.
    Arguments:
    Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
    Arg2: ffffe00148843060, Physical Device Object of the stack
    Arg3: ffffd0004ca74960, nt!TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
    Arg4: ffffe0014b0ef810, The blocked IRP  
    Arg1 gibt das Objekt an, das den IRP-Stack blockiert
    Arg4 ist die Adresse des IRP-Stack; damit läßt sich der Treiber ermitteln
    ....
    FAILURE_BUCKET_ID:  0x9F_3_FocusriteUSB_IMAGE_usbhub.sys
    Hier wird schon mal auf den möglichen Verursacher FocusriteUSB.sys hingewiesen
    Der Nachweis steht noch aus
    ....
    Mit Arg2 das Device-Object abfragen
    !devobj ffffe00148843060
    Device object (ffffe00148843060) is for:
     Cannot read info offset from nt!ObpInfoMaskToOffset
     \Driver\usbhub DriverObject ffffe00148597c80
    Current Irp 00000000 RefCount 1 Type 00000022 Flags 00003040
    SecurityDescriptor ffffc0016d67dae0 DevExt ffffe001488431b0 DevObjExt ffffe00148843d60 DevNode ffffe0014a4b46a0 
    ExtensionFlags (0000000000)  
    Characteristics (0x00000100)  FILE_DEVICE_SECURE_OPEN
    AttachedDevice (Upper) ffffe0014a4b4040 \Driver\ACPI
    Device queue is not busy.
    Das war nichts, nur allgemein USBHub; aber mit DevNode kann weiter gegraben werden
    !devnode ffffe0014a4b46a0
    DevNode 0xffffe0014a4b46a0 for PDO 0xffffe00148843060
      Parent 0xffffe00148bbf4f0   Sibling 0000000000   Child 0000000000   
      InstancePath is "USB\VID_1235&PID_8016\6&330c3fed&0&5"
      ServiceName is "FocusriteUSB"
    Hier wird es schon konkreter
      TargetDeviceNotify List - f 0xffffc0016eba5120  b 0xffffc0016eba5120
      State = DeviceNodeStarted (0x308)
      Previous State = DeviceNodeEnumerateCompletion (0x30d)
    ....
    Jetzt mit Arg4 den IRP-Stack abfragen
    !irp ffffe0014b0ef810
    Irp is active with 10 stacks 9 is current (= 0xffffe0014b0efb20)
     No Mdl: No System Buffer: Thread 00000000:  Irp stack trace.  Pending has been returned
         cmd  flg cl Device   File     Completion-Context
     [N/A(0), N/A(0)]
                0  0 00000000 00000000 00000000-00000000    
    // wegen der besseren Übersicht habe ich hier 6 Null-Stacks enfernt
    [IRP_MJ_POWER(16), IRP_MN_WAIT_WAKE(0)]
                0  0 ffffe00148843060 00000000 00000000-00000000    
    	       \Driver\usbhub
    			Args: 00000000 00000000 00000000 00000002
    .....
    >[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
                0 e1 ffffe0014a4b9a10 00000000 fffff8012d3827fc-ffffe00147fee550 Success Error Cancel pending
    	      Unable to load image \SystemRoot\System32\drivers\FocusriteUSB.sys, Win32 error 0n2
    *** WARNING: Unable to verify timestamp for FocusriteUSB.sys
     \Driver\FocusriteUSB	nt!PopRequestCompletion
    			Args: 00051100 00000001 00000001 00000002
    // Hier ist jetzt klar, dass der Treiber FocusriteUSB.sys den IRP-Stack blockiert. 
    
    // hier ist nun Ende. Das Abfragen von classpnp!_FUNCTIONAL_DEVICE_EXTENSION mit
    der rot markierten Adresse bringt keine tieferen Erkenntnisse

    Hier habe ich mal etwas tiefer gegraben, um den fehlerhaften Treiber aus FAILURE_BUCKET_ID zu ermitteln. Dort wurde auch der USBHub als Ursache genannt. Darauf muss man sich nicht verlassen, was im Folgenden auch bestätigt wurde.
    Der wirkliche Verursacher ist der Treiber, der den IRP-Stack blockiert.
    Und das war image \SystemRoot\System32\drivers\FocusriteUSB.sys

    Einen IRP-Stackframe über dem blockierten Stack wartet das System darauf, aufgeweckt zu werden.

    Noch eine kurze Erklärung zu den Argumenten des IRP-Stack
    [IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
    IRP-Major-Parameter = Power soll geändert werden
    IRP-Minor-Parameter = Power soll neu gesetzt werden (wahrscheinlich erhöht)
    Normalerweise kann man mit der rot markierten Adresse und und dem Debuggerbefehl classpnp!_FUNCTIONAL_DEVICE_EXTENSION eine sehr lange Liste mit genaueren Werten zum IRP-Stackframe und dem Gerät
    ermitteln. Leider bringt das in diesem Fall nur Speichermüll.

    Aber ich denke, der ware Übeltäter ist hinreichend ermittelt.
    Nun kommt es darauf an, zu ermitteln, wozu dieser Treiber gehört. Er ist ja kein Treiber des Windows-Systems.

Lesezeichen


  • An Google übertragen Google
  • -->

    Berechtigungen

    • Neue Themen erstellen: Nein
    • Themen beantworten: Nein
    • Anhänge hochladen: Nein
    • Beiträge bearbeiten: Nein
    •