Was für ein Betriebssystem verwendest Du? Weil 32Bit OS kann mit 4GB nicht wirklich sauber umgehen.
Des weiteren ist die Frage, wie Du im BIOS "Memory Remap" auf "Enabled" gestellt hast. Weil das wär auch nötig.
Werden Dir die 4GB im Betriebssystem überhaupt sauber angezeigt?

Pfuh... 32Bit Betriebssystem und 4GB RAM. Ich bild mir ein da greift XP zu ein paar abenteuerlichen Methoden um zumindest die 3,63GB sichtbar zu machen.
Das Maximus Extreme kann auf jeden Fall Memory Remap, aber das bringt bei 32Bit sowieso nichts, also egal.

Was für einen "4GB-Patch" meinst Du eigentlich?

Ich habe das gleiche Problem gehabt, dann bin ich auf
Vista64Bit umgestiegen, seit dem habe ich "Ruhe im Karton"! Allerdings
möchte ich im jetzigen Zeitpunkt zu bedenken geben, dass Windows 7 bald kommen
wird und nach der bisherigen Berichten zu urteilen, soll wesentlich besser sei,
als Vista.

Hallo ArezOne!

Schau doch mal in diesen Link FSX ES steht nich genug Arbeitsspeicher zur verfügung... ob Du den Patch

Zitat

Hotfix für Windows (KB940105)

hast...

Edit:
Oh, ich sehe gerade der scheint nur für Vista verfügbar zu sein?!?
http://www.drwindows.de/vista-updates-an…ikspeicher.html
auch keine Version für XP. Tut mir leid...

Unter 32 Bit werden 4GB RAM niemals wirklich sauber funktionieren, weil es ein grundlegendes Architekturproblem ist (und mitunter auch der Grund weswegen das 64Bit Computing überhaupt erfunden wurde).
Das kann man irgendwie womöglich grade so hinbiegen dass es halt irgendwie ansatzweise hinhaut, aber von korrektem Funktionieren wird man da nie wirklich sprechen können.

Die boot.ini Sachen die Du gemeint hast wären folgende:

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Home" /fastdetect /NoExecute=OptIn

füge "/3GB /userva=2560" ans ende der Zeile hinzu:

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Home" /fastdetect /NoExecute=OptIn /3GB /userva=2560

Man kann statt 2560 auch 2816 nehmen, das muss man austesten.
Trotzdem würd mich interessieren, was für einen angeblichen 4GB Patch Du installiert haben willst, weil wir haben ja bereits rausgefunden, dass es den für XP nicht gibt.

Und dass es bei anderen läuft ist schön, die haben aber nicht den gleichen Rechner wie Du.
Du kannst alternativ mal testen einen GB-Riegel rauszunehmen und "nur" 3GB zu verwenden, das könnte auch helfen. Das grundlegende Problem liegt einfach darin, dass 32Bit Betriebssysteme nur 4GB Speicher addressieren können, da darf man aber den Grafikspeicher usw schon alles mitrechnen, sprich wirkliche 4GB reines RAM wirds unter 32Bit niemals spielen.

Zitat von »ArezOne«

anderen läuft es doch auch mit 32 bit und 4GB RAM

Auch ich habe WinXP und 4 GB RAM, doch das Betriebssystem kann davon "nur" etwa 3.2 GB nutzen ... immerhin.

Allenfalls können (fortschrittliche?) Programme sogar unter WinXP mehr (als 3.2 GB) davon nutzen, aber ich habe es noch nie selber getestet oder gesehen.

Eine einzelne Applikation kann nie mehr als 2GB RAM für sich beanspruchen unter 32Bit. Es gibt ein paar umständliche Ausnahmen, aber es geht an sich nicht wirklich.
Das mit den 3-Komma-Irgendwas zahlen im XP rührt daher, dass in den Adressraum vom RAM auch noch der Grafikspeicher mit ein wenig Verwaltungsoverhead reingemappt wird.
Etwas mehr als man tatsächlich drinhat, weil Überlagerungen tötlich wären und alles sofort abstürzt wenn man auf diese Bereiche zugreifen würde.

Das mehr an Speicher hat aber halt den Vorteil, dass die 2GB wirklich die Applikation für sich hat und wenigstens alle andere sich im Rest aufhalten kann.
Es ist nicht nur OS-abhängig, sondern auch eine Applikation muss mit 64Bit umgehen können, damit sie sich mehr Speicher untern Nagel reissen kann.
Ich kann im 64er OS zwar soviele 2GB-RAM-fressende 32-Bit Apps nebeneinander laufen lassen wie mein Speicher zulässt, aber wenn ich will dass eine App auch >2GB verwenden kann, dann muss auch die App mit 64Bit umgehen können (die Pointer werden länger usw). Das ganze kann man noch weiter verkomplizieren indem man in die Betrachtung das Multithreading mit reinnimmt, aber ab da wirds dann ziemlich wahnsinnig.

