Regelmäßige Abstürze und letztendlich BlueScreen

Ich glaube ja tatsächlich, dass auf mir ein Voodoo-Zauber liegt... :d
Seitdem das neue Netzteil Freitag bei mir Post ankam, läuft alles tadellos. Es ist nicht mal eingebgaut, sondern steht lediglich im Raum (wollte noch warten bis der Fehler erneut auftritt, um auf Nummer sicher zu gehen) und es gab seitdem keinen einzigen Aussetzer mehr. Jetzt habe ich ja schon fast Angst das Ding wieder zurückzuschicken.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
So, ich melde mich dann mal wieder zurück und missbrauche mein altes Thema - es tut mir leid, dass die Rückmeldung ausblieb... Ich musste letztlich übrigens doch das neue Netzteil einbauen und der Rechner lief dann für einige Zeit bis erneute Probleme mich dazu trieben einen weiteren Motherboard-Tausch durchzuführen, auch das half für einen ungewissen Zeitraum.

Mittlerweile habe ich aber wieder ein ähnliches Problembild: scheinbar willkürliche Abstürze während der Ausführung von 3D-Anwendungen (i.d.R. Spiele) mit unterschiedlich hohen Leistungsansprüchen. In ca. 80% der Fälle kommt es tatsächlich zum...
  1. Absturz/Freeze - Bild und Ton frieren ein bzw. beides verzerrt auf bizarre Art und Weise, wird unregelmäßig von einem der beiden folgenden Punkte abgelöst
  2. Neustart - der Rechner startet einfach vorbehaltlos neu und bleibt oftmals auch im Bootvorgang hängen, kein bestimmter Zeitpunkt feststellbar (sowohl bim Bios-Screen, als auch beim "Windows wird gestartet". Lüfter laufen dabei scheinbar auf Hochtouren (der Geräuschkulisse nach zu urteilen) bis man im Anmeldescreen ist.
  3. BSoD - erklärt sich praktisch von selbst, es ist aber bisher selten zwei Mal der gleiche aufgetreten. Leider habe ich kein Archiv mit den entsprechenden STOP-Codes angelegt, aber zumindest die aktuelle Minidump kann ich vorzeigen.

Aber erstmal meine Screenshots von CPU-Z:
cpu_caches_mainboard.jpgmemory_spd_graphics.jpg
Zum SPD-Screen: Slot 3 und 4 sind exakt gleich, 1 und 2 sind nicht belegt, da ich aufgrund des CPU-Lüfters an diese nur schwerlich herankomme. Ich habe den RAM mal auf 1.5V gestellt (ohne mich damit großartig auszukennen), weil ich gelesen habe, dass dies bereits helfen könne (s.u.)

Nun zum heutigen BSoD und der dazugehörigen Minidump. Das war das erste Mal, dass mir tatsächlich eine Datei und nicht nur ein STOP-Code angegeben wurde, weshalb ich mich auch schließlich dazu entschlossen habe, mich hier noch einmal zu melden. Nach dem blauen Teufel sei die "dxgmms1.sys" verantwortlich. Google brachte mir zum Ergebnis, dass danach höchstwahrscheinlich der Speicher die Ursache sei.
Warum meine Symbole nicht korrekt sein sollen, verstehe ich selbst nicht, aber vielleicht hilft es auch so schon weiter:
Code: 
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
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.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: fffff88013d70e7a, The address that the exception occurred at
Arg3: fffff880023e16a8, Exception Record Address
Arg4: fffff880023e0f00, Context Record Address

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

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
***                                                                   ***
***                                                                   ***
***    Your debugger is not using the correct symbols                 ***
***                                                                   ***
***    In order for this command to work properly, your symbol path   ***
***    must point to .pdb files that have full type information.      ***
***                                                                   ***
***    Certain .pdb files (such as the public OS symbols) do not      ***
***    contain the required information.  Contact the group that      ***
***    provided you with these symbols if you need this command to    ***
***    work.                                                          ***
***                                                                   ***
***    Type referenced: nt!_KPRCB                                     ***
***                                                                   ***
*************************************************************************
*************************************************************************
***                                                                   ***
***                                                                   ***
***    Your debugger is not using the correct symbols                 ***
***                                                                   ***
***    In order for this command to work properly, your symbol path   ***
***    must point to .pdb files that have full type information.      ***
***                                                                   ***
***    Certain .pdb files (such as the public OS symbols) do not      ***
***    contain the required information.  Contact the group that      ***
***    provided you with these symbols if you need this command to    ***
***    work.                                                          ***
***                                                                   ***
***    Type referenced: nt!_KPRCB                                     ***
***                                                                   ***
*************************************************************************
*************************************************************************
***                                                                   ***
***                                                                   ***
***    Your debugger is not using the correct symbols                 ***
***                                                                   ***
***    In order for this command to work properly, your symbol path   ***
***    must point to .pdb files that have full type information.      ***
***                                                                   ***
***    Certain .pdb files (such as the public OS symbols) do not      ***
***    contain the required information.  Contact the group that      ***
***    provided you with these symbols if you need this command to    ***
***    work.                                                          ***
***                                                                   ***
***    Type referenced: nt!_KPRCB                                     ***
***                                                                   ***
*************************************************************************

ADDITIONAL_DEBUG_TEXT:  
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.

MODULE_NAME: nt

FAULTING_MODULE: fffff80003260000 nt

DEBUG_FLR_IMAGE_TIMESTAMP:  521ea035

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: 
+3562643937343935
fffff880`13d70e7a ??              ???

EXCEPTION_RECORD:  fffff880023e16a8 -- (.exr 0xfffff880023e16a8)
Cannot read Exception record @ fffff880023e16a8

CONTEXT:  fffff880023e0f00 -- (.cxr 0xfffff880023e0f00)
Unable to read context, Win32 error 0n30

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x7E

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from fffff800032de709 to fffff880045757f2

STACK_TEXT:  
fffff800`00b9cc98 fffff800`032de709 : 00000000`002fc7c0 fffffa80`0536d498 fffff800`0345ecc0 00000000`00000001 : 0xfffff880`045757f2
fffff800`00b9cca0 00000000`002fc7c0 : fffffa80`0536d498 fffff800`0345ecc0 00000000`00000001 fffff800`03450e80 : nt+0x7e709
fffff800`00b9cca8 fffffa80`0536d498 : fffff800`0345ecc0 00000000`00000001 fffff800`03450e80 fffff800`032e03c7 : 0x2fc7c0
fffff800`00b9ccb0 fffff800`0345ecc0 : 00000000`00000001 fffff800`03450e80 fffff800`032e03c7 00000003`cc773a62 : 0xfffffa80`0536d498
fffff800`00b9ccb8 00000000`00000001 : fffff800`03450e80 fffff800`032e03c7 00000003`cc773a62 00000003`0005189d : nt+0x1fecc0
fffff800`00b9ccc0 fffff800`03450e80 : fffff800`032e03c7 00000003`cc773a62 00000003`0005189d 00000003`cc773a62 : 0x1
fffff800`00b9ccc8 fffff800`032e03c7 : 00000003`cc773a62 00000003`0005189d 00000003`cc773a62 00000000`0000009d : nt+0x1f0e80
fffff800`00b9ccd0 00000003`cc773a62 : 00000003`0005189d 00000003`cc773a62 00000000`0000009d fffffa80`0536d400 : nt+0x803c7
fffff800`00b9ccd8 00000003`0005189d : 00000003`cc773a62 00000000`0000009d fffffa80`0536d400 400000c2`400000c1 : 0x3`cc773a62
fffff800`00b9cce0 00000003`cc773a62 : 00000000`0000009d fffffa80`0536d400 400000c2`400000c1 fffffa80`400000c3 : 0x3`0005189d
fffff800`00b9cce8 00000000`0000009d : fffffa80`0536d400 400000c2`400000c1 fffffa80`400000c3 00000003`34f660d0 : 0x3`cc773a62
fffff800`00b9ccf0 fffffa80`0536d400 : 400000c2`400000c1 fffffa80`400000c3 00000003`34f660d0 fffff800`00b96080 : 0x9d
fffff800`00b9ccf8 400000c2`400000c1 : fffffa80`400000c3 00000003`34f660d0 fffff800`00b96080 fffffa80`03b57890 : 0xfffffa80`0536d400
fffff800`00b9cd00 fffffa80`400000c3 : 00000003`34f660d0 fffff800`00b96080 fffffa80`03b57890 00000000`00000000 : 0x400000c2`400000c1
fffff800`00b9cd08 00000003`34f660d0 : fffff800`00b96080 fffffa80`03b57890 00000000`00000000 00000f31`c11deb2a : 0xfffffa80`400000c3
fffff800`00b9cd10 fffff800`00b96080 : fffffa80`03b57890 00000000`00000000 00000f31`c11deb2a 00000f31`c11df2dd : 0x3`34f660d0
fffff800`00b9cd18 fffffa80`03b57890 : 00000000`00000000 00000f31`c11deb2a 00000f31`c11df2dd fffff800`032d8e53 : 0xfffff800`00b96080
fffff800`00b9cd20 00000000`00000000 : 00000f31`c11deb2a 00000f31`c11df2dd fffff800`032d8e53 fffff800`00b96080 : 0xfffffa80`03b57890


FOLLOWUP_IP: 
nt+7e709
fffff800`032de709 ??              ???

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  nt+7e709

FOLLOWUP_NAME:  MachineOwner

IMAGE_NAME:  ntoskrnl.exe

STACK_COMMAND:  .cxr 0xfffff880023e0f00 ; kb

BUCKET_ID:  WRONG_SYMBOLS

Followup: MachineOwner

Falls weitere Informationen gebraucht werden, liefere ich die gerne nach.

Ich hoffe auf Hilfe und bedanke mich schon mal im Voraus :)
 
Zuletzt bearbeitet:
Your debugger is not using the correct symbols
Zum Vergrößern anklicken....

Hast du einen Symbolpfad im Debugger hinterlegt? Wenn nicht, musst du das noch nachholen, ansonsten kann man mit der Auswertung nicht viel anfangen (wie das geht, kannst du z.B. hier nachlesen: Bluescreen! - ComputerBase Forum). Du kannst die Minidump aber auch gerne hier hochladen, diese kann auch an einem anderen Computer ausgewertet werden.

Allgemein kann man zu dem ausgewerteten Bluescreen sagen, dass eine Speicherzugriffsverletzung aufgetreten ist. RAM wäre somit eine mögliche Ursache für die Probleme.


Stelle noch zusätzlich die Command Rate der RAM im Bios auf "2T".
Sofern die Probleme bleiben erhöhe testweise die Latenzen (Timings) der RAM auf 10-10-10-30. Den Subtiming Wert "tRC" musst du bei den Latenzen auf mindestens 40 clocks einstellen.
 
simpel1970 schrieb:
Hast du einen Symbolpfad im Debugger hinterlegt? Wenn nicht, musst du das noch nachholen, ansonsten kann man mit der Auswertung nicht viel anfangen (wie das geht, kannst du z.B. hier nachlesen: Bluescreen! - ComputerBase Forum). Du kannst die Minidump aber auch gerne hier hochladen, diese kann auch an einem anderen Computer ausgewertet werden.
Zum Vergrößern anklicken....
Ja, habe ich eigentlich: "SRV*c:\symbols*http://msdl.microsoft.com/download/symbols" habe ich jetzt nochmal ausprobiert, was auch nichts brachte, vorher bin ich der MS-Hilfeseite gefolgt und habe die Symbole entsprechend auf eine andere Partition gelegt. Verstehe gerade auch nicht, wo da das Problem ist. Ich lade die Minidump aber zusätzlich nochmal hier hoch: Anhang anzeigen 011914-19250-01.zip
Ich habe das Problem übrigens auch in dem von dir verlinkten Forum geschildert. Weiß leider nicht, ob ich dazu hier einen Link posten darf.
 
mumpeli schrieb:
Ich habe das Problem übrigens auch in dem von dir verlinkten Forum geschildert. Weiß leider nicht, ob ich dazu hier einen Link posten darf.
Zum Vergrößern anklicken....

Das geht sicherlich in Ordnung. Dann muss man nicht alle Fragen zwei mal stellen, sondern kann sehen was schon abgefragt wurde.

Edit...habs gefunden: Regelmäßige Abstürze und Bluescreens - Analysehilfe gebraucht - ComputerBase Forum

Noch ein Edit:

mit den korrekten Symbolen wirds leider auch nicht besser/aussagekräftiger:

Code: 
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
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.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: fffff88013d70e7a, The address that the exception occurred at
Arg3: fffff880023e16a8, Exception Record Address
Arg4: fffff880023e0f00, Context Record Address

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

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

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

FAULTING_IP: 
+0
fffff880`13d70e7a ??              ???

EXCEPTION_RECORD:  fffff880023e16a8 -- (.exr 0xfffff880023e16a8)
Cannot read Exception record @ fffff880023e16a8

CONTEXT:  fffff880023e0f00 -- (.cxr 0xfffff880023e0f00)
Unable to read context, Win32 error 0n30

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT

BUGCHECK_STR:  0x7E

PROCESS_NAME:  System

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from fffff800032de709 to fffff880045757f2

STACK_TEXT:  
fffff800`00b9cc98 fffff800`032de709 : 00000000`002fc7c0 fffffa80`0536d498 fffff800`0345ecc0 00000000`00000001 : 0xfffff880`045757f2
fffff800`00b9cca0 fffff800`032cd89c : fffff800`03450e80 fffff800`00000000 00000000`00000000 fffff880`13c65588 : nt!PoIdle+0x52a
fffff800`00b9cd80 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x2c


FOLLOWUP_IP: 
nt!PoIdle+52a
fffff800`032de709 0fba25376c18000f bt      dword ptr [nt!PerfGlobalGroupMask+0x8 (fffff800`03465348)],0Fh

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  nt!PoIdle+52a

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  521ea035

