PC stürzt im laufenden Betrieb ab ... Bluescreen IRQL_NOT_LESS_OR_EQUAL

[Dennis_1]

Hallo !

Ich habe gefühlt alle 1-2 Wochen einen PC-Absturz mit folgender Fehlermeldung:




Woran erkenne ich nun, welcher Treiber dafür verantwortlich ist ?

 

[onetwoxx]

Welches OS und wann hast du das letzte mal dein OS neu aufgesetzt?

 

[dominic.e]

Wird der Fehler nicht meist durch Probleme mit RAM oder Grafikkarte hervorgerufen?

 

[dhsalamipizza]

Teste mal den Speicher mit memtest.

 

[Marteg]

Hi !

Ich hatte das gleiche Problem und dachte zunächst auch es würde sich um ein Treiberproblem handeln, bis ein Freund mir sagte es könnte auch der Arbeitspeicher defekt sein. Ich habe dann versuchsweise anstatt meines Corsair-Speichers ein Kit von AMD aus der Gamerserie ausprobiert und seitdem keinen Bluescreen mehr gesehen. Wenn Du die Möglichkeit hast das zu testen, würde ich es auf jeden Fall versuchen.
Ganz wichtig ist in dem Zusammenhang, dass die Speicherspannung stabil ist, denn wenn dein Board undervolted kann das auch zu einem instabilen System führen, das ab und an mal abschmiert.

Hoffe ich konnte helfen ?!

Good Luck !!!

 

[cbtestarossa]

http://www.nirsoft.net/utils/blue_screen_view.html
um den gespeicherten Crashdump/Minidump auszulesen.

oder mal in der Ereignisanzeige schauen ob da was ersichtlich ist

 

[MountWalker]

Wenn irgendwelche Hardware im Betrieb aussteigt, kann abgesehen von der Hardware auch das Netzteil die Ursache sein.

 

[Dennis_1]

Ok danke schonmal, ich werde es zunächst mal mit nem aktuelleren Grafiktreiber ausprobieren.
Der PC stürzt auch mal aus einem Spiel heraus ab oder auch wenn ich im Internet surfe.

Hilft das weiter?

 

[dhsalamipizza]

Ich hatte den Fehler bisher immer bei defektem RAM.
Daher kann ich dir weiterhin empfehlen die Ram Riegel einzeln zu testen und das mit memtest:

http://www.memtest.org/#downiso

 

[onetwoxx]

Danke, der Fehlerbericht ist ganz hilfreich

ich sehe anhand deines Fehlerberichtes kein Defekt am MB oder NT, die haben auch alle einen komplett anderen Fehlercode

Der Fehler IRQ less or equal weist unter anderem auf einen Adressierungs-/Speicherfehler hin, könnte ein Fehler des RAM sein, aber auch fehlerhaftes Ansprechen von der Festplatte wie auch der Grafikkarte, aber die Fehlermeldung zeigt hal.dll & ntoskrnl.exe als Fehlerursache an. Versuche mal die hal.dll neu aufzusetzen (alte durch neue ersetzen, gogglen). Den ntoskrnl.exe Fehler kenne ich nur durch den Betrieb von zwei OS bei dem ein fehlerbehafteter Virenscanner (mal de- und neuinstallieren versuchen).

Wenn die alles nichts hilft, und wenn der memtest nichts ergibt, setze dein System komplett neu auf (die fehlerhafte Datei zu finden ist nahezu unmöglich), zumal weitere Bluescreen auch die HDD versauen können

 

[Dennis_1]

Also der memtest hat keine Fehler ergeben, lasse gerade ne DLL Suite laufen, die Fehler beseitigen soll.
Danach werd ich die hal.dll nochmal austauschen und hoffen, dass der Fehler nicht erneut auftritt.

 

[MountWalker]

...
ich sehe anhand deines Fehlerberichtes kein Defekt am MB oder NT, die haben auch alle einen komplett anderen Fehlercode

