Hilfe bei Crashdump-Analyse

[s-g]

Guten Abend,

mir ist soeben mein Rechner auf mysteriöse weise abgeschmiert...
Szenario: Ich hatte den Laptop aus der Docking genommen, damit auf der Couch gesurft bis der Akku zu neige ging und wieder zurück in die Docking gestellt.
Nach ca. 5 Minuten in der Docking, ohne dass ich Ihn in dieser Zeit angefasst hätte, ist er abgeschmiert.
Bluescreen hab ich keinen gesehen, kann aber sein dass er einfach gleich automatisch neu gestartet ist.

Bei besagtem Neustart blieb Windows am Ladeschirm (der mit dem Windowslogo auf schwarzem Grund und dem sich drehenden Kreis darunter) hängen.
Gleiches Spiel als er mit einem langen Druck auf die Power-Taste ausgeschalten und neu gestartet wurde.

Also Akku raus genommen, kurz gewartet, neu gestartet. Jetzt hat er mir an besagten Ladeschirm etwas von wegen "Versuche wiederherstelltung" (sorry, den genauen Text habe ich vergessen) erzählt, passiert ist aber nichts.
Nochmal Akku raus...jetzt läuft er auf einmal wieder einwandfrei.

Vor ca. einem halben Jahr hat er schon mal ähnlichen Blödsinn gemacht.

System:
Windows 8.1 x64.
W520 mit Quadro 2000m und i7-2820qm.
Crucial m4 SSD.
...und ner riesen Ladung externes Zeug an der Docking.

Crashdump habe ich schon ausgelesen, kann aber ehrlich gesagt nicht wirklich was damit anfangen...

Microsoft (R) Windows Debugger Version 6.3.9600.17237 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\Minidump\090414-15093-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available


************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred SRV*C:\symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*C:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 8 Kernel Version 9600 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9600.17238.amd64fre.winblue_gdr.140723-2018
Machine Name:
Kernel base = 0xfffff803`c2a01000 PsLoadedModuleList = 0xfffff803`c2ccb350
Debug session time: Thu Sep 4 04:04:12.839 2014 (UTC + 2:00)
System Uptime: 0 days 17:18:56.716
Loading Kernel Symbols
.

Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.

..............................................................
................................................................
................................................................
.................................
Loading User Symbols
Loading unloaded module list
..............................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000007E, {ffffffffc0000005, fffff8001b249f1f, ffffd0009d96a7c8, ffffd0009d969fd0}

Probably caused by : tdx.sys ( tdx!TdxPnpPowerComplete+25 )

Followup: MachineOwner
---------

0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: fffff8001b249f1f, The address that the exception occurred at
Arg3: ffffd0009d96a7c8, Exception Record Address
Arg4: ffffd0009d969fd0, Context Record Address

Debugging Details:
------------------


DUMP_FILE_ATTRIBUTES: 0xc
Insufficient Dumpfile Size
Kernel Generated Triage Dump

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden.

FAULTING_IP:
tcpip!IpNlpPnpEventCompleteInterface+4b
fffff800`1b249f1f f00fc183784f0000 lock xadd dword ptr [rbx+4F78h],eax

EXCEPTION_RECORD: ffffd0009d96a7c8 -- (.exr 0xffffd0009d96a7c8)
ExceptionAddress: fffff8001b249f1f (tcpip!IpNlpPnpEventCompleteInterface+0x000000000000004b)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000001
Parameter[1]: 000000000001622b
Attempt to write to address 000000000001622b

CONTEXT: ffffd0009d969fd0 -- (.cxr 0xffffd0009d969fd0;r)
rax=00000000fffffffe rbx=00000000000112b3 rcx=e9a4034000d70000
rdx=0000000000000002 rsi=00000000abababab rdi=ffffe001dc36f240
rip=fffff8001b249f1f rsp=ffffd0009d96aa00 rbp=0000000000000001
r8=000000000000082f r9=000000000000002f r10=ffffe001d5c15040
r11=ffffd0009d96a890 r12=fffff8001bde3000 r13=0000000000000000
r14=0000000000000000 r15=00000000efefefef
iopl=0 nv up ei ng nz na po nc
cs=0010 ss=0000 ds=002b es=002b fs=0053 gs=002b efl=00010286
tcpip!IpNlpPnpEventCompleteInterface+0x4b:
fffff800`1b249f1f f00fc183784f0000 lock xadd dword ptr [rbx+4F78h],eax ds:002b:00000000`0001622b=????????
Last set context:
rax=00000000fffffffe rbx=00000000000112b3 rcx=e9a4034000d70000
rdx=0000000000000002 rsi=00000000abababab rdi=ffffe001dc36f240
rip=fffff8001b249f1f rsp=ffffd0009d96aa00 rbp=0000000000000001
r8=000000000000082f r9=000000000000002f r10=ffffe001d5c15040
r11=ffffd0009d96a890 r12=fffff8001bde3000 r13=0000000000000000
r14=0000000000000000 r15=00000000efefefef
iopl=0 nv up ei ng nz na po nc
cs=0010 ss=0000 ds=002b es=002b fs=0053 gs=002b efl=00010286
tcpip!IpNlpPnpEventCompleteInterface+0x4b:
fffff800`1b249f1f f00fc183784f0000 lock xadd dword ptr [rbx+4F78h],eax ds:002b:00000000`0001622b=????????
Resetting default scope

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 0

ERROR_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden.

EXCEPTION_PARAMETER1: 0000000000000001

EXCEPTION_PARAMETER2: 000000000001622b

WRITE_ADDRESS: GetPointerFromAddress: unable to read from fffff803c2d55138
unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSizeOfNonPagedPoolInBytes
000000000001622b

FOLLOWUP_IP:
tdx!TdxPnpPowerComplete+25
fffff800`1bbcf6f5 4883c448 add rsp,48h