Zitat von »mhe«

Unter 32 Bit werden 4GB RAM niemals wirklich sauber funktionieren, weil es ein grundlegendes Architekturproblem ist (und mitunter auch der Grund weswegen das 64Bit Computing überhaupt erfunden wurde).
Das kann man irgendwie womöglich grade so hinbiegen dass es halt irgendwie ansatzweise hinhaut, aber von korrektem Funktionieren wird man da nie wirklich sprechen können.

Sorry, aber das ist ziemlich großer Unsinn, den du hier schreibst. Es gibt unzählige Systeme, welche hardwaremäßig 4 GB RAM verbaut haben, jedoch ein 32-bit-Betriebssystem verwenden. Und das funktioniert bei allen tadellos. Es spricht auch überhaupt nichts dagegen, daß das nicht funktionieren kann, weil eben ein Teil des RAM einfach ungenutzt bleibt. Das Betriebssystem adressiert den RAM soweit, wie es kann (3,63 GB sind da durchaus eine gängige Größe), der restliche Speicher bleibt einfach ungenutzt. Da können auch keine Daten verschwinden oder sonstwas, dieser Teil des Speichers wird einfach ignoriert. Da braucht man auch nichts hinbiegen und nichts.

Desweiteren adressiert Windows nur Speicher, den es auch tatsächlich hat. Einen "Verwaltungsoverhead", der nicht vorhanden ist, kann vom Betriebssystem auch nicht adressiert werden. Überlagerungen kann es auch nicht geben, da die Adressen eindeutig vergeben werden.

Und dann würde ich auch gerne mal den Zusammenhang zwischen Multithreading und 32-bit-Applikationen auf einem 64-bit-System kennenlernen, der so wahnsinnig kompliziert ist.

Zum Thema: Prüfe mal deinen Arbeitsspeicher mit Memtest86+, ob alle Riegel intakt sind.

Zitat von »Stef«

Sorry, aber das ist ziemlich großer Unsinn, den du hier schreibst. Es gibt unzählige Systeme, welche hardwaremäßig 4 GB RAM verbaut haben, jedoch ein 32-bit-Betriebssystem verwenden. Und das funktioniert bei allen tadellos. Es spricht auch überhaupt nichts dagegen, daß das nicht funktionieren kann, weil eben ein Teil des RAM einfach ungenutzt bleibt. Das Betriebssystem adressiert den RAM soweit, wie es kann (3,63 GB sind da durchaus eine gängige Größe), der restliche Speicher bleibt einfach ungenutzt. Da können auch keine Daten verschwinden oder sonstwas, dieser Teil des Speichers wird einfach ignoriert. Da braucht man auch nichts hinbiegen und nichts.

Desweiteren adressiert Windows nur Speicher, den es auch tatsächlich hat. Einen "Verwaltungsoverhead", der nicht vorhanden ist, kann vom Betriebssystem auch nicht adressiert werden. Überlagerungen kann es auch nicht geben, da die Adressen eindeutig vergeben werden.

Und dann würde ich auch gerne mal den Zusammenhang zwischen Multithreading und 32-bit-Applikationen auf einem 64-bit-System kennenlernen, der so wahnsinnig kompliziert ist.

Zum Thema: Prüfe mal deinen Arbeitsspeicher mit Memtest86+, ob alle Riegel intakt sind.

Der Adressraum Overall ist 4GB gross. Von den 4GB subtrahieren wir mal Grafikspeicher. Davon bleibt dann wieviel übrig? Es gibt natürlich mechanismen wie PAE, aber die funktionieren mit Anwendungen wie Spielen halt nicht wirklich ideal, weil sie in einigen Fällen die Performance leiden lassen können. Dass Daten verschwinden können hat übrigens auch niemand behauptet. Dass es keine Overlaps geben kann ist in der Theorie zwar richtig, aber in der Praxis ist die Sicherheit dass dem so ist von der Qualität von verwendeter Software und Hardware abhängig. Warum kommts denn zu den illegal operations beim Speicher? Warum gibts ein OOM bei eingebauten 4GB RAM wo andere mit 2GB das Problem nicht haben?
Tatsache ist, dass Rechner mit 4GB RAM auf 32Bit niemals so stabil laufen wird wie auf 64, einfach weil die Grenzen architekturbedingt sind. Das ist Erfahrung und wird man weder wissenschaftlich beweisen können noch jemals wollen.
Man kann ja einfach die Probe machen, den Rechner auf 2GB runterschrauben und schauen obs dann noch immer zum besagten Problem kommt, das wäre der pragmatische Ansatz.

Lösen wir das einfach simpler. Stef, ich hab hier Lesestoff für Dich, das erklärt viel besser was ich meine als ich das jemals hier könnte (ich wollte nur nicht das ganze soweit treiben dass wir hier den Leuten die Unterschiede zwischen kernel space und user space erklären müssen etc).

A Messy Transition: Practical Problems With 32bit Addressing In Windows (AnandTech)
A Messy Transition (Part 2): Windows XP, Vista, and the 2GB Barrier (AnandTech)

Mir sind diese Artikel durchaus schon bekannt, jedoch kann ich deine Erfahrung hinsichtlich des instabileren Betriebes von Win 32-bit mit 4 GB nicht teilen. Ich baue ja nun selbst eine Menge Rechner zusammen (seit bestimmt zwei Jahren ausschließlich mit 4 GB RAM), für die ich natürlich auch geradestehen muß. Mir ist nicht ein einziger Problemfall bekannt bisher, wo Windows mit der Speicherausstattung Probleme bekommt. Mein Windows-"Versuchsrechner" (der mit dem Flusi) ist selbst auf 4GB mit XP 32-bit ausgebaut und muß wirklich viel über sich ergehen lassen - ebenfalls bisher ohne jegliche Probleme (von einem defekten Speicherriegel einmal abgesehen, aber der funktionierte gar nicht mehr). So unterschiedlich können wohl Erfahrungen sein.

Übrigens finden sich auch in der Fachpresse (zu der auch die verlinkte Seite gehört für mich) nur sehr wenig Problemfälle mit 4 GB beim 32-bit-OS.

@Arezone: Sorry, daß unsere Diskussion nicht wirklich bei deinem Problem hilft.

Zitat von »mhe«

Das kann man irgendwie womöglich grade so hinbiegen dass es halt irgendwie ansatzweise hinhaut, aber von korrektem Funktionieren wird man da nie wirklich sprechen können.

Das Problem existiert hauptsächlich garnicht, es ist völlig egal, ob ein 32bit OS oder ein 64bit OS auf die 4GB zugreift, das ist mal so, denn es gibt immer wieder welche, die Probleme mit dem RAM oder dem Rechner haben, aber die PAE bei 32bit zu überlisten ist sicherlich ein Trick, der nicht funktioniert, und einem 32bit OS die Stabilität abzusprechen aufgrund 4GB ist sicherlich ein weiterer Trick, der aber weniger mit der Realität zutun hat - allerdings ist der Grund für die OOMs in Wirklichkeit eher woanders zu suchen ...

Wieviele Rechner laufen fehlerfrei mit 4GB und 32bit ? Tausende, unzählige, hab selber einen, der hat 8GB RAM und läuft mit HDD-Schubladen über XP32 und 64 und Vista32 und 64 - alles mit einem einzigen System - OOM ? Weit gefehlt - die verhältnismäßig wenigen, die wirklich Probleme damit haben, die nutzen Vista oder XP ohne SPs oder haben das System nicht optimal - jedoch wird halt der Adressraum bei 32bit nur bis ~3,5GB nutzbar und selbst mit aktiviertem PAE im BIOS ist keine erweiterte Nutzung möglich ...

Jetzt sehen wir aber auch mal die andere Seite - Ein user, oder mehrere User haben z.B. ein Vista32bit mit 4GB und OOMs, jetzt kaufen die sich einfach Vista64bit und OOM ist weg - ergo - Sagen die halt aus: "Mit 32bit geht´s nicht" - und das Internet ist mal eben ziemlich voll von den Nachrichten, wenn man jetzt jeden, der keine Probleme mit Vista32 und OOMs hat, zwingen würde seine Erfolgsstory "32bit und 4GB - Kein Problem" zu veröffentlichen, dann hätte man halt Schwierigkeiten die subjektiven OOM-Problem-Berichte zu finden, das gleiche gilt auch für XP, deshalb kann ich Deine Ausführungen auch gut nachvollziehen ...

Denk nur mal an die vielen Experten, die bei Vista mit allen SPs noch die boot.ini gepimpt haben mit dem "3GB Schalter" und danach "Erfolge" beschrieben haben ...

Zitat von »ArezOne«

Dieser Patch wurde eben aus dem Grunde released wenn man mehr als 2 GB auf dem Bord hat.

Allegemein ist es so:

Wenn man alle Vista Servicepacks installiert hast, dann braucht man den Patch eigentlich nicht, aber falls jemand nachsehen will, ob der nötig sein sollte, dann schaut mal HIERnach ...

Diese Boot.Ini-geschichte, die angesprochen wurde, also die mit dem Schalter /fastdetect /3GB /Userva=2560, die braucht man bei Vista eigentlich nicht

Bei XP siehts da anders aus

Eine Geschichte hab ich da aber noch im Hinterkopf, da war etwas mit dem Deaktivieren der Auslagerungsdatei ... Versuche das Ganze mal mit dem Deaktivieren der Auslagerungsdatei... Danach den Rechner neu starten, FSX starten und testen ...

Ansonsten Google mal nach /fastdetect /3GB /Userva=2560 - Dort wirst Du jede menge an Seiten finden, die den 3GB-Schalter erklären, denn der könnte Dir helfen weil damit die 2GB-Limitierung eines Programms geändert wird

Der /3GB Switch macht nichts anderes als den Split der 4GB in der Hälfte (2GB Kernelspace und 2GB Userspace) zugunsten einer Applikation zu verschieben. Dann sinds 1GB Kernelspace und 3GB Userspace.
Das KANN funktionieren, muss aber nicht, weil es zb einige Treiber gibt, die davon ausgehen dass der Kernelspace immer 2GB gross ist -> mögliche Instabilität.
Des weiteren muss auch das ausgeführte Binärfile das /LARGEADRESSAWARE Flag in seinem Header gesetzt haben, damit es mehr als die 2GB auch tatsächlich bekommt.
Ist das beim FSX der Fall?

Zitat von »mhe«

Ist das beim FSX der Fall?

Der FSX ist auf 2GB pro Thread limitiert ...

Gut zu wissen. Ist damit nicht der ganze /3GB Switch irgendwie sinnlos?

Wie dem auch sei, wir sollten langsam mal anfangen uns um den Arez zu kümmern, weil von der technischen Fachsimpelei hat er vermutlich recht wenig.
Arez: Was hast Du alles an Dingen hinterm Flusi laufen? Virenscanner, irgendwelche externen Tools, Messenger etc? Wie ist die Speicherauslastung im Leerlauf?

Hast du den Arbeitsspeicher mal mit dem Programm Memtest86+ geprüft? Das Programm kannst du dir hier downloaden.

Wärst Du bereit, mal testweise 1 und/oder 2 Riegel auszubauen und zu schaun obs dann geht? Weil das würde zumindest beim Eingrenzen der Fehlerursache helfen.
Dass das keine Dauerlösung ist, wissen wir natürlich.

Hübscher Screenshot von der Mustang da am Desktop

Ob es die Option in der fsx.cfg gibt werd ich versuchen rauszufinden.

Also passiert das oft, wenn du grosse Plätze anfliegst... Das ist ja schon mal eine wertvolle Info, weil da scheinbar wirklich der maximale Platz, den das Programm belegen kann/darf überschritten wird (und das sind eben nicht die 4GB die Du eingebaut hast, sondern leider weniger). Was für Einstellungen hast Du im Flusi? Weil evtl ist das mit einem recht einfachen Setting ja behoben.

Wenn wir auf die Art nicht weiterkommen, werden wir uns wohl ansehen müssen wie sich der Speicherbedarf vom Programm entwickelt sobald Du in die Nähe von was grossem kommst.

Weiters die Frage, ob du SP2 für den FSX draufhast.

Der allseits beliebte MeatWater hat hier auch mal einiges zu dem Thema verfasst, vielleicht hilft Dir das weiter.

Immerhin wird da tatsächlich das Largeadressaware Flag in der EXE gesetzt in dem Tutorial, somit stehen die Chancen gut dass das wirklich funktioniert.
Das ist nämlich der Schritt der in vielen anderen Lösungs-Tutorials für Dein Problem weggelassen wird, was die ganze Aktion ad absurdum führt.

Wow, das muss ja sehr potente Hardware sein.
Ruckelt das nicht wie blöd? Wenn ich heimkomm, kann ich Dir mal Settings von meinem FSX zusammenschreiben, vielleicht gehts damit besser. Ist zwar ein Vista64, aber wenn ich alle Regler in allen Menüs auf Anschlag stelle, kriecht die doch recht gut ausgestattete Box ziemlich auf dem Zahnfleisch...

Hm, vielleicht nur so eine Idee. Aber so wie sich das alles anhört und mit deinen sehr hohen Einstellungen, sieht es so aus, als wenn dein Grafikspeicher voll ist und der Arbeitsspeicher nicht mehr nachkommt. Denn die 512VRAM der Grafikkarte(n) sind nicht gerade viel, für einen voll aufgeziegelten FSX.
Immerhin kam die Meldung ja auch bei reduziertem RAM.

Warte mal ab, was mhe dir für Einstellungen rüberschickt. Und probiere es damit dann nochmal aus. Ein Versuch ist es wert.

Zitat von »ArezOne«

Gibts irgenteine möglichkeit das ind er FSX.CFG zubeeinflussen???

Nein, Speicher wird vom Betriebssystem verwaltet ...

Zitat von »Superburschi«

Versuche das Ganze mal mit dem Deaktivieren der Auslagerungsdatei...

Checked ?