Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
GTA 5GTA stürzt ununterbrochen ab und oftmals an sehr "tollen" stellen
Jede GPU (und jede andere HW Komponente) hat in der Registry einen eigenen Subtree, der durch ihre HW-ID eindeutig identifiziert wird. Systemnahe Einstellungen, die Du oder der Treiber für die eine GPU eingestellt hast, beziehen sich nur auf genau diese HW und nichts anderes.
Was ihr verbreitet sind Mythen, nichts weiter.
Es kann sicherlich in einzelnen, seltenen Fällen vorkommen, dass irgendeine SW klemmt - schließlich kann jede SW Fehler haben. Aber das ist wie gesagt SELTEN.
Und was macht Euch eigentlich denken, dass DDU fehlerfrei wäre? Ihr lasst dieses Tool in den Eingeweiden Eures Systems rumwüten, ohne dass die DDU Entwickler wirklich interne Kenntnisse über den Treiber und seine Struktur haben, und evtl. eine neue Treiberversion noch gar nicht selbst gesehen und probiert haben!
Das ist echt Harakiri! Denkt doch mal einfach logisch nach!
Deinstalliert den alten Treiber und gut ist. Mehr ist einfach nicht notwendig und DDU et. al. sind wirklich richtig gefährlich. Das liegt in der Natur der Sache!
Dieses Misstrauen gegen SW von Herstellern und Gottvertrauen in Third-Party Tools aus dem Netz werde ich NIE verstehen.
Ergänzung ()
Wie kann man nur auf die Idee kommen, ein Third-Party Tool wüsste es besser? Und hat niemals einen Fehler? Mannomann.
1. Habe ich garnicht von der GPU gesprochen. Sondern vom Chipsatz und der setzt wohl etwas systemweitere Einstellungen als die Sub-Tree für die Graka. Wenn deine Mainboard-Wechsel ohne Treiberneuinstallationen immer glatt ging, Glückwunsch. Aber sprich anderen nicht ihre Erfahrungen ab.
Das beim Mainboard Wechsel uU Windows den Treiber nichtmal automatisch neu installiert, hast Du gelesen?
2. Zum Thema DDU habe ich ebenfalls nichts geschrieben.
Ihr solltet hier mal von dem Gedanken wegkommen das es an dem Ram oder anderen Dingen liegen könnte. Denn wenn das der Fall wäre würde ich ja generell auch Probleme in anderen Situationen haben. Das ist allerdings nicht der Fall. Es geht explizit um GTA Online.
Ich glaube ich hab den Fehler sogar schon selbst gefunden, wenn es der Fehler war lag es auch nicht an der Hardware.
Das ist kein Argument. Es kann immer sein, dass GTA das System auf eine ganz bestimmte Art stresst und sonst alles andere geht.
Irgendwann kommt mal Spiel xy und crashed auch - auch wenn nur 1% aller Spiele crashen, so ist dann trotzdem ein Problem im System, entweder in der HW (wahrscheinlich) oder in der SW, also Windows oder Treiber (nicht so wahrscheinlich)
Ergänzung ()
Sun_set_1 schrieb:
1. Habe ich garnicht von der GPU gesprochen. Sondern vom Chipsatz und der setzt wohl etwas systemweitere Einstellungen als die Sub-Tree für die Graka. Wenn deine Mainboard-Wechsel ohne Treiberneuinstallationen immer glatt ging, Glückwunsch. Aber sprich anderen nicht ihre Erfahrungen ab.
Das beim Mainboard Wechsel uU Windows den Treiber nichtmal automatisch neu installiert, hast Du gelesen?
2. Zum Thema DDU habe ich ebenfalls nichts geschrieben.
Für einen MB-Wechsel gilt prinzipiell das gleiche, wie ich geschrieben habe. Auch alle MB Komponenten haben jeweils eigene Branches in der Registry.
Früher gab es Probleme, weil alte Windows-Versionen oft einfach Treiber für bestimmte Komponenten gar nicht installiert hatten, und deswegen der Rechner nicht auf dem neuen MB gebootet haben. Aber das ist heute kaum noch ein Problem.
Dennoch würde ich bei einem MB Wechsel tatsächlich auch Windows neu installieren, alleine um dann den ganzen Müll loszuwerden und weil man sein Windows ja eh neu aktivieren muss.
Ja, und? Und jeder Chipsatztreiber ändert auch Einstellungen in den HKLM\System-Klassen, die Allgemeingültig sind für den Kernel. Und wenn da nen DWORD vom 300er Chipsatz gesetzt ist, der ggf für den 500er in gewissen Umständen problematisch sein kann, dann muss man sich darauf verlassen dass dieser Wert dann vom Treiber auch proaktiv ohne Neuinstallation gelöscht wird.
Wenn Du glaubst das passiert immer mit 100%iger Genauigkeit, hast Du entweder nie selbst programmiert oder verbreitest eben selber Mythen.
Fehler ist tatsächlich behoben, es lag also wie bereits von mir geahnt nicht an der Hardware. Ich konnte eben 40 Minuten ohne Crash mein Tagesziel mit beiden Chars beenden.
Grestorn schrieb:
... würde mich nicht wundern, wenn er einfach ein OC Profil aktiv hatte. Entweder für die GPU oder CPU.
Fehler ist tatsächlich behoben, es lag also nicht wie bereits von mir geahnt nicht an der Hardware. Ich konnte eben 40 Minuten ohne Crash mein Tagesziel mit beiden Chars beenden.
muss ich es eher so machen wie du? 90% der Kommentare hier sind off topic weil du einfach eine falsche Meinung hast. Das liegt nicht an meinem ersten Beitrag sondern daran das du hier als Tipps etwas nennst das schlichtweg falsch ist. Mache ich mich so beliebter ? Dann lerne ich von dir !
Ja, und? Und jeder Chipsatztreiber ändert auch Einstellungen in den HKLM\System-Klassen, die Allgemeingültig sind für den Kernel. Und wenn da nen DWORD vom 300er Chipsatz gesetzt ist, der ggf für den 500er in gewissen Umständen problematisch sein kann, dann muss man sich darauf verlassen dass dieser Wert dann vom Treiber auch proaktiv ohne Neuinstallation gelöscht wird.
Wenn Du glaubst das passiert immer mit 100%iger Genauigkeit, hast Du entweder nie selbst programmiert oder verbreitest eben selber Mythen.
Na, wenn Du meinst. Bin verdien ja nur seit gut 30 Jahre mit SW Entwicklung mein Geld
Und welche Registry-Werte meinst Du denn, die ein Chipsatztreiber Deiner Meinung nach auf irgendwelche global gültigen Werte setzt? Butter bei die Fische, wenn Du so was behauptest!
muss ich es eher so machen wie du? 90% der Kommentare hier sind off topic weil du einfach eine falsche Meinung hast. Das liegt nicht an meinem ersten Beitrag sondern daran das du hier als Tipps etwas nennst das schlichtweg falsch ist. Mache ich mich so beliebter ? Dann lerne ich von dir !
Also wir wissen zum Einen immer noch nicht, woran es lag. Also wenn morgen jemand das gleiche Problem hat, dann können wir ihm nicht helfen. Tolle Sache...
Und da wir nicht besonders viele Infos von dir bekommen haben, bekommst du halt von uns erstmal die 3* häufigsten Fehlerbehebungsvorschläge.
Dann sollte es gerade Dir doch bekannt sein, was für ein stetiges und großes Problem es ist, dass die Entwickler ihren Code zum Schluss nicht sauber aufräumen...?
Und welche Registry-Werte meinst Du denn, die ein Chipsatztreiber Deiner Meinung nach auf irgendwelche global gültigen Werte setzt? Butter bei die Fische, wenn Du so was behauptest!
Die gesamte Klasse unter HKLM\SYSTEM\Control Sets zum Beispiel?
"HKLM\SYSTEM\Control Sets" containing alternative configurations for system hardware drivers and services running on the local system (including the currently used one and a backup), a "HKLM\SYSTEM\Select" subkey containing the status of these Control Sets, and a "HKLM\SYSTEM\CurrentControlSet" which is dynamically linked at boot time to the Control Set which is currently used on the local system. Each configured Control Set contains:
[...]
a "Hardware Profiles" subkey enumerating the various profiles that have been tuned (each one with "System" or "Software" settings used to modify the default profile, either in system drivers and services or in the applications) as well as the "Hardware Profiles\Current" subkey which is dynamically linked to one of these profiles.
Dann sollte es gerade Dir doch bekannt sein, was für ein stetiges und großes Problem es ist, dass die Entwickler ihren Code zum Schluss nicht sauber aufräumen...?
Klar weiß ich das, aber wenn irgendwer es am besten weiß, wie man den Treiber sauber entfernt, und das auch am besten getestet hat - und auch den meisten Ärger hat, wenn es nicht klappt - dann ist das der Treiberhersteller selbst.
Ganz bestimmt keine externe Klitsche die letztlich nur mit Trial-and-error arbeiten kann. Wenn die irgendwas falsch auf die Reihe bekommen, ist Dein System tot. Man liest immer wieder, dass das Treibermodell nach einer Behandlung durch ein solches Tool derart beschädigt ist, dass einfach GAR keine Treiberinstallation mehr funktioniert (wohl dem, der dann einen Systemwiederherstellungspunkt hat).
Sun_set_1 schrieb:
Die gesamte Klasse unter HKLM\SYSTEM\Control Sets zum Beispiel?
In CurrentControlSet werden in der Tat alle möglichen HW-nahen und Systemweiten Einstellungen hinterlegt. Aber auch in den Keys da drunter gilt: Treibereinstellungen werden immer unter der HW-ID der jeweiligen HW gespeichert. So stellt das System sicher, dass auch die selbe HW (mit den selben Treibern!) mehrfach im System vorhanden sein kann und dennoch getrennt konfiguriert werden kann.
Erwischt. Hab den falschen Pfad aus dem Text kopiert.. aber ich denke es war klar, was gemeint war
Grestorn schrieb:
In CurrentControlSet werden in der Tat alle möglichen HW-nahen und Systemweiten Einstellungen hinterlegt. Aber auch in den Keys da drunter gilt: Treibereinstellungen werden immer unter der HW-ID der jeweiligen HW gespeichert.
Ich weiß, wie das in der Theorie funktionieren sollte. Ich sage aber, dass ich das durchaus im Bereich des Möglichen halte, dass es auch AMD oder Intel passieren kann, dass diese eben einfach die HW-ID eines neuen Chipsatzes unter einer alten Konfiguration gültig stellen.
Sprich neuer Chipsatz -> Windows merkts, prüft den Treiber -> Treiber sagt passt soweit -> ich adde die HW-ID in den Stacks, tausche sie aus, oder kopiere den Stack und tausche in dem kopierten Stack die ID's aus.
Die ganzen kleinen schmutzigen Tricks, die einem als Programmierer halt das Leben erleichtern - aber äußerst fehleranfällig sind.
Während wir uns ja technisch soweit einig sind glaube ich, dass der Unterschied ist:
Du sagst sowas passiert Firmen wie AMD / Intel schlicht aufgrund der internen QM-Prozeduren nicht mehr.
Ich sage: Ich glaube das passiert weiterhin hundertfach, nur fallen von 100 Bugs, 99 idR nicht auf.
Ich erinnere nur an das hochqualitative Intel Driver Management Tool von 2000 - ca 2010.
Das hat bei HW-Wechsel mehr kaputt gemacht, als es geholfen hat
Aber nochmal, wieso traust Du dann Tools wie DDU so blind? Ohne Not?
Ich meine, wenn man wirklich ratlos vor der Wand steht, nichts geht mehr und man nicht mehr weiterweiß, kann man es ja mal auch mit so einem Tool vesuchen, dann kann es ja nicht mehr schlimmer werden. Aber auch dann würde ich vorher auf die diversen Troubleshoot-Tools von MS zurückgreifen, die den Treiberlayer und andere Windows-Komponenten reparieren (nicht selten nachdem sie durch Third-Party Tools beschädigt wurden).
Aber viele empfehlen Tools wie DDU u.ä. grundsätzlich, bei jedem HW-Wechsel, manche sogar bei jedem Treiberupdate. Das ist schlicht Harakiri.
Mache ich doch garnicht?
DDU habe ich das letzte mal irgendwann Anfang der 2000er für Graka Wechsel NVIDIA / ATI benutzt. Damals waren die De-/Installationsroutinen wirklich ein Graus.
Aber in dem Thread habe ich das mit keinem Wort erwähnt, das waren andere auf der ersten Seite
Ich bin nur nen Verfechter davon, spätestens bei Mainboard-Wechsel, Windows einmal frisch und nackt aufzusetzen. Mehr nicht.
