Anzeige
Anzeige

Am Puls von Microsoft

Anzeige

Rechner stürzt im Ruhezustand ab

P

PeteM92

gehört zum Inventar
Hallo,

Ich versetze meinen Laptop (siehe Mein System) bei Nichtgebrauch meist in den Ruhezustand - so 4-5-6 mal pro Tag.
Danach schalte ich den Laptop mit dem Netzschalter ein und kann nach wenigen Sekunden weiterarbeiten.

Alle paar Tage läßt er sich nicht mehr mit dem Netzschalter reaktivieren.
Dabei wird der Rechner im Ruhezustand heiß, der Lüfter läuft auf vollen Touren und ich muß den Netzschalter für ein paar Sekunden drücken, um den Laptop abzuwürgen.
Anschließend läßt er sich ganz normal wieder neu booten (wie bei einem Neustart).

Heute habe ich dabei eine Datei 092518-10125-01.dmp im Ordner c:\windows\minidump gefunden, die wurde offensichtlich (Datum und Uhrzeit) erstellt, als ich den Rechner abgewürgt und gleich anschließend neu gestartet habe (nach ca. 2 Stunden im Ruhezustand).

Kann da mal bitte jemand reinschauen, ob sich eine Ursache finden läßt? (siehe Anhang)

Es wurde zeitgleich auch eine Datei Memory.dmp im Verzeichnis c:\windows gefunden Dateigröße knapp unter 1 GByte. Die bekomme ich auch gezippt nicht hier hochgeladen.

PS: Windows ist aktuell, BIOS und Treiber gibt es auch nichts neueres. Wecker oder ähnliches, die den Laptop aufwachen lassen könnten, habe ich wissentlich nichts eingestellt.
 

Anhänge

  • 092518-10125-01.zip
    354,8 KB · Aufrufe: 46
Anzeige
Hallo Pete!
Ich habe die Dumpfile herunter geladen. Zum Debuggen komme ich aber erst so etwa in 2 Stunden, weil ich gleich "Fahrdienst" für meine bessere Hälfte habe.

Die Memory.dmp muss man über einen File-Hoster oder über deine Cloud zur Verfügung stellen und uns den Link dazu bekannt geben.

Schon mal ein Frage vorab: hast du ein Multiboot-System (zB Win 7 und Win 10)? Das ist sehr oft die Ursache für solches Verhalten.
 
Hallo Aribert,

prima, daß du draufschauen willst - es eilt nicht.
Mulitboot habe ich nicht. Ich benutze für andere Systeme VMware.
Ich habe 2 Memory.dmp´s, die werde ich mal in eine meiner Clouds hochladen

Grüße Pete

Nachtrag:
Hier 2 Links auf die Dateien Memory.dmp. Datum habe ich in Dateinamen eingehängt, Dateigrößen ca. 900 MByte)
Memory_2018-09-25.dmp
Memory_2018-09-22.dmp
 