Der Fehler IRQ less or equal weist unter anderem auf einen Adressierungs-/Speicherfehler hin, ...

Wenn das NT auf einer Leitung kurzzeitig zu wenig Saft liefert und deshalb ein Speichermodul unterversorgt wird gibts einen Speicherfehler. Wenn der Fehler auftritt, während man beobachtet, dass alle Spannungen innerhalb des Toleranzbereichs liegen, dann kann man das Netzteil ausschließen - aber nciht aufgrund einer BSOD-Meldung, die lediglich meldet, welcher Softwarevorgang gerade stattfand, als der Fehler passierte.

 

[simpel1970]

Lade mal die Dump Dateien hier hoch. Bluescreenview arbeitet zu oberflächlich, um Treiberprobleme 100%ig ausschließen zu können. Eine Auswertung der Dumps mit den Debugging Tools wäre empfehlenswerter.

lasse gerade ne DLL Suite laufen, die Fehler beseitigen soll.

Ob das etwas bringt?

 

[onetwoxx]

Wenn das NT auf einer Leitung kurzzeitig zu wenig Saft liefert und deshalb ein Speichermodul unterversorgt wird gibts einen Speicherfehler. Wenn der Fehler auftritt, während man beobachtet, dass alle Spannungen innerhalb des Toleranzbereichs liegen, dann kann man das Netzteil ausschließen - aber nciht aufgrund einer BSOD-Meldung, die lediglich meldet, welcher Softwarevorgang gerade stattfand, als der Fehler passierte.

Ich habs aufgrund der Aussage

Ich habe gefühlt alle 1-2 Wochen einen PC-Absturz...

das NT ausgeschlossen, sonst würde der Fehler viel öfters auftreten als nur ein- bis zweimal in zwei Wochen. Meiner Erfahrung nach springt deine genannten Spannungunterversorgung nicht hin und her, entweder sie ist da und treten sehr häufig auf oder garnicht

 

[Dennis_1]

Habe die hal.dll mal ausgetauscht und nun taucht nur noch die ntoskrnl.exe als Fehler auf.
Habe mal die letzten beiden Dump's hochgeladen.

Kennt sich jmd damit aus ?

Anhang anzeigen Dump.zip

 

[simpel1970]

Spoiler: Dump vom 11.02.2015

*******************************************************************************
* *
* 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: 000000001ec1f7e0, 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: fffff80003a18b07, address which referenced memory

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

TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2

WRITE_ADDRESS: GetPointerFromAddress: unable to read from fffff800036c2100
GetUlongFromAddress: unable to read from fffff800036c21c0
000000001ec1f7e0 Nonpaged pool

CURRENT_IRQL: f