STACK_COMMAND:  .cxr 0xfffff880023e0f00 ; kb

FAILURE_BUCKET_ID:  X64_0x7E_nt!PoIdle+52a

BUCKET_ID:  X64_0x7E_nt!PoIdle+52a

Followup: MachineOwner

Ein Treiberproblem ist jedenfalls aus der Auswertung nicht zu erkennen. Was aber auch nicht wirklich überrascht:

BSoD - erklärt sich praktisch von selbst, es ist aber bisher selten zwei Mal der gleiche aufgetreten.
Zum Vergrößern anklicken....

Neustart - der Rechner startet einfach vorbehaltlos neu und bleibt oftmals auch im Bootvorgang hängen, kein bestimmter Zeitpunkt feststellbar
Zum Vergrößern anklicken....

Das hört sich nicht wirklich nach Treiberproblemen an.
Bleibt also erst mal bei meinem vorherigen Vorschlag:

simpel1970 schrieb:
Allgemein kann man zu dem ausgewerteten Bluescreen sagen, dass eine Speicherzugriffsverletzung aufgetreten ist. RAM wäre somit eine mögliche Ursache für die Probleme.

Stelle noch zusätzlich die Command Rate der RAM im Bios auf "2T".
Sofern die Probleme bleiben erhöhe testweise die Latenzen (Timings) der RAM auf 10-10-10-30. Den Subtiming Wert "tRC" musst du bei den Latenzen auf mindestens 40 clocks einstellen.
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
Ich danke dir schon mal so weit. Bisher gab's noch keinen weiteren Vorfall, aber sollte dieser eintreffen, stelle ich den RAM mal entsprechend um.
 