Zuletzt bearbeitet:
Hallo Pete!
Da bin ich wieder. Dieses Mal machte das Debuggen sogar etwas Spass, weil die Adressen in den Bugcheck-Parametern zu Ergebnissen führten.
Noch mal zum Verständnis meiner Auswertung: meine Kommentare füge ich in grün ein. Stellen, denen ich besondere Aufmerksamkeit schenke, markiere ich mit rot.
DRIVER_POWER_STATE_FAILURE (9f) // ein Treiber spielt verrückt
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: ffffe70bc81cd060, Physical Device Object of the stack // damit kann das Gerät ermittelt werden
Arg3: fffffa0c296298d0, nt!TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
Arg4: ffffe70bd2027940, The blocked IRP // dieser Parameter gibt Auskunft über den Treiber
...
PRIMARY_PROBLEM_CLASS: 0x9F_3_POWER_DOWN_tcpip!FlpWaitForMiniportToReturnTransmittedPackets
// den Stack brauchen wir dieses Mal nicht, dafür mit Bugcheck-Parameter 4 die IRP-Liste abfragen
!irp ffffe70bd2027940
Irp is active with 5 stacks 3 is current (= 0xffffe70bd2027aa0)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace.
cmd flg cl Device File Completion-Context
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000
>[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
Der Haken > wurde von Debugger gesetzt,da das der blockierte IRP ist
0 0 ffffe70bcb9b7050 00000000 00000000-00000000
// das ist die Adresse des DeviceOblect
Unable to load image \SystemRoot\System32\drivers\Netwbw02.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for Netwbw02.sys
*** ERROR: Module load completed but symbols could not be loaded for Netwbw02.sys
\Driver\NETwNb64 Args: 00015500 00000000 00000005 00000003
[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
0 e1 ffffe70bcb985830 00000000 fffff8033da853c0-ffffe70bd1ce8770 Success Error Cancel pending
\Driver\vwifibus nt!PopSystemIrpCompletion Args: 00015500 00000000 00000005 00000003
// der Treiber NETwNb64.sys blockiert diesen IRP
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-ffffe70bd1ce8770 Args: 00000000 00000000 00000000 00000000
.....
// das DeviceObject ermitteln
!devobj ffffe70bcb9b7050
Device object (ffffe70bcb9b7050) is for:
InfoMask field not found for _OBJECT_HEADER at ffffe70bcb9b7020
\Driver\NETwNb64 DriverObject ffffe70bcb8dd740
Current Irp 00000000 RefCount 0 Type 00000017 Flags 00002050
SecurityDescriptor ffffa483676fdb60 DevExt ffffe70bcb9b71a0 DevObjExt ffffe70bcb9b88d8
ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
Characteristics (0x00000100) FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) ffffe70bcb985830 \Driver\vwifibus
AttachedTo (Lower) ffffe70bc81ce530 \Driver\ACPI
Device queue is not busy.
// Die Geräte-Queue ist nicht beschäftigt, der Treiber hängt.
Beim Abfragen des GeräteObjekts wird noch mal bestätigt, dass NETwNb64 der Auslöser ist. Die Hierarchie-Kette geht von ACPI.Sys über VWifibus.sys nach NETwNb64

Jetzt noch mal mit dem Parameter 2 des BugcheckCode das Geräteobjekt abfragen.
!devobj ffffe70bc81cd060 // Parameter 2
Device object (ffffe70bc81cd060) is for:
Cannot read info offset from nt!ObpInfoMaskToOffset
\Driver\pci DriverObject ffffe70bc81e0280
Current Irp 00000000 RefCount 0 Type 00000022 Flags 00001040
SecurityDescriptor ffffa483676fdb60 DevExt ffffe70bc81cd1b0 DevObjExt ffffe70bc81cd7f0 DevNode ffffe70bc81cdd20
ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
Characteristics (0x00000100) FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) ffffe70bc81ce530 \Driver\ACPI
Device queue is not busy.
......
// mit DevNode kann eine zweite Bestätigung des Verursachers erlangen
1: kd> !devnode ffffe70bc81cdd20
DevNode 0xffffe70bc81cdd20 for PDO 0xffffe70bc81cd060
Parent 0xffffe70bc81c6d20 Sibling 0000000000 Child 0xffffe70bcf5a1010
InstancePath is "PCI\VEN_8086&DEV_08B1&SUBSYS_44608086&REV_73\4&2d7cc356&0&00E2"
// mit dieser Information im Internet suchen
ServiceName is "NETwNb64"
State = DeviceNodeStarted (0x308)
also mit dem Wert von DevNode kann man nähere Informationen über den Treiber im Internet erlangen.
Auf dieser Seite
Intel(R) Dual Band Wireless-N 7260 treiber 16.6.0.8
erfährt man, dass es sich um den Intel(R) Dual Band Wireless-N 7260 Treiber 16.6.0.8 handelt.
Nach der Beschreibung gehört der Treiber zu
Microsoft Windows 7 Ultimate Edition Service Pack 1 (build 7601), 64-bit
Es sollte also versucht werden, für diesen Treiber eine neuere Version zu erlangen.

ot:
Diese Dumpfile hat so viel Informationen Preis gegeben, dass ich hier nur vielleicht 10% wiedergeben kann

Nachtrag:
Ich hatte einen kleinen Irrtum eingebaut:
NETwbNb64 ist der Dienstname. Der zugehörige Treiber ist Netwbw02.sys
 
