Die Kerne Dump sollte hier liegen: C:\Windows\Memory.dmp
Ansonsten einstellen kann man das in der alten Systemsteuerung:
System->Erweiterte Systemeinstellungen->Starten- und Wiederherstellen.
Herunterfahren PC lässt sich nicht ausschalten
#16
geschrieben 30. März 2018 - 15:57
Ich bin kein Toilettenpapier-Hamster.
---
Ich bin ein kleiner, schnickeldischnuckeliger Tiger aus dem Schwarzwald.
Alle haben mich ganz dolle lila lieb.
---
Ich bin ein kleiner, schnickeldischnuckeliger Tiger aus dem Schwarzwald.
Alle haben mich ganz dolle lila lieb.
Anzeige
#17
geschrieben 30. März 2018 - 17:03
Leider an dieser Stelle nichts zu finden, oder muss ich vorher nochmal einen "Absturz" herbeiführen?
#18
geschrieben 30. März 2018 - 17:09
Eigentlich nicht. Wenn alles bereits aktiviert war, sollte es auch eine Dump Datei geben. Lt. Deinen Screenshots hat er da ja was gemacht (0% - 100%). Also irgendwo muss es da eine *.dmp geben.
Ich bin kein Toilettenpapier-Hamster.
---
Ich bin ein kleiner, schnickeldischnuckeliger Tiger aus dem Schwarzwald.
Alle haben mich ganz dolle lila lieb.
---
Ich bin ein kleiner, schnickeldischnuckeliger Tiger aus dem Schwarzwald.
Alle haben mich ganz dolle lila lieb.
#19
geschrieben 30. März 2018 - 17:48
Klingt logisch. Habe den kompletten PC nach *.dmp durchsucht. Keine einzige gefunden,die zum Problem Relevanz haben könnte. Aus 2018 gibt es nur eine, die sich in AppData befindet und Microsoft Photos als Bezug aufweist.
#20
geschrieben 30. März 2018 - 17:52
Das ist mysteriös. Und doof.
Hast Du das in der Systemsteuerung wirklich mal überprüft, ob dort die Einstellungen passen und welcher Pfad da angegeben ist.
Hast Du das in der Systemsteuerung wirklich mal überprüft, ob dort die Einstellungen passen und welcher Pfad da angegeben ist.
Ich bin kein Toilettenpapier-Hamster.
---
Ich bin ein kleiner, schnickeldischnuckeliger Tiger aus dem Schwarzwald.
Alle haben mich ganz dolle lila lieb.
---
Ich bin ein kleiner, schnickeldischnuckeliger Tiger aus dem Schwarzwald.
Alle haben mich ganz dolle lila lieb.
#22
geschrieben 30. März 2018 - 18:10
Ja, das sieht eigentlich richtig aus.
Er solle unter %SystemRoot% die Memory.dmp anlegen (%SystemRoot% = C:\Windows).
Oder ist Deine Auslagerungsdatei zu klein. In dem Falle kann so ein Dump nicht erstellt werden.
Oder verschiebt Windows 10 jetzt die Dumps gleich in dern WER Ordner:
C:\ProgramData\Microsoft\Windows\WER
C:\Users\<Benutzername>\AppData\Local\Microsoft\Windows\WER
Aber bis jetzt waren die eigentlich immer in C:\Windows bzw C:\Windows\Minidump.
Er solle unter %SystemRoot% die Memory.dmp anlegen (%SystemRoot% = C:\Windows).
Oder ist Deine Auslagerungsdatei zu klein. In dem Falle kann so ein Dump nicht erstellt werden.
Oder verschiebt Windows 10 jetzt die Dumps gleich in dern WER Ordner:
C:\ProgramData\Microsoft\Windows\WER
C:\Users\<Benutzername>\AppData\Local\Microsoft\Windows\WER
Aber bis jetzt waren die eigentlich immer in C:\Windows bzw C:\Windows\Minidump.
Ich bin kein Toilettenpapier-Hamster.
---
Ich bin ein kleiner, schnickeldischnuckeliger Tiger aus dem Schwarzwald.
Alle haben mich ganz dolle lila lieb.
---
Ich bin ein kleiner, schnickeldischnuckeliger Tiger aus dem Schwarzwald.
Alle haben mich ganz dolle lila lieb.
#23
geschrieben 30. März 2018 - 18:56
Inzwischen muss es, in einer kurzen Abwesenheit, einen Crash gegeben haben. Mit Crash Dump Analysis gab es einen Report:
Auch in C:\ProgramData\Microsoft\Windows\WER habe ich etwas gefunden:
Eine halbe Stunde später ist der PC woh erneut abgestürtzt, jedoch im ausgeschalteten Zustand verblieben. Nach dem Neustart die folgende Crash Dump Analyse:
Auch in C:\ProgramData\Microsoft\Windows\WER habe ich etwas gefunden:
Eine halbe Stunde später ist der PC woh erneut abgestürtzt, jedoch im ausgeschalteten Zustand verblieben. Nach dem Neustart die folgende Crash Dump Analyse:
Dieser Beitrag wurde von rolli bearbeitet: 30. März 2018 - 20:47
#24
geschrieben 31. März 2018 - 12:29
Da steht jetzt so auch nicht weiter neues drin, jedenfalls nicht der Name des Treibers. Auswerten kann man nur folgendes:
2x BSOD 0x9f (DRIVER_POWER_STATE_FAILURE) mit zwei unterschiedlichen Gründen:
1x BSOD 0x1E (KMODE_EXCEPTION_NOT_HANDLED) mit dem Fehler
Hilft alles nicht so wirklich weiter und dass die ntoskrnl.exe daran schuld sein soll, ist meistens auch nicht der Fall. Si ist halt meistens das oberste Opjekt im STack, weil die auch mit der Erstellung des BSODs zu tun hat. Der Verursacher ist im Stack meistens viel weiter hinten.
Aber dort steht jedenfalls, dass es eine C:\Windows\Minidump\*.dmp gibt.
Allerdings ob die weiter hilft, ist schwer zu sagen. Für beide Fehler wäre eine Kerneldump besser. Aber man kann erst einmal mit der Minidump anfangen und mal schauen.
2x BSOD 0x9f (DRIVER_POWER_STATE_FAILURE) mit zwei unterschiedlichen Gründen:
- A device object has been blocking an IRP for too long a time.
- The power state transition timed out waiting to synchronize with the PnP subsystem.
1x BSOD 0x1E (KMODE_EXCEPTION_NOT_HANDLED) mit dem Fehler
- STATUS_ACCESS_VIOLATION
Hilft alles nicht so wirklich weiter und dass die ntoskrnl.exe daran schuld sein soll, ist meistens auch nicht der Fall. Si ist halt meistens das oberste Opjekt im STack, weil die auch mit der Erstellung des BSODs zu tun hat. Der Verursacher ist im Stack meistens viel weiter hinten.
Aber dort steht jedenfalls, dass es eine C:\Windows\Minidump\*.dmp gibt.
Allerdings ob die weiter hilft, ist schwer zu sagen. Für beide Fehler wäre eine Kerneldump besser. Aber man kann erst einmal mit der Minidump anfangen und mal schauen.
Ich bin kein Toilettenpapier-Hamster.
---
Ich bin ein kleiner, schnickeldischnuckeliger Tiger aus dem Schwarzwald.
Alle haben mich ganz dolle lila lieb.
---
Ich bin ein kleiner, schnickeldischnuckeliger Tiger aus dem Schwarzwald.
Alle haben mich ganz dolle lila lieb.
#26
geschrieben 31. März 2018 - 14:32
Als Zip packen und hier anhängen! Die Ansicht in Deinem Minidump Ordner nutzt niemandem was.
#27
geschrieben 31. März 2018 - 17:39
Die beiden geposteten Dateien sind nach einem Crash in meiner Abwesenheit vom PC nach dem Neustart verschwunden. Anbei die neueste .dmp Datei
Sorry, war die falsche.
Sorry, war die falsche.
Angehängte Datei(en)
-
033118-26734-01.dmp (618,18K)
Anzahl der Downloads: 40
#28
geschrieben 31. März 2018 - 18:30
Hättest auch beide lassen können. Je mehr Dumps, desto besser.
Dieses Mal hat er wenigstens den IRP gespeichert, so dass man auf das DRIVER_OBJECT zugreifen kann. Das macht Windows 10 seltsamer Weise nicht immer.
Das Ganze hängt mit dem virtuellen Netzwerk von Virtiual Box zusammen:
VBoxNetAdp6.sys - VirtualBox NDIS6 Miniport Driver
Der scheint da irgend ein Problem zu haben. Eventuell mal Updaten, falls Du nicht schon auf Version 5.2.8 von VirtualBox bist.
---
Fällt natürlich auch hier auf, dass Du noch Windows Build 16299.309 installiert hast, obwohl altuell wäre es 16299.334. Ist jetzt wieder die Frage, warum nicht alle das Update KB4089848 bekommen haben.
Der jetzige Dump (033118-26734-01.dmp): DRIVER_POWER_STATE_FAILURE (9f) Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time ... ... FAULTING_MODULE: fffff80f26850000 VBoxNetAdp6
Dieses Mal hat er wenigstens den IRP gespeichert, so dass man auf das DRIVER_OBJECT zugreifen kann. Das macht Windows 10 seltsamer Weise nicht immer.
Das Ganze hängt mit dem virtuellen Netzwerk von Virtiual Box zusammen:
VBoxNetAdp6.sys - VirtualBox NDIS6 Miniport Driver
Der scheint da irgend ein Problem zu haben. Eventuell mal Updaten, falls Du nicht schon auf Version 5.2.8 von VirtualBox bist.
---
Fällt natürlich auch hier auf, dass Du noch Windows Build 16299.309 installiert hast, obwohl altuell wäre es 16299.334. Ist jetzt wieder die Frage, warum nicht alle das Update KB4089848 bekommen haben.
Ich bin kein Toilettenpapier-Hamster.
---
Ich bin ein kleiner, schnickeldischnuckeliger Tiger aus dem Schwarzwald.
Alle haben mich ganz dolle lila lieb.
---
Ich bin ein kleiner, schnickeldischnuckeliger Tiger aus dem Schwarzwald.
Alle haben mich ganz dolle lila lieb.
#29
geschrieben 01. April 2018 - 10:22
Zunächst "Frohe Ostern"
Habe nach Empfehlung win10 upgedatet und auch die neueste Version von Virtual Box installiert. Keine Besserung. Anbei die neuesten dmp files:
Im Gerätemanager erscheinen unbekannte Geräte, bei denen eine Treiberaktualisierung fehlschlägt.
Die Geräte haben die Bezeichnung ROOT\NET\0001 und ROOT\NET\0002 Die "Eigenschaften" füge ich hier dazu:
Habe nach Empfehlung win10 upgedatet und auch die neueste Version von Virtual Box installiert. Keine Besserung. Anbei die neuesten dmp files:
Im Gerätemanager erscheinen unbekannte Geräte, bei denen eine Treiberaktualisierung fehlschlägt.
Die Geräte haben die Bezeichnung ROOT\NET\0001 und ROOT\NET\0002 Die "Eigenschaften" füge ich hier dazu:
Angehängte Datei(en)
-
033118-27796-01.dmp (604,29K)
Anzahl der Downloads: 40 -
040118-28312-01.dmp (585,2K)
Anzahl der Downloads: 25
#30
geschrieben 01. April 2018 - 10:49
Für 033118-27796-01.dmp reicht die Minidump wieder nicht aus:
Also keine Information zum Treiber oder Gerät vorhanden. Hier bräuchte man dann eine Kernel Dump. Das Selbe gilt auch für 040118-28312-01.dmp.
Bei den unbekannten Geräten, was steht denn unter Hardware ID? Bei Google-Suche landet man meistens bei OpenVNP.
1: kd> !drvobj fffff802209e3ef0: Unable to get value of ObpRootDirectoryObject fffff802209e3ef0: Unable to get value of ObpRootDirectoryObject Driver object not found ... ... 1: kd> !pnptriage Error retrieving value of nt!PnpEnumerationRequestList Error reading value of nt!PnpDeviceEventList (0x17676048)
Also keine Information zum Treiber oder Gerät vorhanden. Hier bräuchte man dann eine Kernel Dump. Das Selbe gilt auch für 040118-28312-01.dmp.
Bei den unbekannten Geräten, was steht denn unter Hardware ID? Bei Google-Suche landet man meistens bei OpenVNP.
Ich bin kein Toilettenpapier-Hamster.
---
Ich bin ein kleiner, schnickeldischnuckeliger Tiger aus dem Schwarzwald.
Alle haben mich ganz dolle lila lieb.
---
Ich bin ein kleiner, schnickeldischnuckeliger Tiger aus dem Schwarzwald.
Alle haben mich ganz dolle lila lieb.