Bluescreens Win 7 Pro x64 (BlueScreenView Report!)

mal kleines Update: seit Wochen keine Bluescreens mehr :banana:
scheint wirklich mit der RAM Spannung zusammen gehangen zu haben. hoffe jetzt da ich es ausspreche und mich freue dass mich der fehler nicht erneut einholt^^
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hi zusammen,

beim durchforsten des Forum bin ich hier gelandet.
Ich habe aktuell ähnliche Probleme wie hier beschrieben:
http://www.hardwareluxx.de/community/f230/bluescreen-woran-liegts-824801.html#post17256291

Mein erstes Ram Kit von Kingston lief auch mit erhöhter Spannung von 1,59 Volt.
Aktuell ausgetauschte Adata Module mit 1,5 Volt.
Bluescreens sind geblieben.

Verändert habe ich jetzt noch, Enhanced Halt State (C1E) und Agressive Power Link deaktiviert.
C1E soll laut diversen Berichten auch ein BSOD Verursacher sein.

Alle Platten, Ram, Prime, Mem, BurnIn... Test liefen einwandfrei durch.
Wie kann der ntoskernel abkacken?

Gruß Alex

Anlage CPU-Z, AIDA64 Infos
 

Anhänge

  • CPU.png
    CPU.png
    17,7 KB · Aufrufe: 27
  • Memory.png
    Memory.png
    12,3 KB · Aufrufe: 27
  • SPD.png
    SPD.png
    14,5 KB · Aufrufe: 30
  • Aida Übersicht.png
    Aida Übersicht.png
    51,6 KB · Aufrufe: 30
  • Aida Sensoren.png
    Aida Sensoren.png
    35,6 KB · Aufrufe: 22
Nachtrag: eben neuer BSOD, DMP File, BlueScreenView
PC lief nur zum TV schauen, habe gemerkt das der Ton weg war.

Alex

Anlage:
Crash File DMP und BlueScreenView
 

Anhänge

  • BlueScreenView BSOD.png
    BlueScreenView BSOD.png
    29,5 KB · Aufrufe: 23
  • 081011-13072-01.zip
    25,6 KB · Aufrufe: 19