Sooo, ich melde mich dann doch mal wieder. Erst kam wieder eine gute Woche kein Absturz mehr, dann war ich im Urlaub und hatte zu guter Letzt viel für die Uni zu tun. Währenddessen habe ich die Minidumps mal weiterhin gesammelt und hänge diesen an. Vielleicht ergibt sich dadurch ja ein konkreteres Fehlerbild, was ich jedoch irgendwie bezweifle.

Den RAM hatte ich zwischendurch mal umgestellt, das blieb allerdings erfolglos.

Derzeitig sind es wieder häufiger Freezes als Bluescreens, teilweise völlig zufällig während regulären Desktop-Betriebs und ohne Verzerrungen. Starte ich den Rechner danach neu, bleibt er oftmals im Bootscreen vom Mainboard hängen, meist mehrere Male nacheinander. Dementsprechend würde ich eigentlich wieder auf ein Spannungsproblem schließen, woran schätzungsweise das MB oder das Netzteil die Hauptschuld trägt. Aber irgendwie kann es doch nicht sein, dass seit September 2009 immer wieder in halbjährigem bis einjährigem Abstand ein ähnliches Fehlerbild auftritt, was immer auf diese Komponenten zurückführt. Seit dato habe ich das dritte Mainboard und das zweite Netzteil verbaut, immer aufgrund eines Defekts. Das kommt mir einfach spanisch vor. Zumal mich das so sehr verunsichert, dass ich am liebsten alle Komponenten austauschen würde, um der Paranoia zu entgehen, dass irgendein anderes Stück Hardware (sei es RAM, CPU oder GPU) regelmäßig den Rest zerpflückt. Dafür habe ich aber leider nicht das Geld.
 

