[gelöst] Benötige dringend Hilfe zu ntoskrnl.pdb

Guten Abend,

ich bin neu hier. Mein Betriebssystem ist Windows 8.1

Es ist jetzt fast einen Monat her, dass mein PC zum 1ten mal einen System-STOPP während des Betriebs eingelegt hat und daraufhin nach c.a. 10 Sekunden neu startete (Dies passiert jetzt fast täglich - davon abhängig was ich gerade mache), ein Bluescreen mit dem Fehler "DPC_WATCHDOG_VIOLATION" kommt und der PC erstellt in der Zeit Minidump's. Ich schätze mich in Sachen PC-Kenntnisse als "Fortgeschritten" ein und konnte in der zeit durch WinDbg (Debuggen) bereits Fehler beheben...bis auf einen und dieser ist: ntoskrnl.pdb. Die ntoskrnl.pdb Datei ist überhaupt nicht auf meinem System vorhanden (ich weiß nicht ob sie es jemals war), ebenso wird sie nicht im Microsoft Symbolserver gefunden. - Ich denke mal ein Update hat mir die ganze Sache zuvor etwas zerlegt.

Geradewegs wenn ich einen StressTest für die Hardware starte, insbesondere beim testen des RAM's macht das System dann den Stopp. Hierbei liegt die Auslastung des RAM's dann gerade mal zwischen 60-80% und das System wird gestoppt und startet neu. Ich habe den RAM bereits überprüft mit "MemTest" und der "Windows-Speicherdiagnose" (haben beide nichts gefunden) und die RAM's auch einzeln (aus- und eingebaut) mit Windows getestet. Aber es scheint so zu sein, dass das Problem quasi jeden einzelnen RAM-Riegel betrifft. - Es scheint kein Hardwarefehler zu sein.


Meine bisherigen Fortschritte und Versuche mit diesem Problem:
- Alle Treiber vom Windows-System und der Hardware sind komplett aktuell.
- Ich habe am System und an der Hardware keinerlei Veränderungen vorgenommen.
- Ich habe bereits debugged mit "WinDbg (X64)" und konnte einige der Fehler beheben.
- Ich habe sfc.exe /scannow gestartet und es konnte diverses reparieren (mehrfach) - nichts relevantes ist beschädigt
- Ich habe DISM.exe gestartet, aber das konnte ich nicht zum Erfolg nutzen.
- Ich habe bisher nach Viren gesucht, aber es wurde nichts gefunden.
- Ich habe Symbolpakete zusätzlich heruntergeladen, aber fand darin keine ntoskrnl.pdb Datei.
- Ich habe über das BIOS zusätzlich auch mal von der original Windows CD/DVD gebootet und im "WinRE" dann die "Automatische Reparatur" gestartet, wobei es hier das Problem gab, das es meinen PC nicht hat reparieren können. Kritisch scheint nichts zu sein, es fehlt lediglich eine wichtige Symboldatei (ntoskrnl.pdb) - Die Datei kam wohl mal mit einem Windows-Update und verschwand scheinbar mit einem nicht ordnungsgemäßen Windows-Update...das hat Spuren hinterlassen.

Falls jemand Windows 8.1 mit dem Build 6.3.9600 hat würde ich denjenigen bitten, mir die Datei "ntoskrnl.pdb" per Email zu senden, damit ich sie in den Symbolpfad für ntoskrnl.exe einbinden kann.

Mir gehen nämlich die Ressourcen aus! Auffrischen und Neuinstallation kommt für mich eigentlich nicht in Frage.
Ich habe mal noch die 5 letzten Minidumps mit angehangen (Besitze noch mehr).

PS: Ich habe wirklich alles getan in Sachen Reparatur was ich machen konnte, um die Datei aufzubringen, habe sogar Microsoft angefragt, ob sie mir die Datei schicken könnten - Leider ohne Erfolg.

Der Fehler liegt jeweils im Bereich directx und Grafikkarte.
DirectX neu installieren.
Treiber für die Grafikkarte neu installieren.
Ältere Treiber für die Grafikkarte probieren.
Mit andere Grafikkarte testen.

Hallo, Windows 8.1 symbols package contains ntoskrnl.pdb

hier die downloads
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-symbols

Gruß

Guten Morgen! Willkommen im Forum, @Leadfoot!
Am 6.02.18 hast du den Driver Verifier laufen lassen und um 22:23 Uhr den Stoppfehler DRIVER_VERIFIER_DETECTED_VIOLATION (c4) erhalten. Als Verursacher wurde ein fehlerhafter Treiber avipbb.sys festgestellt, der eine unbekannte Funktion verwendete:
Dieser Treiber ist Bestandteil von AVIRA Antivir.
Was hast du daraufhin unternommen?