FAULTING_IP:
hal!HalpPciReadMmConfigUlong+7
fffff800`03a18b07 8902 mov dword ptr [rdx],eax

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: SolutoService.

TRAP_FRAME: fffff8800a0473b0 -- (.trap 0xfffff8800a0473b0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=00000000198c0fef rbx=0000000000000000 rcx=ffffffffffd1b000
rdx=000000001ec1f7e0 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80003a18b07 rsp=fffff8800a047548 rbp=ffffffffffd1b000
r8=00000000000000a4 r9=00000000000000a4 r10=0000000000000000
r11=fffff80003a261d0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
hal!HalpPciReadMmConfigUlong+0x7:
fffff800`03a18b07 8902 mov dword ptr [rdx],eax ds:00000000`1ec1f7e0=????????
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80003488469 to fffff80003488ec0

STACK_TEXT:
fffff880`0a047268 fffff800`03488469 : 00000000`0000000a 00000000`1ec1f7e0 00000000`0000000f 00000000`00000001 : nt!KeBugCheckEx
fffff880`0a047270 fffff800`034870e0 : fffff880`009ea180 fffffa80`0d363b50 00000000`1ec1f7e0 00000000`00000004 : nt!KiBugCheckDispatch+0x69
fffff880`0a0473b0 fffff800`03a18b07 : fffff800`03a08245 fffff880`0a047610 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x260
fffff880`0a047548 fffff800`03a08245 : fffff880`0a047610 00000000`00000000 00000000`00000000 fffff800`03a080d6 : hal!HalpPciReadMmConfigUlong+0x7
fffff880`0a047550 fffff800`03a08b32 : 00000000`e00c301b 00000000`1ec1f7e0 00000000`00000004 00000000`00000000 : hal!HalpPCIPerformConfigAccess+0x55
fffff880`0a047580 fffff800`03a0802c : 00000000`00000000 fffff800`00000078 fffff880`0a047780 00000000`00000004 : hal!HalpPciAccessMmConfigSpace+0x196
fffff880`0a0475d0 fffff800`03a07e06 : 00000000`00000004 fffffa80`00000078 00000000`000000a4 fffff880`0a047780 : hal!HalpPCIConfig+0x9c
fffff880`0a047640 fffff800`03a079f8 : 00000000`00000078 fffff800`00000078 00000000`000000a4 00000000`00000000 : hal!HalpReadPCIConfig+0x5e
fffff880`0a047680 fffff800`03a08c12 : 00000000`00000000 fffff800`0378b420 00000000`00000001 fffffa80`0d61ccc8 : hal!HalpGetPCIData+0x100
fffff880`0a047750 fffff880`07f21ff2 : 00000000`00000004 fffffa80`0704db40 fffffa80`0d61ccc8 00000000`00000000 : hal!HalGetBusDataByOffset+0x86
fffff880`0a047840 00000000`00000004 : fffffa80`0704db40 fffffa80`0d61ccc8 00000000`00000000 00000000`000000a4 : cpuz136_x64+0x1ff2
fffff880`0a047848 fffffa80`0704db40 : fffffa80`0d61ccc8 00000000`00000000 00000000`000000a4 00000000`00000004 : 0x4
fffff880`0a047850 fffffa80`0d61ccc8 : 00000000`00000000 00000000`000000a4 00000000`00000004 00000000`00000000 : 0xfffffa80`0704db40
fffff880`0a047858 00000000`00000000 : 00000000`000000a4 00000000`00000004 00000000`00000000 fffff8a0`05513c80 : 0xfffffa80`0d61ccc8


STACK_COMMAND: kb

FOLLOWUP_IP:
cpuz136_x64+1ff2
fffff880`07f21ff2 ?? ???

SYMBOL_STACK_INDEX: a

SYMBOL_NAME: cpuz136_x64+1ff2

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: cpuz136_x64

IMAGE_NAME: cpuz136_x64.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 508c18d9

FAILURE_BUCKET_ID: X64_0xA_cpuz136_x64+1ff2

BUCKET_ID: X64_0xA_cpuz136_x64+1ff2

Followup: MachineOwner

Danach hat das (veraltete) CPU-Z Tool den hal Fehler ausgelöst. Ist ein bischen überraschend. Ein Absturz durch CPU-Z ist mir auch noch nicht untergekommen.
Jedenfalls war nicht die hal.dll Ursache für den Absturz.

Spoiler: Dump vom 12.02.2015

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
2) A developer attempted to set a normal kernel breakpoint using a kernel
debugger that was not attached when the system was booted. Normal breakpoints,
"bp", can only be set if the debugger is attached at boot time. Hardware
breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a039d89e27373b, Reserved
Arg2: b3b7465ef0a40691, Reserved
Arg3: fffff8000356f710, Failure type dependent information
Arg4: 0000000000000001, Type of corrupted region, can be
0 : A generic data region
1 : Modification of a function or .pdata
2 : A processor IDT
3 : A processor GDT
4 : Type 1 process list corruption
5 : Type 2 process list corruption
6 : Debug routine modification
7 : Critical MSR modification

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