Anhänge

  • mdumps1.zip
    74,7 KB · Aufrufe: 43
  • mdumps2.zip
    97,1 KB · Aufrufe: 38
Ein konkretes Fehlerbild ist nicht ersichtlich.

Deinstalliere testweise "damontools". Der dazugehörige Treiber taucht mehrmals verdächtig in den Stack-Verläufen auf (sptd.sys).
Bringt das noch nichts deinstalliere zusätzlich AVAST.
 
Daemon Tools habe ich mal deinstalliert, allerdings kam beim anschließenden CCleaner-Durchlauf schon wieder ein Absturz, das wird's also nicht gewesen sein. AVAST habe ich auch noch nicht so lange drauf, die Probleme waren definitiv schon vorher da. Dementsprechende würde ich das spontan auch ausschließen.
 
Wenn die Probleme auch schon vor AVAST da waren, wäre die Deinstallation wohl vergebene Mühe.

Teste dann lieber, ob das System stabil läuft, wenn nur ein RAM Riegel eingebaut ist (jeden Riegel einzeln einbauen und testen), um sicher zu gehen, dass nicht doch ein Riegel nicht 100%ig läuft und Memtest den Fehler nicht erkannt hat.
 
Offenbar war tatsächlich der Arbeitsspeicher schuld. Seitdem ich einen Riegel vor ein paar Tagen ausgebaut habe, wovor ich mich bisher aus unerfindlichen Gründen immer scheute, gab es keinerlei Abstürze oder sonstige Ärgernisse mehr. Problemlose Phasen längerer Dauer traten zwar auch vorher schon auf, aber dieses Mal habe ich den Ausbau direkt nach einem Absturz vorgenommen. Um sicher zu gehen, könnte ich nochmal beide Riegel einzeln mit M86+ und/oder P95 testen.
 