Zuletzt bearbeitet:
Hallo Peter,
nur schon mal vorab, Ruhemodus und Schnellstart sind bei einer SSD kontraproduktiv. Warte aber mal auf @Ari45, die Auswertung zeigt vielleicht in eine andere Richtung.
 
Ich lade mir jetzt eine der beiden Memory.dmp von deiner Cloud herunter. Das ist ein Geduldsspiel. Für 900 MB rund 22 Minuten.
Wenn mal wieder so etwas ist, müssen wir über einen FileHoster versuchen, ob es da schneller geht.
Da der Bettzipfel langsam winkt, wird es heute nichts mehr mit dem Debuggen.
Aber einen Ansatzpunkt hast du ja erst mal.
 
Danke für die Analyse, Aribert

Tut mir leid, daß das Herunterladen zäh läuft. Die Links verweisen auf meine Dropbox, die ich normalerweise aber nur zum Austausch von Bildern zwischen meinen Geräten benutze. Da hier nicht allzugroße Datenmengen anfallen, ist mir nicht aufgefallen, daß das langsam ist. Das Hochladen der beiden Files hat insgesamt 7 Minuten gedauert (bei 10 Mbit/s Uploadgeschwindigkeit).

Ich habe da Treiberanbieter Intel, Treiberdaturm 31.10.2017, Treiberversion 18.33.11.2 installiert.
Da gibt´s von Intel tatsächlich deutlich neuere Versionen, Datum 11.9.2018, Version 20.80.0

Ich habe mich da wohl zu sehr darauf verlassen, daß die Windows Anzeige stimmt "Die besten Treiber sind bereits installiert" und auch auf der Dell-Seite gibt´s keine neuere Version.

Ich werde mal noch abwarten, was die weitere Auswertung ergibt, und dann die Treiber von der Intel-Seite installieren und weiter beobachten.


Nachtrag:
ich habe mittlerweile diesen neuen Treiber installiert - leider funktioniert damit mein WLAN überhaupt nicht. Eine interessante Erfahrung am Rande: Ich dachte, kein Problem, und habe die Windos-Systemwiederherstellung gestartet. Dabei mußte ich erfahren, daß die Systemwiederherstellung mit ca. 10 Minuten deutlich länger dauert als das Recovery der gesamten Systempartition mit meinem Backup-Programm (ca. 7 min).
Weiteres Problem: der installierte Treiber war neuer als der von der Dell-Seite erhältliche. Der Dell-Treiber ließ sich dadurch nicht installieren. Also Intel-Gerät deaktiviert, Treiber deinstalliert und erneut Dell-Treiber-Installation gestartet. Ergebnis: Fehlermeldung "der Treiber ist nicht geeignet", was meine Zuversicht in Dell etwas erschüttert hat. Allerdings hat Windows-Update jetzt einen älteren Treiber installiert, mit dem ich erst mal arbeiten werde.

Nachtrag 2:
ich habe gerade mal die Downloads getestet. Jedes meiner Files von oben hat so ca. 3 1/2 Minuten zum Herunterladen gebraucht, das läuft mit der maximalen Downloadgeschwindigkeit meiner Internetverbindung (VDSL50, effektiv 40 MBit/s). Die Files sind halt jedes ca. 1 GByte groß.
 
Zuletzt bearbeitet:
Guten Morgen!
Auch in der Memory.dmp vom 25.09.18 werden die gleichen Verdächtigen genannt.
ACPI -> vwifibus -> Netwbw02.sys
Auf dem Stack des letzten Thread ist noch mal zu sehen, dass wirklich der blockierte IRP-Stack die Ursache ist.
# Child-SP RetAddr Call Site
00 fffffa0c`29629898 fffff803`3d880859 nt!KeBugCheckEx
01 fffffa0c`296298a0 fffff803`3d880762 nt!PopIrpWatchdogBugcheck+0xed IRP-Fehler
02 fffffa0c`29629910 fffff803`3d6ecd39 nt!PopIrpWatchdog+0x22 IRP-Überwachung
03 fffffa0c`29629960 fffff803`3d6ebc77 nt!KiProcessExpiredTimerList+0x159
04 fffffa0c`29629a50 fffff803`3d7bbaba nt!KiRetireDpcList+0x4c7
05 fffffa0c`29629c60 00000000`00000000 nt!KiIdleLoop+0x5a Rückkehr aus IDLE