BUGCHECK_STR: 0x109

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff800034c6ec0

STACK_TEXT:
fffff880`033925d8 00000000`00000000 : 00000000`00000109 a3a039d8`9e27373b b3b7465e`f0a40691 fffff800`0356f710 : nt!KeBugCheckEx


STACK_COMMAND: kb

SYMBOL_NAME: ANALYSIS_INCONCLUSIVE

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME: Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP: 0

BUCKET_ID: BAD_STACK

Followup: MachineOwner

Aus der Dump kann man leider nicht viel herausholen. Hast du an dem Tag die hal.dll schon ausgewechselt?

Ob die Fehler nun softwareseitig ausgelöst werden, oder hardwarebedingt sind, lässt sich nicht eindeutig ausmachen.
Ist dein System übertaktet?
Wenn nicht, würde es sich anbieten ggf. das Betriebssystem neu zu installieren (insbes. ohne Tools wie TuneUp, etc.). Auch bei dir Installation darauf achten, dass keine veraltete(n) Software/Treiber installiert werden.
Veraltete Treiber sind insbes.:
- 000.fcl (von 2008) -> CyberLink FCL Driver oder CyberLink PowerDVD
- ctac32k.sys (von 2008) -> Creative
- AtiPcie.sys (von 2009) -> ATI/AMD PCIE Treiber für ATI PCIE Chipsatz oder ATI PCI Express

Poste bitte noch ein paar Screenshots von CPU-Z (Reiter Mainboard, CPU, Memory und SPD)

 

[Dennis_1]

Ja beim 2. Dump ist die hal.dll bereits ausgetauscht.
Hatte testweise die Windows interne Speicherprüfung mal 2 Stunden laufen lassen und sie hatte auch nur den hal.dll Fehler gefunden.
Übertaktet ist bei mir nichts, hatte nur vor 4 Monaten eine neue Grafikkarte (R9 280) und 2 weitere 2GB RAM-Riegel eingebaut.

Werde gleich mal die neuen RAM-Riegel ausbauen und schauen, ob er dann stabiler läuft. Komisch ist nur, dass die Bluescreens erst nach 1-2 Monaten aufgetreten sind und nicht direkt nach dem Upgrade.

 

[simpel1970]

Teste die RAM Kits mit Memtest86+ auf Fehler. Die Prüfung außerhalb von Windows mind. 4-6 Std. laufen lassen.
Werden dort keine Fehler gefunden, könnte das Problem auch an der Vollbestückung liegen, oder die RAM Kits passen einfach nicht zusammen.
Ich würde -sofern mit Memtest keine Fehler gefunden werden- die RAM Kits einzeln einbauen (also immer nur 2x2 GB) und im Betrieb testen, ob bei beiden Kits Probleme auftauchen, oder ob es problemlos läuft.

Treten dabei mit keinem Kit Probleme auf, könnten ggf. manuelle Bios Einstellungen (z.B. RAM Spannung erhöhen) das "Vollbestückungs-" Problem lösen.

Bezüglich des hal.dll Austausches, lasse bitte mal sfc /scannow laufen, um die Systemdaten auf Integrität zu überprüfen.
Dazu die Eingabeaufforderung als Administrator starten und folgenden Befehl eingeben:
sfc /scannow

 

[onetwoxx]

Wenn der memtest nichts gebracht hat, mach ein Backup deiner wichtigen Daten, und setzte dann dein Win neu auf. Wenn danach wieder wieder die gleichen Bluesccrens auftreten liegt an der Hardware, wenn nicht dann war es eine fehlerbehaftete Win Datei, alles in allem spart das Zeit und du kannst danach wenigstens etwas ausschließen

 

[Dennis_1]

Kurzer Zwischenbericht ... nachdem ich auch noch den Scan auf Integrität der Systemdaten durchgeführt habe, läuft der PC nun seit einer Woche stabil ohne Absturz.