Das wäre die Auswertung deiner Dump:

Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [F:\Programme\081011-13072-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*C:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0xfffff800`02e66000 PsLoadedModuleList = 0xfffff800`030ab670
Debug session time: Wed Aug 10 11:54:59.962 2011 (GMT+2)
System Uptime: 0 days 2:21:12.805
Loading Kernel Symbols
...............................................................
................................................................
.......................................
Loading User Symbols
Loading unloaded module list
..........
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {217a, f, 1, fffff80002ecce0e}

Probably caused by : ndis.sys ( ndis!ndisMiniportMessageIsr+a8 )

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

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

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 000000000000217a, memory referenced
Arg2: 000000000000000f, IRQL
Arg3: 0000000000000001, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff80002ecce0e, address which referenced memory

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


WRITE_ADDRESS: GetPointerFromAddress: unable to read from fffff80003115100
000000000000217a

CURRENT_IRQL: f

FAULTING_IP:
nt!KeInsertQueueDpc+18e
fffff800`02ecce0e 0f0d8bdc210000 prefetchw [rbx+21DCh]

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: System

TRAP_FRAME: fffff80004acc850 -- (.trap 0xfffff80004acc850)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000001 rbx=0000000000000000 rcx=fffffa800b675500
rdx=0000000000000022 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002ecce0e rsp=fffff80004acc9e0 rbp=fffffa800b675518
r8=0000000000000029 r9=0000000000000000 r10=0000000000000000
r11=fffff80003058e80 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
nt!KeInsertQueueDpc+0x18e:
fffff800`02ecce0e 0f0d8bdc210000 prefetchw [rbx+21DCh]
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80002ee21e9 to fffff80002ee2c40

STACK_TEXT:
fffff800`04acc708 fffff800`02ee21e9 : 00000000`0000000a 00000000`0000217a 00000000`0000000f 00000000`00000001 : nt!KeBugCheckEx
fffff800`04acc710 fffff800`02ee0e60 : fffffa80`07f44000 fffff880`06d083cd fffffa80`0c337000 fffff800`03058e80 : nt!KiBugCheckDispatch+0x69
fffff800`04acc850 fffff800`02ecce0e : 00000000`40950088 00000000`00000001 00000001`00000000 ffffda7e`39cc3a88 : nt!KiPageFault+0x260
fffff800`04acc9e0 fffff880`01cd2488 : fffffa80`0b675518 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KeInsertQueueDpc+0x18e
fffff800`04acca70 fffff800`02edea7c : fffff800`03058e80 fffffa80`00000001 00000000`00000000 00000000`00000000 : ndis!ndisMiniportMessageIsr+0xa8
fffff800`04accab0 fffff800`02eda942 : fffff800`03058e80 fffff800`00000001 00000000`00000001 fffff880`00000000 : nt!KiInterruptDispatch+0x16c
fffff800`04accc40 00000000`00000000 : fffff800`04acd000 fffff800`04ac7000 fffff800`04accc00 00000000`00000000 : nt!KiIdleLoop+0x32


STACK_COMMAND: kb

FOLLOWUP_IP:
ndis!ndisMiniportMessageIsr+a8
fffff880`01cd2488 84c0 test al,al

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: ndis!ndisMiniportMessageIsr+a8

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: ndis

IMAGE_NAME: ndis.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4ce79392

FAILURE_BUCKET_ID: X64_0xA_ndis!ndisMiniportMessageIsr+a8

BUCKET_ID: X64_0xA_ndis!ndisMiniportMessageIsr+a8

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

0: kd> .trap 0xfffff80004acc850
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000001 rbx=0000000000000000 rcx=fffffa800b675500
rdx=0000000000000022 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002ecce0e rsp=fffff80004acc9e0 rbp=fffffa800b675518
r8=0000000000000029 r9=0000000000000000 r10=0000000000000000
r11=fffff80003058e80 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
nt!KeInsertQueueDpc+0x18e:
fffff800`02ecce0e 0f0d8bdc210000 prefetchw [rbx+21DCh]
0: kd> .bugcheck
Bugcheck code 0000000A
Arguments 00000000`0000217a 00000000`0000000f 00000000`00000001 fffff800`02ecce0e
0: kd> kb
*** Stack trace for last set context - .thread/.cxr resets it
RetAddr : Args to Child : Call Site
fffff880`01cd2488 : fffffa80`0b675518 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KeInsertQueueDpc+0x18e
fffff800`02edea7c : fffff800`03058e80 fffffa80`00000001 00000000`00000000 00000000`00000000 : ndis!ndisMiniportMessageIsr+0xa8
fffff800`02eda942 : fffff800`03058e80 fffff800`00000001 00000000`00000001 fffff880`00000000 : nt!KiInterruptDispatch+0x16c
00000000`00000000 : fffff800`04acd000 fffff800`04ac7000 fffff800`04accc00 00000000`00000000 : nt!KiIdleLoop+0x32
0: kd> kv
*** Stack trace for last set context - .thread/.cxr resets it
Child-SP RetAddr : Args to Child : Call Site
fffff800`04acc9e0 fffff880`01cd2488 : fffffa80`0b675518 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KeInsertQueueDpc+0x18e
fffff800`04acca70 fffff800`02edea7c : fffff800`03058e80 fffffa80`00000001 00000000`00000000 00000000`00000000 : ndis!ndisMiniportMessageIsr+0xa8
fffff800`04accab0 fffff800`02eda942 : fffff800`03058e80 fffff800`00000001 00000000`00000001 fffff880`00000000 : nt!KiInterruptDispatch+0x16c (TrapFrame @ fffff800`04accab0)
fffff800`04accc40 00000000`00000000 : fffff800`04acd000 fffff800`04ac7000 fffff800`04accc00 00000000`00000000 : nt!KiIdleLoop+0x32
0: kd> .trap fffff800`04accab0
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000002
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002eda942 rsp=fffff80004accc40 rbp=0000000000000002
r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
r11=fffff80003058e80 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po nc
nt!KiIdleLoop+0x32:
fffff800`02eda942 440f22c1 mov cr8,rcx
0: kd> kb
*** Stack trace for last set context - .thread/.cxr resets it
RetAddr : Args to Child : Call Site
00000000`00000000 : fffff800`04acd000 fffff800`04ac7000 fffff800`04accc00 00000000`00000000 : nt!KiIdleLoop+0x32

Ich gehe richtig davon aus, dass du ständig wechelnde Stopfehlercodes hast? Es sieht -zumindest nach der Auswertung- nicht nach einem Treiberproblem, eher nach einem Hardwareproblem aus.

Dennoch zur Sicherheit, falls es immer der gleiche Stopfehlercode sein sollte...alle Treiber sind Up-to-Date? Hast du irgendwelche Systemtools installiert? Was für eine Firewall- und Antivirensoftware hast du?

C1E soll laut diversen Berichten auch ein BSOD Verursacher sein.

Bei einem "normal" laufenden, bzw. nicht übertakteten System nicht.

Poste bitte noch einen Screenshot vom CPU-Z Reiter "Mainboard".

Ein CMOS Reset hast du schon mal ausgeführt? Die RAM auch schon einzeln laufen lassen (immer nur einen RAM Riegel einbauen)?

Edit:

Sehe gerad, dass du einen Link im ersten Post gesetzt hast... (besser spät als nie merken :d)
Hier fällt mir eine Sache ins Auge:

Habe nur die maximale TDP für den TurboMode von 118 Watt auf 105 Watt gesenkt, Ram läuft auch mit 1.5 Volt wie empfohlen.

Was genau hast du da gemacht? Den Spannung reduziert? Das würde die ganzen Bluescreens erklären.

Wir posten dann aber wohl lieber in deinem Thread weiter.
 
Zuletzt bearbeitet:
Die Stopfehlercodes waren meist immer gemischt, meist der 0x00000124,
sonst 0x0000001e, 0x00000116, 0x0000003b, 0x0000000a

Firewall Windows 7 eigene, Virenscanner mal Norton 2011 (ohne FW), Avast und
den Microsoft Virenscanner, stets das gleiche.
Treiber sind aktuell von der Herstellerseite, nix Beta.
Windows 7 x64 ist die gleiche Installationsart wie auf meinem alten System mit einem Intel P45 Chipsatz, dort liefen Grafik-, TV- und Netzwerke, alle Festplatten durchgehend ohne Bluescreens oder Hänger.

CMOS schon durchgeführt, Batterie schon raus, BSOD's sind seit Boardkauf mit Bios 1.4.
Ram schon einzeln laufen gelassen, Adata und Kingston, nix über oder untertaktet.

TurboMode, das Board stellt selber ein (Bios TDP 118 Watt) welche maximale TDP die CPU für kurze Zeit vertragen kann, habe die nur runter gestellt, kein Vcore verändert.

Alles schon aus dem System rausgeworfen und nach einander dazu eingebaut/ installiert.
Prime und Co. sind noch nie abgestürzt und immer durch gelaufen, alle Platten komplett mit den Herstellertools im langen Test überprüft.
Kabel, Netzteil getauscht...

Mir kraut es davor das Board zu wechseln.

Gruß Alex

Anlagen mit dem DMP File 0x00000124
 

Anhänge

  • CPU-Z Mainboard.png
    CPU-Z Mainboard.png
    10,7 KB · Aufrufe: 31
  • Bios Voltage Control.jpg
    Bios Voltage Control.jpg
    188,9 KB · Aufrufe: 22
  • CPU Control.jpg
    CPU Control.jpg
    174 KB · Aufrufe: 24
  • 080911-13587-01.zip
    25,7 KB · Aufrufe: 18
Zuletzt bearbeitet:
Alles schon aus dem System rausgeworfen und nach einander dazu eingebaut/ installiert.

Also auch wenn du das Betriebssystem neu installierst und nur die notwendigste Hardware einbaust (insbes. Intel Gigabit CT Desktop Adapter und die Technisat SkyStar HD2 weglassen), treten die Probleme auf?

Ohne die manuellen Bioseinstellungen (also rein die Setup Defaults lassen) treten die Probleme auch auf?

Wie hoch bist du mit der RAM Spannung mit den A-DATA schon gegangen?
 
Hi,

mein System läuft nun seit 2 Tagen ohne Absturz (BSOD) oder Hänger.
Es gab ein neues Bios für mein Board, TV und Grafikkarte habe ich umgesteckt, habe alles neu aufgesetzt mit den wie bisher neusten Treibern und 2 noch nicht über Windows Update angebotene Patches eingespielt.

Einer davon war:
Computer randomly stops responding because of a deadlock situation in Windows Server 2008 R2 or in Windows 7

Den anderen finde ich nicht wieder.
Bisher läuft alles rund, lasse den PC jeden Tag mit allen möglichen Sachen 16 Stunden lang laufen.

Komisch find ich, mit 8GB Ram war die VDIMM bei 1,50V und T1, mit 16GB Ram 1,59V und T2.
Die JEDEC schreibt eine Abweichung von -/+ 5 %, machen die 0,9 Volt mehr dem Ram was aus?

Im Bios habe ich sonst nur AHCI und EPU Power Safe aktiviert und Floppy, Serial Port ausgestellt.(C1E und Agressive Power Link sind enabled)

Ich beobachte mal weiter das System und berichte wieder.
Hoffentlich bringt Intel mal eine neue Intel Firmware Engine auf dem neusten Stand raus, bezüglich der bekannten kleineren SSD Ansteuerungsbugs.

Danke und Gruß
Alex
 
Schön dass es nun läuft!

Die Command Rate - Einstellung 2T ist für Vollbestückung normal.
Die 1,59V Spannung sind für den RAM unproblematisch und für den Memory-Controller in der CPU noch akzeptabel.
 
Nabend Luxxer

Ein Kumpel hatte eben diesen Bluescreen



Kann mir jemand weiterhelfen? :hmm:
 
google den Stop Code . Wird wohl am schnellsten gehen.
 
Der Stop 0xF4 Fehler kann vielerlei Ursachen haben.
Häufig tritt er bei Problemen mit der Systemplatte auf. Sofern dein Kumpel eine SSD hat, sollte er mal nach der aktuellsten Firmware ausschau halten.
Des weiteren wäre ein Screenshot von CrystalDiskInfo hilfreich.

Laut dem Screenshot wurde zudem eine Dump Datei angelegt. Diese könnte nähere Informationen über die Absturzursache beinhalten. Die Dumps werden i.d.R. unter C:\Windows\Minidump abgelegt (je nach Einstellung ggf. auch als MEMORY.DMP unter C:\Windows).
Diese Dump Datei sollte er dir zur Verfügung stellen, damit du sie hier hochladen kannst.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh