falls noch nicht erstellt / bekannt ....
"Endlich: Out of Memories im Griff: Nachdem ich mir die vergangenen Nächte um die Ohren gehauen habe bin ich nun sehr zuversichtlich, ein Serum gegen die gefürchteten "out of memory" Fehler gefunden zu haben, wie sie beim Zusammenspiel hoher Detaileinstellungen und komplexer Add Ons in letzter Zeit immer häufiger auftreten. Ich will das hier nicht als meine Idee verkaufen, aber ich habe aus einer vielzahl an Tipps und Forenbeiträgen letztlich wohl das herausgefiltert, was endlich funktioniert. Des Rätsels Lösung liegt darin, dass weder die FS9.exe noch die FSX.exe so programmiert wurden, dass sie Anfragen an den virtuellen Speicher von Windows (XP und Vista) in einem Rahmen halten, wie sie vom Betriebssystem auch verarbeitet werden können. Da diese Begrenzung innerhalb der Anwendungen fehlt, gerät Windows in Panik und macht den Sack zu - OOM.
Der Grund, weswegen dieses Problem in letzter Zeit häufiger auftritt, ist nicht etwa der berüchtigte "Oktoberbug". Immer mehr User verfügen inzwischen über leistungsfähige Hardware, die derart hohe Einstellungen erst möglich bzw. sinnvoll macht! Vorher geriet das Betriebssystem nicht in die Situation, in die wir es jetzt durch die schlagartig gesteigerten Anforderungen bringen. Diese Anforderungen stellen nicht nur wir User in Form von "alle regler rechts", sondern auch Add Ons, die sich angesichts besser werdender Hardware-Ausstattungen immer mehr trauen, gesteigerte Ressourcenansprüche zu stellen.
Für Windows Vista gibt es seit einiger Zeit einen Patch von Microsoft, dier dieses Problem behebt. Auch wird mit SP2 des FSX die FSX.exe automatisch so angepasst, dass sie beim Betriebssystem höhere VM Anforderungen stellen kann.
Nun gibt es zwei Taktiken, dem OOM-problem entgegenzuwirken.
1) Man sorgt dafür, dass es gar nicht erst zu zu hohen Anfragen beim Betriebssystem kommt
2) Man setzt Betriebssystem und *.exe Datei an einen Tisch und zeigt beiden, wie sie das Problem gemeinsam meistern können.
Bei Variante 1), zu der es inzwischen unzählige Tipps und Tricks nachzulesen gibt, wird das Problem nicht wirklich behoben. Man erkauft sich einen stabilen FS mit dem Verzicht auf hohe Detailstufen, im Extremfall sogar auf ganze Add Ons (Super 80, Yak 40, Heathrow 200.
Variante 2) ist sehr viel sinnvoller, denn sie beseitigt die Kommunikationsschwierigkeiten zwischen Anwendung und Betriebssystem, sie den OOM verursachen.
Funktionsweise:
Offiziell funktioniert dieser Tweak nur mit Systemen, die 2GB oder mehr an Bord haben. Es gibt aber zahlreiche Rückmeldungen, dass es auch mit weniger RAM funktionieren soll - man kann es gefahrlos ausprobieren, mehr als einen Bluescreen wird es nicht geben, und die Veränderung kann jederzeit problemlos rückgängig gemacht werden.
Auch sollte Directx 9c installiert sein, da es sonst zu Anzeigefehlern kommen kann.
Trotzdem und in aller Klarheit: jeder probiert das hier auf eigene Gefahr aus!
Die Umstellung erfolgt in zwei Schritten. Schritt eins weist Windows XP an, mehr als 2GB an virtuellem Speicher zur Verfügung zu stellen. Schritt zwei teilt den einzelnen Anwendungen mit, wie sie die Anfrage nach mehr VM beim Betriebssystem stellen können, ohne dass dieses panisch den Sack zumacht.
Der eine oder andere wird bereits mal etwas darüber gelesen haben, allerdings sind mir keine wirklich vollständigen Anleitungen unter gekommen, schon gar nicht in deutscher Sprache.
Schritt 1:
Download des Programms "4GB Patch" HIER: http://ntcore.com/4gb_patch.php
Anfertigung einer Sicherheitskopie der Datei FS9.exe
Dann mit dem runtergeladenen Tool die FS9.exe öffnen und patchen. Das Tool ist idiotensicher und absolut selbsterklärend!
Der FS weiß jetzt, dass er nach mehr virtuellem Speicher fragen darf und wie er das anstellen soll. Nun muß Windows XP noch mitgeteilt werden, dass eine solche Anfrage von Programmen kommen kann und das es sich dann nicht erschrecken soll:
Schritt 2:
Gebt unter Windows XP bei "Ausführen" sysdm.cpl ein und bestätigt mit OK.
Dann klickt auf die Registerkarte Erweitert, dann unter Starten und Wiederherstellen auf Einstellungen.
Dann unter Systemstart auf Bearbeiten. Daraufhin wird die Datei zum Bearbeiten in Editor geöffnet.
Hier erscheint ein Text der diesem hier sehr ähneln sollte, vielleicht ist er auch identisch:
[boot loader]
timeout=30
default=multi(0)disk(1)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(1)rdisk(0)partition(1)\WINDOWS="Windows XP Professional" /fastdetect
In der grünen Zeile schaut Windows beim Systemstart nach, wie es gestartet werden soll. Sind mehrere Betriebssysteme installiert oder mehrere Varianten eines Betriebssystems, so tauchen diese hier in Form mehrerer solcher Zeilen auf.
Damit sich Windows fortan nicht mehr erschreckt, wenn ein Programm nach mehr virtuellem Speicher schreit, fügt der grünen Zeile den roten Text hinzu. NICHT vertippen!
[boot loader]
timeout=30
default=multi(0)disk(1)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(1)rdisk(0)partition(1)\WINDOWS="Windows XP Professional" /fastdetect /3GB /userva=2560
Speichert die Datei, schliesst alle Fenster und startet den Rechner neu.
WICHTIG
Wer Cloud9 Produkte nutzt, kann momentan diese nicht verwenden während der Tweak aktiv ist. Die gilt aber NUR für die modifizierte FS9.exe. Um in einer FS-Session ein Coud9 Produkt zu benutzen, muss die veränderte FS9.exe in FS9.mod umbenannt werden und das unmodifizierte Backup ins Hauptverzeichnis des FS kopiert werden.
Will man keine Cloud9 Produkte nutzen, muss die Datei bglman.dll im Modules-Verzeichnis mit einer Umbenennung in bglman.off für die Sitzung deaktiviert werden.
Ich habe Cloud9 darüber informiert und man stellte mir in Aussicht, sich des Problems anzunehmen.
Nachträgliche Ergänzung:
Ein ähnliches Problem wie mit Cloud9 gibt es leider ausgerechnet mit der Yak-40 von Suprunovdesign. Diese hat eine Kopierschutzabfrage innerhalb der Gaugedatei, die sich leider auch durch die geänderten Adressbereiche verschaukelt fühlt und das Flugzeug für die Benutzung sperrt - mit dem Hinweis, der Key sei falsch. Dieser Zustand besteht aber NUR, wenn der FS mit der veränderten *.exe Datei gestartet wird. Startet man den FS wieder mit der unveränderten fs9.exe, funktioniert die Yak wieder wie gewohnt. Eine erneute Eingabe des Keys ist nicht nötig.
Ich habe Igor darauf hingewiesen und denke mal, dass er uns da entgegenkommen wird, denn schließlich betrifft das OOM Problem ja auch sein Produkt.
Das gleiche Problem ist mit der Saab Safir zu erwarten, da sie einen sehr ähnlichen Kopierschutz besitzt. Da diese aber in keiner weise von OOMs betroffen ist kann man sie auch über die unveränderte fs9.exe problemlos betreiben.
Weiterer Nutzen
Bei einigen wird der FS nicht die einzige Anwendung sein, die von diesem Tweak profitiert. Besonders Videoschnittprogramme, Renderer, Converter und Audiosoftware kann ebenso "gepimpt" werden. Sicherheitskopie nicht vergessen, bevor ihr die exe modifiziert!
Für Rückmeldungen bin sicher nicht nur ich dankbar! "
Quelle: Meatwater (ex. FXP-Forum)