Wenn es mit dem einen Riegel fehlerfrei läuft, teste noch den anderen RAM Riegel einzeln. Treten dann wieder die Probleme auf, ist dieser Riegel defekt. Die Memtest Prüfung könntest du dir dann sparen.
 
Gesagt, getan. Mit dem anderen Riegel lief allerdings auch alles anstandslos. Hab jetzt doch nochmal Memtest an beiden Riegeln, einzeln und zusammen, angewandt. Zumindest nach einem Pass - ich weiß, das ist noch nicht so aussagekräftig - spuckte keiner der drei Tests einen Fehler aus. Einzige Auffälligkeit war die Lautstärkepräsenz des GraKa-Lüfters während des Prozesses (laut Handtest zwar warm, aber nicht heiß). Die Tests dauerten ca. 13 (einzeln) bzw. 22 Minuten (zusammen).

Ich habe jetzt beide Riegel mal drin gelassen und beobachte weiter, ob nun wieder das vorherige Fehlerbild auftritt. Dementsprechend liegt ein Spannungsproblem als Problemquelle abermals näher.
 
Zuletzt bearbeitet:
1 Pass ist nicht sehr aussagekräftig. Im Zweifel würde ich die Einzeltest je mind. 6 Std. laufen lassen.

Denkbar wäre aber auch ein Kompatibilitätsproblem (RAM - Motherboard).
Mache bitte noch mal ein paar aktuelle Screens von CPU-Z (Reiter Memory und CPU).