BUGCHECK_STR: AV

ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) amd64fre

LAST_CONTROL_TRANSFER: from fffff8001bbcf6f5 to fffff8001b249f1f

STACK_TEXT:
ffffd000`9d96aa00 fffff800`1bbcf6f5 : 00000000`00000000 00000000`00000000 00000000`00000000 fffff800`1e217bc1 : tcpip!IpNlpPnpEventCompleteInterface+0x4b
ffffd000`9d96aa50 fffff800`1bde7f15 : 00000000`00000000 ffffe001`d58b6e00 ffffe001`d8d3a8b0 00000000`00000001 : tdx!TdxPnpPowerComplete+0x25
ffffd000`9d96aaa0 fffff800`1b6452c7 : 00000000`00000000 fffff800`1bde3000 ffffe001`dc36f240 00000000`abababab : TDI!TdiPnPPowerComplete+0x8e
ffffd000`9d96aad0 fffff800`1bde6f44 : fffff800`1bde3000 00000000`00000000 00000000`efefefef ffffe001`dcf6be40 : netbt!NbtPnPPowerComplete+0x17
ffffd000`9d96ab00 fffff803`c2a3da2b : fffff800`1bde56c0 ffffd000`9d96abd0 ffffe001`db7723e0 ffffe001`d8d48740 : TDI! ?? ::FNODOBFM::`string'+0x6fd
ffffd000`9d96ab50 fffff803`c2ada514 : 00000000`00000000 ffffe001`d5c15040 ffffe001`d5c15040 ffffe001`d5018040 : nt!ExpWorkerThread+0x293
ffffd000`9d96ac00 fffff803`c2b5b2c6 : ffffd000`8595c180 ffffe001`d5c15040 ffffe001`dc73d080 006e006f`00720068 : nt!PspSystemThreadStartup+0x58
ffffd000`9d96ac60 00000000`00000000 : ffffd000`9d96b000 ffffd000`9d965000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16


SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: tdx!TdxPnpPowerComplete+25

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: tdx

IMAGE_NAME: tdx.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 5215f7c2

IMAGE_VERSION: 6.3.9600.16384

STACK_COMMAND: .cxr 0xffffd0009d969fd0 ; kb

BUCKET_ID_FUNC_OFFSET: 25

FAILURE_BUCKET_ID: AV_tdx!TdxPnpPowerComplete

BUCKET_ID: AV_tdx!TdxPnpPowerComplete

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:av_tdx!tdxpnppowercomplete

FAILURE_ID_HASH: {f565ca0b-8044-f5b2-2d34-59a9d6fe1bb5}

Followup: MachineOwner
---------

Wäre dankbar, wenn mir jemand einen Tipp geben könnte :thumbup:

Nachtrag:
Gerade eben ist das System extrem langsam geworden, hat gar nicht mehr reagiert...jetzt geht es wieder...das ist neu

 

[think_pad]

Der Bugcheck besagt, dass sich das W520 selbst abgeschaltet hat, um sich vor Datenverlust zu schützen. Dies macht er normalerweise nur, wenn etwas mit dem RAM (65%) nicht stimmt,oder die SSD "am Sterben" (20%) ist. Man hat auch schon siechende Akkus (5%) oder keuchende Netzteile (10%) gesehen, die so etwas ausgelöst haben.... :crying:

 

[linrunner]

Der Bugcheck besagt, dass sich das W520 selbst abgeschaltet hat, um sich vor Datenverlust zu schützen. Dies macht er normalerweise nur, wenn etwas mit dem RAM (65%) nicht stimmt,oder die SSD "am Sterben" (20%) ist. Man hat auch schon siechende Akkus (5%) oder keuchende Netzteile (10%) gesehen, die so etwas ausgelöst haben.... :crying:

Ich behaupte jetzt einfach mal, das alles was Du hier schreibst frei erfunden ist. Du darfst mir aber gerne das Gegenteil beweisen, indem Du uns die Stelle in s-gs Ausgabe und weitere Fundstellen zeigst, die Deine Aussagen belegen.

 

[think_pad]

Ich behaupte jetzt einfach mal, das alles was Du hier schreibst frei erfunden ist.

Auf Streit bin ich nicht aus, es geht hier nur darum, dem TE einen Weg zur Überprüfung seines ThinkPads zu weisen.

• http://msdn.microsoft.com/en-us/library/windows/hardware/ff557196(v=vs.85).aspx

If you received a blue screen error, or stop code, the computer has shut down abruptly to protect itself from data loss.

• http://answers.microsoft.com/en-us/...1000007e/e8f03131-18cf-4528-a3e2-acae1ddbb06f

Man kann dem TE jetzt noch sagen, dass diese Verhalten erfahrungsgemäß oft nach an einer falschen Ab-und Wiederanmeldung eines USB-Geräts auftritt, aber erst einmal sorgt man doch dafür, dass er die grundlegenden Funktionen des Geräts überprüft (RAM, SSD, Akku, Netzteil) Das ist der Plan, und der ist nicht falsch...

 

[s-g]

SSD ist zwar nicht mehr die frischeste, sieht aber imho noch brauchbar aus:



Am Montag lass ich mal den Tag über Memtest drüber laufen...

Akku und Netzteil sind schwer zu testen...aktuell läuft er (wieder) auch unter last stabil. Ich habe zwar noch ein zweites NT da, solange sich der Fehler aber nicht reproduzieren lässt...

Was mich bei der ganzen Sache stutzig macht ist halt, dass Windows nach dem Absturz nicht mehr vernünftig hochgefahren ist.

 

[think_pad]

Was mich bei der ganzen Sache stutzig macht ist halt, dass Windows nach dem Absturz nicht mehr vernünftig hochgefahren ist.

Eben, irgendetwas hat sich völlig unabhängig von der Ursache beim Absturz zerschossen; aber aus diesem Grund kann man mal C:\sfc /scannow durchführen...

 

[gestern]

System:
Windows 8.1 x64.
W520 mit Quadro 2000m und i7-2820qm.
Crucial m4 SSD.

ich tippe auf die SSD respektive auf die zusammenarbeit von win 8 mit den erweiterten stromsparmechanismen die win 8 mitbringt.
zudem ist per default kein abschalten bei win 8 eingestellt sondern ein tieferer schlafmodus, wenn er im stand by ist und sich runterfahren will wegen zu wenig akku, geht er in den tieferen schlafmodus und schreibt das ram noch auf die HDD.

genaueres kann man da nur sagen wenn man im detail die config der maschine kennt.
z.b. UEFI, secure boot, intel fast boot, MS quick boot, ob der cash der HDD aktiv ist, ob das BS die HDD in den schlaf senden darf, ob man eine ramdisk hat für die auslagerungsdatei und was darauf gelden wird (normalerweise).
fällt mir grad so spontan ein.

ich kann bei meiner kiste deinen fehler reproduzieren so oft ich will weil bei mir der kernel im ramdrive geladen wird, der wird dann nicht zuerück auf die HDD geschrieben ( weil das ram drive als laufwerk bewertet wird) und so muss halt windows neu starten weil es nicht weiss wo es stehen geblieben ist.

auch welche (eventuell) software man nimmt um sich die SSD einzurichten so richtet z.b. das neue samsungtool mit den neuen SSDs von samsung und mehr als 8 giga ram automatisch ein ramdrive ein als zusätzlichen SSD cash.

edit :
beim näheren betrachten der analyse ist mir aufgefallen das es sich bei dir um eine TCP/IP betitelte hardware adresse handelt.
also könnte es auch mit dem "strom und einem netzwerkadapter zusammen" handeln.
aber die könnte auch nur da sein weil vom W-Lan, zurück in die der dock, auf kabel netzwerk gewechselt wurde.
so genau erschliesst sich mir das nicht vom wissen her.

 

[s-g]

SFC bringt folgende Meldung:



Die CBS.log-Datei ist knapp 3mb groß, solange ich also nicht weiß wie man relevante Einträge filtern kann poste ich deren Inhalt hier besser nicht

Das der Rechner sich wegen zu wenig Saft ausgeschalten hat glaube ich nicht, im Akku war noch genügend für mindestens 30 min, außerdem wurde er im Moment des Absturzes geladen.

Der Tiefschlafmodus ist deaktiviert, die Auslagerungsdatei auf ein Minimum reduziert (16GB RAM und 128GB SSD).

RAMDisks ö.ä. gibt es keine.
Win 8.1 ist im UEFI-Only Modus installiert.
SecureBoot ist deaktiviert.
Intel FastBoot = Intel RapidBoot? Dazu sollte doch ein extra Tool von Intel installiert sein? ...wenns so ist, nicht aktiviert.
MS QuickBoot ist aktiviert.
SSD Cache ist aktiviert.
BS darf HDDs ins Bett schicken.

Einrichtungstools für die SSD gab es keine, Windows wurde ganz normal über die offizielle ISO installiert.

LAN-Kabel gibt es keine, für den Netzwerkzugang wird ausschließlich WLAN verwendet (Intel 6300).
Andere LAN-Adapter kommen von VMware oder VirtualBox.

 

[think_pad]

SFC bringt folgende Meldung...

Da haben wir den Salat, ich sag' da nur: Vertraut den Gurus, vertraut Euren alten Hackern! Nur sie wissen, was im Kopf und im fühlenden Herzen eines Computers vor sich geht... :thumbsup:

1. Ausgelöst wurde der Crash in der Dock vermutlich durch eine nicht abgemeldete und dann wieder angemeldete USB-Fernsehkarte oder eine Camera oder ähnliches (Pufferüberlauf) ...
2. Der unsichtbare Bluescreen hat Systemdateien zerschossen, die eigentlich repariert werden sollten, aber nicht wurden.
3. Der RAM muss unbedingt mal getestet warden, um ihn als Fehlerquelle auszuschließen.
4. Dass das System die Systemdateien nicht reparieren kann, zeigt nur, dass die SSD in allernächster Zeit den Löffel abgeben wird. Hier wäre ein Systemabbild auf USB-Platte dringend angesagt, und anschließend schon mal eine neue SSD sondieren.
5. Nun kann man sich auf die Suche nach dem unsignierten USB-Treiber machen, der den Crash ausgelöst hat. Entweder man findet einen signierten, oder man benutzt einen externen, aktiven USB-Hub, oder man meldet alle kritischen Geräte von Hand ab, bevor man das Gerät aus der Dock holt.

 

[DTM]

...

Mit Verlaub, das ist alles hanebüchener Unsinn. Du hast keine Ahnung, wovon du sprichst. Es gibt keine Hinweise auf Pufferüberlauf, Kamera, Fernsehkarte, RAM-Fehler, SSD-Probleme oder unsignierte Treiber. Und das mit der Selbstabschaltung zum Schutz der Daten ist eine Binsenweisheit. Eine unbehandelte Exception im User-Mode führt zum Absturz des Programms, läßt das System aber unberührt, weil Prozesse gegen den Rest des Systems isoliert sind. Eine unbehandelte Exception im Kernel-Mode aber führt zu einem Bugcheck (=> BSOD), weil Code im Kernel-Mode nicht isoliert ist und sich nicht einfach beenden oder neustarten läßt. (Ausnahme: Graphiktreiber seit Vista.) Das Auftreten eines Bugchecks kann zwar durch einen Hardwarefehler (RAM, SSD) ausgelöst werden, aber das passiert eher im laufenden Betrieb und nicht beim An- oder Abdocken.

Überhaupt sehe ich keinerlei Indizien, daß der Fehler durch Hardware verursacht wird. Es handelt sich um einen Treiber oder eine Kernel-Komponente, die eine unbehandelte Exception ausgelöst hat. Die naheliegendste Vermutung ist also ein Treiberfehler. Der Stacktrace legt nahe, daß es durch Plug-and-Play ausgelöst wird.

Ich vermute, daß die meisten Plug-and-Play-Gerätetreiber darauf getestet werden, daß das jeweilige Gerät einzeln angeschlossen oder entfernt wird. Beim Docking und Undocking passiert das aber mit x Geräten zugleich, und das verursacht evtl. eine Race-Condition oder sonst irgendwas, womit die Treiber nicht gerechnet haben. Das spricht auch gegen einen RAM- oder SSD-Defekt. Für diese These spricht auch, daß du das Problem vor längerer Zeit schonmal hattest. Das Lustige an Race-Conditions ist ja gerade, daß sie nur unter ganz bestimmten Umständen und auch dann nicht jedes Mal auftreten. Sowas zu debuggen ist fürchterlich.

Wahrscheinlich gibt es einen bestimmten Treiber oder ein bestimmtes Gerät, das den Fehler auslöst. Der Crashdump zeigt auf tdx.sys, das ist der Kernel-Mode-Teil des Transport Driver Interface. Vielleicht liegt es am Netzwerktreiber; kommt mir allerdings nicht allzu wahrscheinlich vor. Zumal du gar kein LAN-Kabel angeschlossen hast.

Nach einem Bugcheck (besonders einem wiederholten) geht Windows der Vermutung nach, daß es wohl an einem Treiber liegen könnte. Ich vermute, daß die Automatische Reparatur versuchsweise einzelne Treiber deaktiviert, um zu schauen, ob es hilft. Kann sein, daß sie auch die Systemintegrität überprüft.

Wie dem auch sei, laß deine SSD in Frieden, die sind wahrscheinlich nicht schuld. Interessant wäre eher, was für Software du installiert hast, die eine Kernel-Mode-Komponente beinhaltet. Vielleicht einen renitenten Virenscanner?

 

[think_pad]

Überhaupt sehe ich keinerlei Indizien, daß der Fehler durch Hardware verursacht wird. Es handelt sich um einen Treiber oder eine Kernel-Komponente, die eine unbehandelte Exception ausgelöst hat. Die naheliegendste Vermutung ist also ein Treiberfehler. Der Stacktrace legt nahe, daß es durch Plug-and-Play ausgelöst wird.

Nichts anderes wurde behauptet, und dennoch ist es richtig, den TE erst seine Hardware überprüfen zu lassen, damit ein Hardwarefehler prinzipiell ausgeschlossen werden kann.

Eine nicht durchführbare Systemüberprüfung durch das System selbst lässt aber nun mal darauf schließen, dass aus irgendeinem Grund Backup-Dateien, die für die Korrektur der Systemdateien vorhanden sein müssen, nicht da sind. Entweder ist das System korrupt, oder mit der SSD stimmt etwas nicht...

 

[s-g]

Also an der Dock hängen

Logitech USB Maus + Tastatur
2x Externe Festplatte, einmal über USB einmal über eSATA
Plextor DVD-laufwerk (im Ultrabay liegt die originale HDD)
Creative USB-Soundkarte
SilverCrest Kartenleser
Monitor und Fernseher

die einzigen nicht signierten Dateien die auf Anhieb gefunden wurden sind
Anhang anzeigen 97442
welche vermutlich beide etwas mit dem Fingerprint-Reader zu tun haben.

Ein kurzer Durchlauf mit dem Windowseigenen RAM-Test brachte keine Fehler, Memtest lass ich morgen über den Tag laufen.

Keine Ahnung, welche meiner Programme den Kernel Mode nutzen...
Antivirus ist Eset Smart Security.
Ansonsten gibts noch VMWare und VirtualBox, die ThinkVantage Fingerprint-Software, TPFanControl, ... das übliche Office-Zeug...und sonst rein gefühlsmäßig nichts, welches tiefere Systemrechte erfordert...

 

[der_ingo]

VMware und VirtualBox und dazu noch die Treiber des Virenscanners? Weia. ;-)

Wenn das jetzt ein einzelner BSOD war, würde ich da erst einmal abwarten und beobachten, ob es wieder auftaucht. Falls ja, wäre der Virenscanner für mich der erste Kandidat, der deinstalliert wird.

Die Treiber für die WLAN Karte sind aktuell in der Version von Intel?

 

[s-g]

RAM-Test hat nichts ergeben...

Meine Treiber sind idr. so aktuell, wie es Windows/ ThinkVantageSystem -Update auch sind
Werde aber nochmal manuell auf aktuelle Treiber prüfen...