Die dann folgenden drei Dumpfiles enthielten den Stoppfehler DPC_WATCHDOG_VIOLATION (133). Der Auslöser war der Treiber dxgkrnl.sys, der allerdings von nvlddmkm+0xc9058 "auf die Reise" geschickt wurde.
Was hast du daraufhin unternommen?

Laut sysinfo ist ein veraltetes BIOS installiert:
BIOS Version 1801
BIOS Release Date 11/12/2013

Auf der Homepage des Motherboards ist verfügbar
BIOS Version 2101
BIOS Datum 2015/08/05

Zwischen dem Installierten BIOS und dem letzten verfügbaren BIOS wurde mindestens drei mal die System-Stabilität verbessert.
https://www.asus.com/de/Motherboards/M5A78LMUSB3/HelpDesk_BIOS/

Und noch ein Gedanke:
Mit Einführung von Windows 8.1 nahmen die Probleme mit Drittanbieter-Sicherheitssoftware zu.
Wenn mit Treiber-Update und BIOS-Update die Stoppfehler nicht beseitigt werden können, ist zu Testzwecken AVIRA (vollständig) zu deinstallieren. Nach der Deinstallation ist noch das Bereinigungs-Tool von Avira zu verwenden.
https://www.avira.com/de/download/product/avira-registry-cleaner
In dieser Zeit übernimmt der Windows Defender den Schutz (völlig ausreichend).

Übrigens: die ntoskrnl.pdb ist bei mir auch nicht vorhanden, wird aber auch nur zum Debuggen benötigt.


Nachtrag:
In den Sysinfo der Dumpfiles wird eine Onboard-Grafikeinheit ausgewiesen
Diese ist eingeschaltet. Außerdem ist laut deinem "Mein System" ein Grafikkarte ( NVIDIA GeForce GTX 1070) eingebaut.
Manchmal kommt es zwischen beiden Grafiklösungen zu Problemen. Kannst du mal im BIOS die Onboard-Grafik abschalten?

Die 2-Stunden-Regel, die hier im Forum üblich ist, ist abgelaufen, deshalb ein neues Fenster.

Die eigentliche Frage (Benötige dringend Hilfe zu ntoskrnl.pdb ) wurde noch nicht erschöpfend beantwortet.
Deshalb diese Update:
Die Datei ntoskrnl.pdb korrespondiert mit ntoskrnl.exe. Allerdings ist in den Dateieigenschaften zu lesen, dass der originale Name ntkrnlmp.exe ist. Und genau diese Datei ist gemäß der Modulliste geladen. Und für diese ntkrnlmp.pdb ist auch die zugehörige Symboldatei geladen.
Wir fragen den Debugger, was diese Modul nt ist
Da ntoskrnl.exe im Speicher auf ntkrnlmp.exe verweist und eigentlich beide identisch sind, gibt es nur für die originale Datei ntkrnlmp.exe eine Symboldatei, nicht aber für ntoskrnl.exe.
Eventuell wurde die Datei ntkrnlmp.exe von einem Programmierer erweitert und erhielt dadurch den Namen ntoskrnl.exe.
Ich vermute das nur, ich weiß es nicht genau.

In c:\Windows\System32 sind sowohl ntoskrnl.exe als auch ntkrnlmp.exe vorhanden. Und wenn man die Dateieigenschaften auf dem TAB Details anschaut, wird diese Namensbeziehung angezeigt.

Ich hoffe, ich konnte ein bisschen Unklarheit beseitigen.

Wie ich aber schon in meiner vorhergehenden Antwort schrieb, wird dies Symboldatei ntoskrnl.pdb nur im Debugger benötigt und wird nie einen Systemfehler verursachen.

PDB-Dateien gibt es nur innerhalb des Debuggers, ohne macht es keinen Sinn. Wenn WinDbg das nicht laden kann, hat es keine Internetzugriff oder der Dump ist Schrott, sagt es dir aber auch. WinDbg komplett runter und neu drauf.

@.Bernd, ich glaube, du hast #5 nicht gelesen.
Es geht nicht um PDB-Dateien allgemein, sondern um genau diese eine PDB-Datei.
Und da ntoskrnl.exe die gleiche Datei ist, wie ntkrnlmp.exe, gibt es eben nur diese eine PDB-Datei, ntkrnlmp.pdb.
Wegen einer Datei, die es nicht gibt, brauch man keinen Debugger neu installieren.