Ist die Command Rate noch auf 1T? Wenn ja...teste, ob die Probleme mit der Einstellung 2T bleiben (wenn auch die Einzeltests á 6 Std. keine Fehler bringen).
Falls auch mit 2T die Probleme bleiben (und die Einzeltests keine Fehler gebracht haben), erhöhe zusätzlich die RAM Spannung (in kleinen Schritten) bis max. 1,65V (angefangen bei 1,50V).
 
An den Reitern in CPU-Z (siehe Startpost im ComputerBase-Thread) hat sich jetzt nichts getan. Sobald ich eine Änderung vorgenommen habe und daraufhin trotzdem ein Absturz kam, bin ich wieder zurück auf die Standardwerte gewichen.
Und, wie weiter oben erwähnt, sind deine Tipps von mir vorher auch schon angewandt worden, blieben jedoch allesamt erfolglos.

Bisher warte ich noch auf den nächsten Absturz.
 
mumpeli schrieb:
Und, wie weiter oben erwähnt, sind deine Tipps von mir vorher auch schon angewandt worden, blieben jedoch allesamt erfolglos.

Bisher warte ich noch auf den nächsten Absturz.
Zum Vergrößern anklicken....
Nur mal so am Rande:
Ich hatte beim PC meiner Frau vor langer Zeit ein ähnliches Verhalten.
Letztendlich hab ich dann bei beiden RAM-Riegeln lediglich die Kontakt-Flächen gereinigt und seitdem trat nie wieder ein Problem auf.
 
simpel1970 schrieb:
Welche Spannungsbereiche (RAM) hast du schon getestet? Bist du bis 1,65V (max) gegangen?
Zum Vergrößern anklicken....
Das weiß ich, ehrlich gesagt, nicht mehr so genau, aber ich meine schon, dass ich 1,65V eingestellt hatte. Ich werd's nach dem nächsten Absturz wohl doch nochmal testen...:d

DerWolf schrieb:
Nur mal so am Rande:
Ich hatte beim PC meiner Frau vor langer Zeit ein ähnliches Verhalten.
Letztendlich hab ich dann bei beiden RAM-Riegeln lediglich die Kontakt-Flächen gereinigt und seitdem trat nie wieder ein Problem auf.
Zum Vergrößern anklicken....
Ja, die Vermutung kam mir beim Rumgestöpsel auch auf, bzw. dass ein Slot Staub gefressen haben könnte. Habe allerdings nur mal sporadisch durchgepustet und die Riegel etwas abgewischt. Vielleicht war das tatsächlich schon das Problem.
 
mumpeli schrieb:
Habe allerdings nur mal sporadisch durchgepustet und die Riegel etwas abgewischt.
Zum Vergrößern anklicken....
Ich hab eseinerzeit die RAM-Kontakte mit einem Radier-Gummi gereinigt. Also in Kontakt-Richtung und auch quer dazu vorsichtig drüberrubbeln.
Und -wie gesagt- seitdem nie wieder Probleme gehabt.

Ich drück die Daumen, dass das bei Dir auch so sein wird.
 
Anmelden, um zu antworten.
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