Und hier noch mal der IRP-Stack
irp ffffe70bd2027940
Irp is active with 5 stacks 3 is current (= 0xffffe70bd2027aa0)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace.
cmd flg cl Device File Completion-Context
.... ich habe die leeren IRP-Stacks weg gelassen
>[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
0 0 ffffe70bcb9b7050 00000000 00000000-00000000
*** ERROR: Module load completed but symbols could not be loaded for Netwbw02.sys
\Driver\NETwNb64
Args: 00015500 00000000 00000005 00000003
[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
0 e1 ffffe70bcb985830 00000000 fffff8033da853c0-ffffe70bd1ce8770 Success Error Cancel pending
\Driver\vwifibus nt!PopSystemIrpCompletion
Args: 00015500 00000000 00000005 00000003
Es ist also im Prinzip der gleiche Inhalt, wie bei dem Minidump. Es sind zwar eine Unmenge mehr Informationen, die uns aber nicht weiter bringen. So werden in der Memory.dmp 60 aktive DeviceObjekte aufgelistet, die aber mit dem Stoppfehler nichts zu tun haben.

Wenn das Aktualisieren der beteiligten Treiber nicht zum Erfolg führt, sollte man vielleicht doch mal probieren, ob das Deaktivieren des Ruhemodus das Problem löst, wie @makodako in #5 bereits vorgeschlagen hat..
 
Hallo Aribert,

nochmal vielen Dank für die Analyse.
Ich habe zwischenzeitlich weiter geforscht, Intel(R) Dual Band Wireless-N 7260 deaktiviert und Treiber deinstalliert. Danach hat mir Windows Update einen älteren Treiber als "am besten geeignet" installiert. Das muß ich mal jetzt eine zeitlang beobachten (ist ja etwas schwierig, da das Problem ja, wie in #1 beschrieben, sehr sporadisch auftaucht). Auch Dell werde ich kontaktieren - da sollte schon ein brauchbarer Treiber existieren.

Das Deaktivieren des Ruhezustands mache ich nur äußerst ungern, die Bootzeit meines Rechners aus dem Ausschaltzustand liegt bei 70 s, nach Ruhezustand ist mein Rechner nach 9 s wieder aktiv. Ja ich weiß, jetzt kommt eine Diskussion um die absolut ungenügende Performance beim Booten, aber ich lade da eine ganze Menge "Zeugs", das anderen überflüssig erscheint, mir aber das Arbeiten mit dem Rechner und die Erscheinungsweise angenehmer macht.

Beispiel: ich lade unter anderem ein Programm Winsize2, das nur dazu dient den VMwarePlayer beim Start an einen definierten Platz auf dem Bildschirm zu bringen (im Player ist nämlich ein "Feature" eingebaut, das ihn bei jedem Start an einer anderen zufälligen Position des Bildschirm erscheinen läßt). Ich habe da Bootzeit und Komfort ziemlich eingehend gegeneinander abgewogen und kann mit den Startzeiten aus dem Ruhezustand sehr gut mit dem Rechner leben. Die Startzeit aus dem Energiesparmodus ist nochmal schneller, den benutze ich aber nicht weil ich den Rechner schon auch mal einen Tag ausgeschaltet lasse. Der Energiesparmodus leert mir dann den Akku.

Nochmal vielen Dank, von selbst hätte ich nicht auf den WLAN-Treiber getippt, die Analyse hat mir sehr geholfen.
Ich werde das jetzt mal ein paar Tage beobachten und dann Bescheid geben.
 
Pete, noch ein kleines Nachwort:
Mein Rechner startet, trotz SSD, auch so zwischen 45 und 60 Sekunden.
Aber ich bin den Kompromiss eingegangen, lieber ein stabiles System als einen schnellen Start.
Außerdem lade ich im Autostart (aus Bequemlichkeit) 4 Programme, die nicht unbedingt mit dem System gestartet werden müssen.
So muss jeder für sich selbst Prioritäten setzen.
Bei mir ist es Stabilität (kein Ruhemodus) und Bequemlichkeit.
Bei dir ist es eben schneller Systemstart und sofort zuletzt benutzte Programme aktiv.
Ich denke, da gibt es kein "besser" oder "schlechter", das muss jeder für sich selbst entscheiden.
 
Das neuste Treiberpacket für den Intel 7260-WLAN-Chip ist https://downloadcenter.intel.com/de...ware-und-Treiber-f-r-Windows-10?product=59485. Das hat zwar die Versionsnummer 20.80, diese gilt jedoch nur für den Treiber der neusten Chipgeneration 9XXX und die Zusatzsoftware.

Für den 7260 ist die neuste Version die 18.33.13.4, siehe dazu den Text auf der verlinkten Webseite. Diese ist allerdings auch noch nicht so alt. Der Treiber für die 7260 wurde zuletzt mit dem WLAN-Treiberpaket 20.60 im Juni 2018 aktualisiert.

Falls der Chip auch über Bluetooth verfügt, sollte auf jeden Fall auch der neuste Bluetooth-Treiber installiert werden. https://downloadcenter.intel.com/de...reless-Bluetooth-f-r-Windows-10?product=59485 Der enthält nämlich ein Update gegen eine Sicherheitslücke in Bluetooth.
 
Danke für den Hinweis @build10240,
da hab ich wohl bei meinem Versuch den falschen Download genommen.
Ich schau mir das an.
 
So, ich möchte jetzt fast einen Neustart dieses Themas machen, deshalb auch ein neuer Post.

Ich habe jetzt alle möglichen Treiber, den neuesten von der Intel-Seite und auch ältere und auch einen uralten von der Dell-Seite für meinen Laptop getestet - alles völlig erfolglos.

Aber

eine Beobachtung habe ich dabei gemacht (bei mindestens 2 Dutzend Versuchen):

das Problem tritt reproduzierbar dann auf, wenn ich vorher mit dem Firefox gearbeitet habe (Firefox 62.0.2 mit und ohne Addons, da ich das Problem schon länger habe, ist die Version von Firefox vermutlich irrelevant).

Dabei ist es egal, ob der Firefox noch geöffnet ist oder schon 1 Minute geschlossen ist (länger habe ich nie gewartet). Und es ist noch verrückter - das Problem tritt nur auf, wenn der Firefox als letztes Programm im Internet war. Es tritt nicht auf, wenn ich nach dem Firefox noch Google Chrome oder Outlook aufgerufen habe.

Und um das ganze noch zu toppen: wenn der Taskmanager läuft (der darf nicht minimiert sein), tritt das Problem auch nicht auf.

Ich glaube ja nicht an Voodoo oder irgendeinen anderen Zauber - aber eine vernünftige Erklärung habe ich dafür nicht.

Kann mir einer von Euch dazu was sagen?


Nachtrag:
Das Problem scheint gelöst.
Da hat sich wohl im Laufe der Firefox Updates irgendetwas verheddert. Nachdem ich mein Firefox Profil gesichert, Firefox deinstalliert und neu installiert und mein Profil zurückgesichert habe, scheint sich mein Laptop wieder "brav" zu verhalten.
Jedenfalls konnte ich die Aufhänger nach Benutzung des Firefox nicht mehr reproduzieren.

Nochmal Danke Aribert für Deine Mühen.
 
Zuletzt bearbeitet:
Erneuter Nachtrag:

das Problem tritt nach wie vor auf - die "scheinbare" Lösung hat sich als nicht zutreffend erwiesen.

Ich habe allerdings inzwischen meine Arbeitsweise angepaßt (nach Firefox schließen warte ich jetzt erst mal etliche Sekunden, bis ich den Laptop in den Energiesparmodus schicke). Damit tritt das wesentlich seltener auf.

Noch eine Beobachtung: wenn der Firefox geöffnet bleibt, tritt das Problem auch nicht auf.
Nachdem aber der Firefox der Browser ist, der mir am Besten zusagt, muß ich wohl mit dem Zustand zurechtkommen.
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Anzeige
Oben