Und wenn man die Umgebungsvariable "_NT_SYMBOL_PATH" korrekt gesetzt hat, muss man sich nicht um den manuellen Download der Symboldateien kümmern. Der Debugger (selbst WinDbg Preview) läd dann die Symboldateien immer selbstständig nach, wenn sie sich geändert haben.

Und da ntoskrnl.exe die gleiche Datei ist, wie ntkrnlmp.exe

Zum Vergrößern anklicken....

Mag ja sein. Aber

In c:\Windows\System32 sind sowohl ntoskrnl.exe als auch ntkrnlmp.exe

Zum Vergrößern anklicken....

Gibt es hier nicht. ntkrnlmp.exe als auf ntkrnlmp.pdb existieren hier nur im Debugger.
Und das ist der Windows 10 Debugger unter Win8.1. Ich schau gerne noch mal unter win10 nach...
Und wie Alex schreibt, hat der Debugger auch hier keinerlei Probleme damit.

Win10 x64 - ntoskrnl.exe ja, aber kein pdb, ntkrnlmp.exe nein, pdb ja.

Ich hab in "Localsymbols" nur die Ntkrnlmp.pdb vorliegen.

Erstmal Danke für die Mühe!

1. Nachdem ich "Driver Verifier" ausgeführt hatte, habe ich mein System neu gestartet. Der erkannte fehlerhafte Treiber von Avira brachte mich daraufhin zu einem ständigen Bluescreen, den ich nicht mal durch den Abgesicherten Modus / Netzwerktreiber aktiviert und auch nicht durch das deaktivieren beim Start von jeglicher Antivierensoftware umgehen konnte. Immerhin konnte ich im WinRE auf die Option mit der 'Image Wiederherstellung' auf die Festplatten und Dateien zugreifen, denn ich habe mir gedacht, wenn nur ein Treiber gefunden wurde, dann kann ich den sicherlich auch aus dem System ziehen, um wieder ins Windows zu gelangen. Ich habe also den Treiber aus dem System auf einen USB-Stick gezogen und dann kam ich auch wieder ins Windows. Seltsamerweise lief mein System danach sehr sehr Träge - Im TaskManager war die System Auslastung (Datenträgerauslastung) schon rötlich gefärbt. - auch hier war dann die Systemstabilität im Eimer und der PC hatte die darauffolgenden Male das Problem, dass er sogar beim Hochfahren oder Neu starten abstürzte.
Ich habe vor all diesen Tätigkeiten/Lösungsversuche extra Wiederherstellungspunkte erstellt. Somit konnte ich dieses Problem wieder rückgängig machen.

Das Problem mit ntoskrnl.exe bzw. ntoskrnl.pdb entstand an dem Abend als ich einen Avira-Scan laufen ließ. Als der Avira-Scan gerademal 1 Minute lang lief, habe ich einen einzigen Klick in einem Browser-Fenster getätigt und daraufhin stoppte das System umgehend. Es gab keine Soundverzerrungen, etc, sondern einfach nur den "abrupten Stopp" des Systems. - Das war, was dem ersten System-Stopp angehörte.

- Die erstmals generierte Minidump Datei zu diesem Problem hänge ich noch mit an (Die Minidump Datei wurde noch ein paar Stunden vor dem allerersten 1ten System-Stopp generiert (dieser passierte glaub ich c.a 21:00 Uhr).


2. Zu dem Problem mit "dxgkrnl.sys":
Was ich daraufhin unternommen habe, weiß ich leider nicht mehr (außer weitere Versuche des Debuggens). Bedeutet es zum einen, dass ich DirectX 11 neu installieren sollte + hierzu debuggen?


3. Das BIOS hatte ich auch schon im Blickfeld, jedoch habe ich es nie aktualisiert, denn meistens bringen Veränderungen auch neue Probleme mit sich. - Ich wollte hiermit zukünftig sicherstellend vorsorgen. Die Aktualisierung des BIOS scheint keine Treiber-Erneuerungen mit sich zu bringen. 99 % meiner Treiber sind aktuell, aber 1 % betreffen das BIOS Update.

- Wäre es dein Rat, das ich das BIOS aktualisiere, selbst wenn es wahrscheinlich nicht ausschlaggebend für das Problem mit ntoskrnl.pdb ist?


Wie ist das letztendlich zu verstehen mit der ntoskrnl.pdb? Ist diese Datei mehr oder weniger "nachtragend" (hinterherhinkend/Anschluss verloren) via ntoskrnl.exe und deswegen letztendlich das Problem meiner Instabilität? Weil wenn die Datei nur etwas mit dem Debugger selbst zu tun hat, wie kann es dann sein dass sie nicht vorhanden ist, aber so etwas derartiges im System verursacht? - Die Symbolpakete und der Microsoft-Symbolserver sagen scheinbar "Nein".


4. Zum Nachtrag:
Ich denke mal, dass die Onboard-Grafikeinheit deswegen hin und wieder aktiv ist, aus Gründen der Sparsamkeit (wegen Strom,etc). Da die GTX 1070 bis zu 180 Watt braucht.
Ich hatte derzeit auch nur ein einziges mal kurz das Problem, das der Grafikkartentreiber für die GTX 1070 schlapp machte, aber das war nur für den Bruchteil einer Sekunde und einmalig.
Ich weiß nicht ob es die Option überhaupt in meinem alten BIOS gibt, um die Onboard Grafikkarte zu deaktivieren und ob das klug wäre, weiß ich auch nicht (Zur not, habe ich noch 4 Grafikkarten und einen weitern PC übrig).

- Kannst du auch auslesen, wie häufig es zwischen den beiden Grafikprozessoren zur problematischen Grafiklösung kommt?


Vielen Dank für die Unterstützung!
LG.

Minidump: Anhang anzeigen 011418-46000-01.zip

Guten Abend,

aber wenn es die Datei nicht gibt (oder vielleicht nicht mehr), warum verlangt mein System dann danach?
Jedoch besitze ich die ntkrnlmp.pdb.

Wenn du weisst, wieso dein Windows überhaupt danach verlangt, hast du evtl auch die Lösung, warum es dir fehlt.
Deswegen meinte ich Deinstallieren.

Mein Debugger läuft in Sandboxie, daher vom System entkoppelt.

Die PDB liegen in Unterordnern:
C:\Program Files\Windows Kits\10\Debuggers\x86\sym\ (bzw auch \x64\sym\)

Sorry, aber wer verlangt nach dieser Datei?
PDB-Dateien sind Symboldateien, die ausschließlich im Debugger verwendet werden. Sie kann also auf dein System keinen Einfluss haben.
Und nicht mal in den 5 Dumpfiles, die du in #1 bereitgestellt hast, wird diese Symboldatei angemahnt. Warum sollte sie auch angemahnt werden. Wie ich in #5 gezeigt habe, ist ntoskrnl.exe ein "Abkömmling" von ntkrnlmp.exe. Und da der Debugger weiß, dass diese Abhängigkeit besteht, nimmt er mangels einer ntoskrnl.pdb eben die originale ntkrnlmp.pdb

Zum Grafik-Problem
In den Dumpfiles ist nur zu sehen, dass es Probleme mit dem Grafiktreiber gibt. Wie oft dabei eine Wechselwirkung zwischen Grafikkarte und Onboardgrafik die Ursache war, kann ich nicht sehen. Ich habe es nur vermutet, weil es gelegentlich diese Probleme gibt.

Zum BIOS
Wenn in 2 Jahren 5 BIOS-Updates erscheinen und davon bei den drei letzten die System-Stabilität verbessert wurde, dann musst du schon selbst entscheiden, ob du das neueste BIOS benötigst.

@.Bernd
Wenn man sich an die Empfehlung von MSN hält liegt der Symbolordner in C:\Symbols

Hallo

Für mich hört sich das ganz stark nach immer noch vorhandenen Überprüfungs- Einstellungen des Treiberüberprüfungsmanager(DRIVER_VERIFIER) an.
Die Einstellungen die man damit vornimmt, bleiben auch nach einem Neustart des Systems erhalten.

Mit dem Verifer simuliert man dem System Höchstbelastungen auf Treiber.Für Entwickler oder Programmierer hilfreich,fehlerhafte Treiber zu optimieren.

Wenn man die Standart Einstellungen des Systems wiederherstellen will, muss man direkt im Verifer die zuvor vorgenommenen Änderungen wieder löschen.(Siehe Bild) ansonsten läuft das System mit höherer Belastung auf Treiber weiter.



Könnte das auf dein System zutreffen ?

Guten Abend,

ich habe DirectX 11 überprüft sowohl auch einen älteren Grafiktreiber installiert, als es diese Probleme noch nicht gab. Am Grafikkartentreiber kann's eigentlich nicht liegen. Den Onboard Grafikchip konnte ich bisher noch nicht deaktivieren.

Ich habe AVIRA ebenfalls mal komplett deinstalliert, daraufhin funktionierten dann mal die StressTest's für den RAM, aber das glückte nur für kurze Zeit. Denn immer beim zweiten Anlauf des RAM StressTest passierte wieder der System-STOPP.

Was mir außerdem noch aufgefallen war, ich wollte mal die MEMORY.DMP (und einige andere Dateien aus dem System) auf eine externe Festplatte kopieren und siehe da, das System stoppte beim kopieren der Datei "MEMORY.DMP", also dachte ich das Problem gefunden zu haben.
Ich habe die MEMORY.DMP dann mal gelöscht und schon war das Problem mit dem System-STOPP für einige Stunden Geschichte. Jedoch kam der STOPP heute wieder, sprich es wurden wieder neue MEMORY.DMP's geschrieben. - die dafür verantwortlich zu sein scheinen.

Frage: Kann man das schreiben von MEMORY.DMP irgendwie über CMD oder sonst deaktivieren?

ich habe bereits ein Update des BIOS vorgenommen. Wie zu erwarten, gab es dadurch keine Verbesserungen/Unterschiede. Das System wird immer noch im Betrieb gestoppt.
Könnte die ganze Sache mit "ntoskrnl.pdb" vielleicht doch ein harter Virus sein, den ich nicht aufspüren konnte - wäre das ganze realistisch? - Welchen Schutz empfiehlt ihr mir?

Ich habe mal noch Screenshots gemacht. Ich lese hier etwas von SINGLE_DPC_TIMEOUT_EXCEEDED und WIN8_DRIVER_FAULT. - Liegt hier Rätsels Lösung?






ICH DANKE EUCH ALLEN FÜR DIE UNTERSTÜTZUNG UND ANTWORTEN!

LG.

Ich möchte mich nicht ständig wiederholen. Zu dem Problem der *.PDB-Dateien lies noch mal die Antworten #5 und #14.
Wenn du keinen Debugger installiert hättest, gäbe es auch keine PDB-Dateien auf deinem Rechner.

Dateien vom Typ DMP enthalten Fehlerprotokolle (ganz allgemein gesagt).
Memory.dmp und Minidump.dmp enthalten Informationen zu einem Windows-Stoppfehler, in der Hauptsache den Speicherinhalt.
Es ist also keine gute Idee, das Schreiben von *.DMP-Dateien zu unterbinden. Dann kann man keine Fehler mehr verfolgen und der Debugger wird sinnlos.
Eine Memory.dmp ist niemals an Abstürzen oder anderen System-Instabilitäten schuldig.
Die Screenshots hättest du dir sparen können. Was sollen wir mit einem Bild vom Debugger-Protokoll-Schnipsel anfangen, zumal der Debugger wahrscheinlich ohne die notwendigen Symboldateien läuft.

Das Debuggen ist kein Selbstlauf. Starten - Fehler ablesen - System läuft wieder funktioniert nicht. Man muss schon wissen, was der Debugger macht und was seine Anzeigen bedeuten.
Überlasse das Debuggen erst mal denen, die etwas davon verstehen und besorge dir erst mal Literatur um dich in die Problematik ein zu arbeiten.


Die Auswertung der letzten 5 Dumpfiles haben wir dir schon in #2 und #4 geschrieben.
Da du keine neuen Dumpfiles hoch geladen hast, hat sich auch an diesen Auswertungen nichts geändert.

Und eine Frage ist noch unbeantwortet:
In #14 schrieb ich als 1. Satz

Sorry, aber wer verlangt nach dieser Datei?

Zum Vergrößern anklicken....

Windows selbst auf keinen Fall, weil es im normalen Windows die PDB-Dateien gar nicht gibt.

Gute Neuigkeiten,

das Problem ist gelöst!!!


Ich habe mir vor ein paar Tagen Windows 8.1 auf einen USB-Stick geladen.
Da meine Windows 8 CD/DVD nicht Windows 8.1 enthielt, konnte es mein System auch nicht Reparieren, als ich von der CD/DVD bootete, daher stand im Protokoll der Reparatur folgendes: "Die Betriebssystemversion ist inkompatibel mit der Starthilfe."

Aber die Windows Version auf dem USB-Stick war 8.1 und konnte die Reparatur durchführen: "e:\windows\system32\ntoskrnl.exe" ist beschädigt.
Ergebnis: Erfolgreich abgeschlossen.

Noch mal insbesondere Danke an Ari45!! Und alle anderen!
LG.