|
zu wenig Arbeitsspeicher immer nur an einer Stelle
Hallo liebe Flusigemeinde.
Ich versuche schon seit einer Woche ein Leg der IVAO Long Haul Tour zu fliegen, und jedes Mal stürzt mir der Flusi im Anflug auf UUEE- Moskau, mit der Fehlermeldung wie im Anhang zu sehen ab. Ich Habe dann versucht, von einem anderen Airport dort hin zu gelangen, aber immer mit dem gleichen Ergebnis. Da mein System sonst sehr stabil läuft, bin ich doch schon verwundert, dass der Fehler immer wieder an der selben Stelle auftritt. Ich benutze, bis auf FS Global, keinerlei Addon Scenerien in Russland. Wie gesagt, egal wohin mich mein Flieger bis jetzt immer hingebracht hat, alles ohne Probleme. Da ich mit FSPassengers fliege und immer von dort wieder starten möchte wo ich vorab gelandet bin, ist es wirklich frustrierend, wenn nach einem 5 Std. Flug der Flusi immer kurz vor dem Touch down tschüss sagt. Ausserdem würde ich gerne dieses Leg validiert bekommen, damit ich endlich nach Japan reisen kann. ;-) Hat jemand von euch die gleichen Erfahrungen gemacht, oder hat jemand eventuell einen Lösungsweg für mich, damit ich endlich wieder voran komme? Für Infos wäre ich wirklich dankbar. Gruss Thomas Anhang: http://img77.imageshack.us/img77/900/shot0001fp9.jpg P.S. Mein System ist im Profil aufrufbar. |
Hmm, benutzt Du eine Moskau-Szenerie oder Default?
Wenn Addon könnte man vermuten, dass sich in dem scenery Ordner ein Landclass file befindet und das darf nicht sein. Landclass files fangen häufig mit "LC_" an - leider nicht immer... schau doch mal nach (auch bei weiteren Szenerien). Edit: Da Du ja schreibst, dass Du in Russland keine Addons verwendest, muss es ja irgendwas auf dem Weg dort hin sein (es dauert ja auch bis Auslagerungsdatei + 2GB überlaufen). |
zuwenig Arbeitsspeicher
Hallo Thomas,
ich habe gerade das gleiche Problem, allerdings trifft es mich bei einem Flug mit der F1 ATR von München nach Manchester. Es erwischt mich dort ähnlich wie bei Dir kurz vor dem Einschwenken in den Final. Ich habe gerade alle Szenerien des Flusis, bis auf die mitgelieferten Standard Szenerien entfernt. Als Nächstes werde ich jetzt die Szenerien neu installieren, die ich für den besagten Flug benötige. Danach werde ich mit Wolli´s Tool prüfen, ob sich irgendwelche leeren Textur-Ordner eingeschlichen haben und den Flug durchführen. Mal sehen, was dabei herauskommt. Die Szenerien die ich neu installiert habe sind: UT Europa; GAP 1-4; UK 2000 #1-8 + London Airports + Gatwick Pro Zugegeben, die brauche ich nicht alle für diesen speziellen Flug, aber sie gehören zu den grösseren Gebieten in denen ich mich im Moment herumtreibe. Ich werde Dich auf dem Laufenden halten. Gruß Torsten P.S. Wenn vielleicht jemand noch einen besseren Tipp hat nur zu.. :-) |
Hallo zusammen,
@marco ew311 Also auf deine Vermutung hin, bin ich mal in den Addon Scenery Ordner und von dort aus in den Scenery Ordner gegangen. Ich habe mir dann alle Dateien angesehen, die aussschliesslich aus normalen bgl-Dateien bestehen. ABER, eine kleine Datei mit dem Namen ( LC_67_030.bgl )habe ich dort gefunden. Es war wirklich nur diese eine Datei. Könnte es sich bei dieser Datei um eine Landclass-Datei handeln, die eventuell für meinen Crash verantwortlich ist? @tmaciol Dann bin ich ja mit meinem Frust ja nicht alleine ;-) Ich werde diese Datei mal aus den Scenery Ordner herausnehmen und schauen, was jetzt passiert. Gruss Thomas |
Zitat:
Ich drücke die Daumen, wäre ja schön, wenn es das schon wäre - häufig findet man den Schuldigen nicht so schnell. Leere Texturordner wie Torsten schreibt, sind auch noch eine Möglichkeit. |
Die Meldung ist exakt diejenige, die man bei einem Speicherleck erhält, wie es z.B ein Landclassfile im FS2004 verursachen kann.
Wobei die Aussage, dass ein Landclassfile nicht in einem Sceneryordner sein darf falsch ist. Denn immer wird ein Landclassfile in einem Scenery Ordner stehen müssen, denn das ist die Struktur des FS. Richtig ist: Immer wenn ein Textureordner parallel zu einem Sceneryordner liegt in dem sich ein Landclassfile befindet, dass hier alle Texturen und Steuerdateien die zum Betrieb dieses Landclassfiles nötig sind vorhanden sein müssen. Wenn nicht tritt das Speicherleck ein. Umso mehr Texturen fehlen umso schneller wächst das Speicherleck. Da ist es natürlich logisch, dass ein leerer Texture Ordner der parallel zu einem Scenery Ordner mit Landclassfile existiert absolut tödlich ist. Da ist es natürlich sinnvoll, dass man so einen Textureordner löscht. Denn ist keiner vorhanden paasiert auch nichts. Wie gesagt hat man aber einen Textureordner und es sind die benötigten Texturen vorhanden dann geht das OK, es kommt zu keinem Speicherleck. Sehr viele Scenerydesigner gehen so vor, denn so lassen sich eigene individuelle Texturen unabhängig von den Default Texturen des FS verwenden. Gefährlich wird es, wenn Designer aus Unwissenheit ein Landclassfile BGL z.B in einer Airportscenery unterbringen. Denn die wird immer einen Textureordner für Gebäude usw. haben. Der Texture Ordner ist also da, es fehlen aber ev. die Landclasstexturen. Also Peng Speicherleck. So wird es hier wohl sein. Es ist extrem wahrscheinlich, dass es sich bei oben erwähnten File um ein Landclassfile handelt. Prüfen kann man das übrigens mit dem SDK Tool TMF Viewer. Sollte es so sein und es handelt sich um eine Scenery die einen Textureordner hat (die Landclasstexturen selbst fehlen aber), dann muss das Landclassfile raus aus dieser Addonscenery. Man kann es notfalls als eigene neue Scenery anmelden. (ohne parallelen Texture Ordner) Übrigens ich beschreibe in meiner Doku auf www.jobia.de ein Scanverfahren, wie man den kompletten FS nach diversen Scenerycodes abscannen kann. Man muss also nicht nach Namen von potentiellen Dateien fahnden bzw. mit dem TMF Viewer im Vorfeld ev. auch unwahrscheinliche Dateien prüfen ob es nicht doch ein Landclassfile ist. Mittels dieses Verfahren scannt man den FS automatisch nach gewünschten Code ab. Das geht bei Einzelscenerien extrem schnell. Beim ganzen FS kann man ev. auch schon mal ein Bierchen trinken. Aber immer noch schneller als mit anderen Verfahren nach Landclassfiles zu suchen. Eine andere Methode wäre über dass Tool Filemon. Hier könnte man fehlerhafte TexturDateizugriffe während des Betriebs überwachen. Das Landclassspeicherleck entsteht nämlich durch erfolglose Texturdateizugriffsversuche des FS im zugehörigen Textureordner. Da er dort nichts findet lädt er alternativ Defaulttexturen. Leider versucht er dieses ständig erneut. Das Speicherleck schreitet voran, siehe auch meine Dok. |
@JOBIA
Vielen dank für die ausführliche Beschreibung.Ich werde mir diesen riesen Schinken aufmerksam durchlesen. :-) @All Leider konnte ich bis jetzt immer noch nicht das Problem beheben. Ich habe mir dann die Mühe gemacht, auf meinen Zweitrechner ebenfalls den FS2004 zu installieren. Als einzige Addons die PMDG 744 sowie FS Global. Ich wollte es nicht glauben, aber auch hier hatte ich den selben Fehler. Also FS Global deinstalliert und siehe da, alles ohne Probleme. Daraufhin habe ich meine Flusiordner des Hauptrechners unter die Lupe genommen und auf leere Texturordner hin untersucht. Es waren aber keine zu finden. Somit bleibt für mich nur die Möglichkeit, wärend dieses Leg's der Tour FS Global zu deinstallieren und anschliessend wieder zu installieren. Eines ist mir aber bei diesen Flügen aufgefallen. Je näher ich an den Zielflughafen UUEE komme, um so stockender wird das Terrain aufgebaut. die Texturen bleiben relativ unscharf und der Flusi fängt an zu stottern. Dann im Sinkflug, Peng zu wenig Arbeitsspeicher. Jetzt bin ich gerade auf dem Weg nach Japan und alles läuft wie ich es mir wünsche, inklusive Rückenwind ;-) Gruss Thomas :hallo: |
Also FS Global für den FS2004 habe ich auch.
Häng doch einfach mal als ZIP File eine entsprechende Flugsituation inkl. zugehörigen Wetterfile welche Du kurz vor dem Problem abspeicherst hier als Forenanhang an. Am besten natürlich mit Defaultflieger. Dann könnte man das mal nachvollziehen ob es auch bei anderen mit FS Global hier zu einem Speicherleck kommt. Mesh als Speicherleck habe ich noch nie was von gehört. Fakt ist, dass bei aufwendigen Gelände mehr gerechnet werden muss, auch das dieses an sich mehr Speicher belegt als ein flaches Gelände gleichen LOD Levels. (Datenkompression) Wenn man dann kaum noch Platz auf der Auslagerungsdatei hat, ev. über wenig PC RAM verfügt, dann kann es natürlich auch ohne ein echtes Speicherleck bei regulär hoher Speicherbelastung zu so einer Fehlermeldung kommen. Speziell Anwender die ev. die Auslagerungsdatei deaktiviert haben, bzw. sie von Windows verwalten lassen, eine volle Festplatte haben (ev. Papierkorb nicht gelöscht) laufen Gefahr so einer Fehlermeldung. Wie gesagt was Landclass betrifft ist es nicht unbedingt ein leerer Texture Ordner der ein Speicherleck auslöst, sondern ein Texture Ordner der nicht die benötigten Texturen enthält. Beispiel: In einer Airport Scenery wurde aus versehen von einem Designer auch eine Landclass BGL untergebracht. Die Airport Scenery besitzt natürlich einen Texture Ordner für Gebäudetexturen. Es existiert also ein nicht leerer Texture Ordner. Dem Laien fällt dieses Problem natürlich nicht auf, da er ja immer in Foren hört, dass nur ein leerer Texture Ordner so ein Speicherleck auslöst. So eine Scenery wird dann gemäß des Forensachverhalts als Problem ausgeschlossen. Trotzdem ist sie natürlich ein Problem, denn es existieren hier ja nur Airporttexturen nicht aber Landclasstexturen im Textureordner. |
@JOBIA
Erst einmal vielen dank für deine Mühen. Ich werde diesen Flug noch einmal mit einer Standardmaschine wiederholen und dann die Daten zippen. Allerdings bräuchte ich von dir nur noch ne Info, welche Dateien es denn genau sein sollen. Gruss Thomas |
Also folgendes. Du lädst z.B die Default B737. Dann begibst Du Dich grob in die Nähe Deines Problemgebietes wo Dein damaliger Flug lang ging und konfigurierst dein Flugzeug mit Autopilot so, dass es den Flug alleine grob in Richtung UUEE- Moskau durchführt.
Du kannst natürlich auch den damaligen Flug zunächst komplett durchführen bis Du meinst Du bist in der Nähe des Punktes auf der Anflugroute zu UUEE- Moskau wo das Problem wahrscheinlich auftreten wird. Am besten sollte dieser Punkt auch schon unter Autopilot während der Flugphase erreicht werden. Hast Du grob diesen Punkt erreicht, speicherst Du diese Flugsituation ab. Name z.B SpeicherleckFSGLOBAL Diese Flugsituation könnte man jetzt jederzeit wieder aufrufen und von hier beobachten ob es zum Speicherleck kommt. Das gleiche würde für mich gelten. Da wir die Default B737 nehmen kann ich wenn Du mir diese Flugsituation SpeicherleckFSGLOBAL schickst exakt den selben Flug bei mir mit der Default B737 unter Autopilot durchführen. Autopilot deshalb, da dann das Flugzeug bei mir exakt so fliegen wird, wie es das bei Dir getan hat. Da mit der Flugsituation auch das Wetter gespeichert wird, haben wir selbe Wetterverhältnisse ev. gleiche Winddrift usw. Wenn es also wirklich ein FS Global Problem anstatt eines Landclassproblem sein sollte, dann müsste es bei mir jetzt sehr wahrscheinlich auch auftreten. Ok was Du vermutlich jetzt nicht weist, wo ist denn nun diese gespeicherte Flugsituation abgelegt. Der Pfad sieht in ungefähr so aus. Ein Beispiel für mein PC mit deutschen Win XP. Ich melde mich als Benutzer Joachim beim hochfahren von XP an. Der Pfad lautet bei mir C:\Dokumente und Einstellungen\Joachim\Eigene Dateien\Flight Simulator-Dateien Bei Dir wird anstatt das Joachim das einzusetzen sein, was Deinem Benutzernamen entspricht. gehe in diesen Pfad. Dort solltest Du jetzt zwei Files finden die so lauten werden: SpeicherleckFSGLOBAL.FLT SpeicherleckFSGLOBAL.WX Diese beiden Files kannst Du in einen Ordner Flugsituation kopieren. Diesen zippst Du und hängst in hier als Forenanhang an. Kannst in mir auch direkt per Mail schicken. jobia@t-online.de Ich versuche schon seit einer Woche ein Leg der IVAO Long Haul Tour zu fliegen, und jedes Mal stürzt mir der Flusi im Anflug auf UUEE- Moskau, mit der Fehlermeldung wie im Anhang zu sehen ab. tung |
Hallo zusammen,
sorry daß ich diesen Thread nochmal "wiederbelebe", aber ich habe auch so meine Probleme mit dem Arbeitsspeicher! Habe mittels Filemon herausgefunden, daß der Flusi die ganze Zeit die Datei FS9\EFFECTS\UtSandSu.bmp.fx und die FS9\effects.cab erfolglos sucht! Die Dateien müssten zu Ultimate Terrain gehören ... Des weiteren sucht er immer wieder erfolglos nach der FS9\SCENERY\WORLD\TEXTURE\140B2Sp1.bmp - allerdings nicht so häufig wie nach obigen Dateien ... Kann dies die Ursache für mein Speicherleck sein??? Vielen Dank schon mal für eure Antworten! Gruß THOMAS |
Liebe Leidensgenossen !
Hab´ schon befürchtet, dass dieses Problem nur bei mir auftaucht. Hab´ mich so gefreut über meinen neuen Rechner mit dem Intel E6600 Proz. m. 2GB RAM. Endl. kann man EDDF u.dgl. mit 30 fps an-und abfliegen, usw.... da häufen sich die Probl. mit FS Abstürtzen. Es war mir unmöglich, in Europa irgendeinen Flug zu beenden. Immer "zu wenig Speicher, ... bzw. "FS9 hat ein Problem festgestellt, .... " Probl.: terrain.dll bzw. irgendeine andere .dll Nach und über Amerika gab´s kein Problem. Als ich von KSFO nach EGLL nach 10:35 h online zur Landung ansetzte - rw. in sight, gear down, ... kam die Meldung "Nicht genügend virtueller Speicher, .." Von Sion kommend nach Klagenfurt war regelmäßig über Innsbruck Endstation. Hab´ darauf alle add-ons abgeschaltet und bin mit dem nackten FS9 geflogen - mit Teilerfolgen. Bin mit Jobia, dem ich an dieser Stelle nochmals herzlich danken möchte, in Kontakt. Seit ich dann UT Europe in der Bibliothek abgemeldet habe, hab´ ich nun 3 Flüge über Europa zu à 2:20 h erfolgreich beendet. Will noch nichts verschreien und weiter testen, aber wenns denn so sein sollte, hab´ich das Geld für UTE umsonst ausgegeben, bzw. gibt´s dazu irgendeinen Patch (finde nämlich keinen)? Habt Ihr Alternativen dazu gefunden? Eure Problemlösung würde mich sehr interessieren. Viele Grüße Franz |
Ich habe genau dieses Problem mit dieser Meldung auch bisher nicht richtig in den Griff bekommen und heute mal einen Flug mit der 747 von EDDF nach EGKK gemacht. Wieder beim Final mit dieser Meldung und der FS9 nutzte in dem Moment 1GB Speicher. Mir ist aufgefallen, das es eigentlich nur mit der 747 auftritt. Bei kleineren Maschinen wird lange nicht so viel Speicher genutzt trotz Scenery Addons. Könnte es nicht einfach auch sein, das des FS9 ab einer bestimmten Anzahl von Addons einfach überfordert ist? Habe wirklich alles probiert bisher und extra auch auf UTE verzichtet nach einer Neuinstallation.
Steffen |
Wollte auch mal die Dateizugriffe von Filemon beim fliegen prüfen lassen. Wie habt ihr den Filter von Filemon dafür eingestellt, damit nicht zu viel angezeigt wird? Thx...
Steffen |
Sorry, das ich erneut damit anfange, aber mich lässt diese "OOM" Problem einfach nicht los und das es bei mir nur mit den PMDG Maschinen in Verbindung mit viel AI und großen Scenerys auftritt. Ich habe nun auch im PMDG Forum mehrere dieser Einträge unten gefunden und kann bei mir auch sicher ein Speicherleak ausschließen. Ich bin mir auch ziemlich sicher, das dieses Problem in der Kombination von großen Scenery Addons, Active Sky..., und z.B.. PMDG Dickschiffen auftritt... Und da ich aber nur ungern auf die PMDG's verzichten möchte, muss ich wohl mal andere Testwege beschreiten.
"Hello On my system (2 GB RAM) it looks like a combination of PMDG 744, PMDG 744F, complex scenery and time of flight. I guess it's not a single aircraft or scenery that causes this effect. It's the combination. I noticed CTDs either on approach when the scenery will be loaded or after landing when I change to spot view. The chance to get a CTD depends on the time of flight as well. Complex sceneries involved in CTD on my system are: EDDF Mega Scenery Aerosoft LFPG Aerosoft EGLL Pro UK2000 KPHX SimFlyers RJBB Overland .... and so on I've already tried several Windows page file settings: no page file, fix size or Windows managed. No help at all. From my point of view it looks like a memory management issue of Windows. The combination of a complex aircraft, complex scenery at destination and several hours of flying will cause this memory problem. Very annoying by the way..." |
Hi Steffen,
Du hast Post! :-) Aber ich poste hier trotzdem nochmal für unsere "Leidensgenossen" Ich kann den Fehler insoweit reproduzieren, weil er mir bei einem Flug LFPG - KLAX mit dem PMDG 737-BBJ immer so auf Höhe Neufundland abschmiert ... Bin der Meinung daß das Ganze was mit Ultimate Terrain zu tun hat ... hab mal das Programm Filemon im Hintergrund die Dateizugriffe mitprotokollieren lassen und bei mir scheint es zu sein, daß er sich "einen Wolf sucht" nach einer Datei die die Sommer-Küstentexturen darstellen soll! Andererseits hat das Deaktivieren aller Ultimate-Terrains aber nix gebracht! Hat zwar die betreffende Datei nicht mehr gesucht ist aber trotzdem mit der bekannten Fehlermeldung abgeschmiert! Einen anderen Absturz bekomme ich auf der Strecke LLBG-EDDF mit der PMDG 747 etwa auf Höhe Italien bzw Kroatien, je nach Flugplan ... Bin echt ratlos! :heul: @ Steffen: Hab den Filter von Filemon so eingestellt, daß ich bei "include" den Pfad vom Flusi eingegeben habe und daß er nur die fehlerhaften Versuche anzeigen soll. |
Hast auch Post, aber hier noch mal für die Leidensgenossen...
Wie oben schon geschrieben, schiebe ich es mit auf die Speichergrundlast, die schon die PMDGs verursachen in Verbindung mit dem bei mir nur genutzten VC und dann halt noch "dicken" Addons. Das bestätigen auch die zahlreichen Posts im PMDG Forum zu diesem Thema. Übrigens verursachte UTE von Anfang an zugegebene Specherleaks, die wohl mit den folgenden Patchen behoben sein sollten, was ich aber nicht so richtig glauben kann und deshalb auf UTE verzichtet habe. Deine Filemon Aufzeichnungen bestätigen das ja eigentlich auch. Die haben da Texturen vergessen mitzugeben! Was für AI hast Du denn in welcher Höhe bei Dir laufen? Ich will nachher noch mal mit der 747F von EDDF nach EGKK oder EGLL fliegen, wo ich immer diesen Fehler im Final hatte und mal die AI runter schrauben. Mal sehen, ob das was brings. Dabei werde ich Filemon auch mal laufen lassen. Vlt. hilft mir das ja ein wenig weiter. Ich will einfach nicht auf die PMDGs verzichten! komisch daran ist, das ich mit GA's nie diesen Fehler nachvollziehen konnte. Steffen |
@ Steffen: Ich werd unsere Unterhaltung via PM mal hier fortführen wenn Du nix dagegen hast! Ist ja nix geheimes was wir besprechen! ;) Außerdem bin ich etwas schreibfaul und will nicht alles doppelt schreiben! :p
Damit wir wissen worüber wir reden, hier mal mein System: AMD Athlon 64 4600+ Dual Core (Socket 939) ASUS A8N-SLI Motherboard nVidia Geforce 7950 GT 512 MB 3072 MB RAM (2x512 2x1024 MB-Riegel) 2x 160 GB S-ATA HDD Der Flusi mit seinen Peripherie-Anwendungen läuft auf einer eigenen Platte mit WinXPPro. Verwende als Add-Ons: PMDG 737-600U/700/800/900, 747-400, 747-400F Level-D 767 Eurowings 2004 Ultimate Terrain Europe Ultimate Terrain USA Ultimate Terrain Canada/Alaska Ground Environment 2006 FS Global 2005 Active Sky v6 AES v1.60 GAP 1,3,4 Mega-Airport Frankfurt Aerosoft France 1+2 Aerosoft New Spanish Airports Aerosoft Mallorca 2005 Gran Canaria 2005 Wonderful Madeira etliche SimWings-US-Airports etliche Freeware-Airports Puh, hoffe ich hab nix vergessen! ;) Als AI-Traffic hab ich alle vorhandenen Airlines von "World of AI" mit 100% im Flusi laufen ... Frames sind bei 15 gelockt - aber beim MAF habe ich durchschnittlich 8 Frames/s Ach ja bzgl. der AI-Traffic: Bei mir spuckt Filemon auch da laufend Fehler aus ... Hab lt. FlightSimManager keine Landclass- und Texturen-Fehler! :mad: ICH SEHS ÜBRIGENS AUCH NICHT EIN, MICH DEM WILLEN EINES PROGRAMMS ZU BEUGEN UND Z.B. DIE SCHÖNEN PMDG-MASCHINEN WEG ZU LASSEN!!! :mad2: ;) |
Bin gerade über EBOS auf dem Weg nach EGKK. Mal sehen wie es im Final läuft. Bisher kein Fehler in Filemon zusehen. Hast doch nur "Error" angehakt, richtig? Speicherauslastung im Moment 67% von 2GB. Gleich T/D, na da bin ich mal gespannt...
|
ZU
Zitat:
Diesen Fehler haben aber nur zu Anfangszeiten einige Addon Designer bzw. einige Anwender selbst begangen. Alle anderen mehr oder weniger versteckten Speicherlecks wie man sie damals in z.B All Roads of Europe oder Austria Prof. bzw. UT findet um nur mal drei zu nennen, finden diese Tools nicht. Dieses kann man nur mittels meiner Headerfragmentsuchmethode die ich in der Doku beschreibe bzw. noch einfacher mit Filemon entdecken, wenn man weis, dass als Nebeneffekt eines Landclass Speicherlecks zuvor ein erfolgloser Texturladeversuch in betroffen Addon Texture Ordner vorgelegen hat. Diesen erfolglosen Texturzugriff (der die Speicherverschwendung selbst übrigens nicht auslöst) kann man in Filemon erkennen. Aber ich sehe hier auch nicht unbedingt ein Speicherleck als Auslöser. Leider werden die LOG Files immer sehr groß. Ich habe bei Franz nur einen kleinen Bruchteil gesehen. Auch ist es nicht einfach etwas zu beurteilen, wenn man nicht exakt synchronen Zeitbezug Filemon zum FS und zum auftretenden Problem hat. Ich habe schliesslich nicht am PC gesessen und es selbst beobachtet was wann wie passiert ist. Ich sehe nur die letzten 2,5 Minuten vor dem offensichtlichen Absturz. Wie die Speicherauslastung bei Franz war, weis ich nicht. Bei einem Absturz zuvor war sie um 1,8GB. Übrigens um 1,8GB ist oft eine Absturzgrenze wenn jemand 2GB Ram besitzt und die Auslagerungsdatei deaktiviert hat. Also ein 2GB RAM Besitzer bitte mal beobachten ob es bei euch immer ab 1,8GB RAM kritisch wird. Es könnte nämlich ein Problem mit der Auslagerungsdatei geben. Mir ist mal bei Schwiegervater aufgefallen (ähnlich aktuelles System wie einige hier haben), dass irgendwie die Festplatte extrem langsam hinsichtlich Datenzugriff ist. Ev. fehlt irgendwann der schnelle Zugriff zur Auslagerung. Letzteres nur ein Verdacht. Ich weis auch nicht ob Franz sein LOG File nicht einen Filter enthielt der z.B Texturen ausschliesst. Sonderbar war das in den kurzen 2,5 Minuten des LOG Files welches er mir geschickt hat zwar Texture Ordner abgefragt wurden, aber keine einzige Textur """BMP""" Datei abgefragt wurde. Das ist äußerst ungewöhnlich (insofern nicht ein Exclude Filter gesetzt war) Da sich in den letzten Zeilen auch PMDG findet gehe ich fast davon aus, dass dieser Flug ebenfalls mittels einer PMDG durchgeführt wurde. Es finden sich obwohl der Anflug auf Sao Paulo anstand extrem viele Scenery Abfragen europäischer Addons. Ich kenne das Phänomen eigentlich nur dann, wenn Addons noch vielen alten FS2002 Code und davor enthalten. Auch scheint Franz das LOG File lässt es zumindest erahnen extrem viele Addons auf seinem PC zu haben. Auch UTE usw. ist dabei. Das mit dem komischen Effektfile von UTE ist mir auch sofort aufgefallen. Also wir finden hier eindeutig identische Verhältnisse bei euch vor. Es sieht fast so aus, dass der FS hier irgendwo an seine Grenzen kommt. Man sollte also zunächst mal darauf achten ob es immer dann auftritt wenn man nahe an die eigene RAM Grenze kommt also ca. 0,2GB davor. Ev. auch ob bei euch kurz zuvor sehr viele Addons abgescannt wurden, die ev. mit der Fluggegend überhaupt nichts zu tun haben. Auch ob bei euch kurioser Weise vor dem Absturz keine Texturen abgefragt wurden. Mehr kann ich dazu momentan nicht sagen, da ich viele der Addons wie z.B UTE nicht habe. Ev. würde ich mal die Empfehlung geben testweise UTE und FS Global komplett zu deaktivieren. |
Moin,
ich habe ja nun gestern weiter getestet mit der 747 über Europa und habe aber mal im Final per Key über FSUIPC die AI auf 50% gesenkt. Keine Ahnung, ob es daran gelegen hat, aber ich habe in EGKK extra noch zwei GA durchgeführt und es kam zu keinem Absturz. Die Gesamtramauslastung war in dem Moment bei 77% (im Flug vorher von EDDF durchweg bei 66-68%), also noch etwas unter den 1,8GB. Das würde aber durchaus bestätigen, das es bei mir ab den angesprochenen 1,8GB kritisch wird und ich vlt. mit Senkung des Traffic im Final etwas darunter gekommen bin. Nebenbei hatte ich auf einem zweiten Moni noch Filemon laufen, welches nur auf fehlerhafte Zugriffe von meiner FS9 Festplatte (WD Raptor SATA II) konfiguriert war. Außer einem fehlerhaften Zugriff auf eine ini Datei der 747 wurde aber nichts angezeigt, was mir bestätigt, dass es eigentlich kein Texturproblem sein kann. Ich werde nun mal veruchen, die Rambelastung neben FS9 zB. durch Auslagerung von Active Sky 6.5 auf einen anderen Rechner zu senken. Verwendet habe ich bei diesem Flug: -PMDG 747F -Zusammenstellung AI aus WOAI-Traffic und anderen Paketen -Active Sky 6.5 -Ground Env. Pro -Flight Env. -alle GAP/GS/RG Pakete -Cloud9 Amsterdam -UK 2000 EGKK, EGLL -UK Roads @Jobia Austria Pro werde ich bei mir auch mal mit Filemon checken. Steffen |
Upps, Doppelpost - Sorry...
|
Zu
Zitat:
Komme jetzt nicht auf den Namen. Es hatte jemand den Verdacht gemeldet das es eins hat. Ich hatte dann den Nachweis geführt, dass es so ist und auch welche Texturen im Texture Ordner fehlen. Denn man beachte bei ATP. ATP verwendet ein lokales LC mit lokalen optisch von den Defaulttexturen abweichenden Texturen. Hier muss dann zwingend ein Texture Ordner existieren. Sprich diese erwähnten Tools die Landclass Speicherlecks aufspüren sollen, verweigern hier, da sie nach LC Files mit leeren Texture Ordnern suchen. Das ist bei der ATP aber nicht der Fall, da hier ja gerade lokale Texturen genutzt werden sollen. Oder aber sie melden im Extremfall eine Störquelle aufgrund eines vorhandenen Texture Ordners, der aber bei vielen Landclass Addons mit lokalen Texturen in Ordnung geht, da hier alle benötigten Texturen auch existieren. Wie gesagt bei der ATP fehlten ein paar Texturen. Siehe diesen Thread: Austria Professional / ATP Beseitigung des Landclasspeicherlecks Kann sein, dass es dafür mittlerweile einen original Patch gibt. |
Noch mal kurz zum Titel dieses Threads. Bei Franz tritt das Problem nicht an einer Stelle auf, sondern generell irgendwann.
Aber so wie es aussieht auch in Nähe seiner RAM Grenze. Es kommt allerdings nicht unbedingt eine Fehlermeldung aufgrund zu geringen Speichers. Es ist hier also eindeutig nicht das übliche Landclass Speicherleck. Eher die extrem vielen Addons und generell hohe Speicherbelastung aufgrund der Addons selbst. Mal sehen wenn er mir seine Scenery.cfg geschickt hat kann man ev. mehr dazu sagen. Ich könnte mir aber vorstellen, dass Ihr auch sehr viele Addons habt. Ich kenne das noch aus früheren Zeiten so alla Jäger und Sammler. Da kommt mit Free und Payware Addons einiges zusammen. |
Genau so ist es Jobia. Da spricht auch dafür, das ich dieses Problem, egal wo und wann, immer wieder mit der PMDG 747 habe, die ja sowieso schon viel Ram braucht. Mit der 737 habe ich noch nicht viel getestet, aber ich denke das wird da wohl ähnlich sein. Dann habe ich auch nochmal mein Spiele-XP OS optimiert und auch Programme wie Active Sky auf Netzwerkrechner ausgelagert. Trotzdem kommt es zu CDT's oder dieser OOM Meldung, obwohl dann noch gut 800MB von 2GB Ram zur Verfügung stehen und mein System sonst absolut sauber ist und keine sonstigen Probleme macht. Die auftretenden Fehler konnte ich übrigens mit "kleineren" GA-Maschinen noch nicht nachvollziehen. Muss ich nun vlt. doch komplett auf VFR umsteigen ;). Ist eben sehr schade, dass man nun endlich die Hardware hat, diese ganzen Adddons mit den max. möglichen Qualitätseinstellungen bei fps jenseits der 30fps zu geniesen und dann soetwas...
Könntest Du dir ggf. meine scenery.cfg auch mal ansehen? Gruß Steffen |
Ok
|
Geht Dir morgen zu ;). Ich bin heute mal den kompletten Abend am Stück die Strecken geflogen, die mit der 747 immer abstürzten und habe dazu die LevelD und die Captain Sim verwendet. Beide brachten mich immer ohne einen CTD ans Ziel und das bei den gleichen Einstellungen wie mit der 747 und dabei meine AI auf 100%. Wobei die Speicherauslastung 20-25% unter der mit einer 747 lag! Hängt das vlt. doch mit den PMDGs und größeren Addons zusammen?
Steffen |
Zu
Zitat:
Ich selbst habe die 747 nicht, kann also nicht beurteilen was da abläuft. |
hi zusammen,
darf ich mich mit einer Frage einklinken? Flug Nizza - Mailand. Kurz hinter Genua FS-Hänger (zu wenig Arbeitsspeicher). Kontrolle mit filemon ergab, daß sich AROE einen Wolf nach bitmaps sucht. http://www.buerger-lenggries.de/images/aroe.jpg 900-er Dateien, 008A2M*.bmp und 039B2M*.bmp hab ich schon in den FSQ-Ordner kopiert. Die suchte er nämlich ununterbrochen. Frage: Kann ein AROE-User das bestätigen? Ist das normal? Beschäftigt den Rechner ja ziemlich. Über "Nicht-AROE-Gebiet" ist's in filemon nämlich sehr ruhig was Fehler angeht. a3g Wolfgang |
Zu
Zitat:
Ich schrieb in diesem Thread auf der Seite zuvor folgende Zeile: "Alle anderen mehr oder weniger versteckten Speicherlecks wie man sie damals in z.B All Roads of Europe oder Austria Prof. bzw. UT findet um nur mal drei zu nennen, finden diese Tools nicht" Also wurde AROE von mir direkt erwähnt. Du findest hier im Forum weiterhin folgenden Beitrag aus dem Juli 2005 von mir: AROE verursacht definitiv Speicherleck Da finden sich auch die technischen Hintergründe und wie zu handeln ist. Es macht hier übrigens keinen Sinn die fehlenden Texturen alle in den AROE Texture Ordner zu kopieren. Dieses Landclassfile welches dort das Problem auslöst ist nicht als lokales Landclass Addon gedacht. Du müsstest nahezu alle Landclass Texturen des FS hier rein kopieren um das Speicherleck zu verhindern. Durch diese Aktion wäre zwar das Speicherleck beseitigt, allerdings hättest Du damit von der Basis schon eine fast doppelte Landclass Texturspeicherlast geschaffen. Von daher gehe so vor wie ich es in dem Beitrag aus 2005 beschreibe. |
Checke ev. mal die FSQ Homepage ab. Ich hatte dem Guido das Problem damals mitgeteilt. Ev. gibt es dort einen Patch von Flugwerk. Wenn nicht gehts Du so vor wie ich es beschrieben habe.
|
Ich habe nun festgestellt, dass diese Speichermeldung wirklich nichts mit dem Arbeitsspeicher zu tun hat, denn es kommt immer wieder zu Freez bei mir, auch wenn diese Meldung nicht erscheint und wirklich noch viel Speicher vorhanden ist. Gestern Abend war es mal wieder die komplette Flusi mit schwarzen Bildschirm (nur ATC Anzeige war noch zu sehen) und nichts ging mehr. Und das wieder in einem Final, diesmal auf EGLL. Es tritt absolut nie im Flug auf, sondern nur im Anflug auf größere Airports!? Ich bin nun schon am überlegen, ob es vlt. an den NV-Treibern meiner 8800er liegt, oder ist es doch nur ein FS9.1 Problem.
Steffen |
@JOBIA
sorry, daß ich erst heute antworte: Habe die posts seinerzeit zum AROE-Speicherleck wohl mitverfolgt und die von dir angeregte Änderung (europe.bgl) vorgenommen. Wie man sieht, ist da doch noch viel potentieller Ärger verborgen. Aufgrund der Vielzahl der Kombinationsmöglichkeiten PC-Hardware/Einstellungen/Grafik + FS SceneryAddOn/FS Aircraft + AITraffic usw ist es wohl ausgesprochen schwierig, dem eingangs angefragten Problem auf die Spur zu kommen. Dem obigen Statement bezügl bestimmter PMDGs oder LC-Addons als Ursache kann ich aus meiner Erfahrung nicht ganz zustimmen: Ich z.B. habe einen Rechner (Dell) mit 2GB und trotz einer Unmenge von Scenery- und AircraftAddOns (auch PMDGs, CaptSim, die üblichen verdächtigen Texture-/Mesh-/Wetter-AddOns usw., RAM-Auslastung bleibt immer unter 1,2 GB) nur CTDs (Fehler: ntdll.dll), die auf AI-Traffic zurückzuführen sind: Nämlich wenn ganz bestimmte a/c's erscheinen sollen. (besser gesagt sinds offensichtlich bestimmte Liveries). Aufgrund der Unmenge an AI-Flugzeugen war es mir auch mit filemon bisher nicht möglich, den/die Störenfried/e zu lokalisieren. Der Fehler ist zwar reproduzierbar (100%AI in der Nähe großer europäischer Flughäfen oder dicht beflogener Strecken auch über Meer) aber bislang nicht behoben. Viele CTDs in Europa, die im Forum schon beschrieben wurden (z.B. Flug entlang bestimmter Küsten), konnte ich nachstellen aber immer durch Absenkung des AI beheben. Das würde auf zu viel belegten Speicher schliessen lassen, aber: Die RAM-Auslastung hat sich bei mir bei diesen Versuchen zwischen 100%-AI und 0%-AI (!) nur ganz unwesentlich geändert. Vielleicht habe ich auch einfach nur Glück :-) Die doch einschneidenden Eingriffe durch viele höherwertige und komplexe Scenery-AddOns sind ja nicht unerheblich (gerade UTE, AROE oder z.B. CanarySim), sodaß die Chance groß ist, daß beim Aufspielen von Patch1 für Software A bei Software B oder im FS insgesamt irgendwann was schiefgeht. Eine Frage zum Schluß: Oben wird erwähnt, daß der Aufruf von Szenerienelementen, die sehr weit vom aktuellen Standort entfernt sind, etwas mit veraltetem Code (FS2002) zu tun hat. Ich habe z.B. in Europa immer via filemon beobachten können, daß GlacierBay oder FlightZone Portland aufgerufen wird. Darin dürfte doch nicht viel alter Code stecken? Siehe hier: Position nördlich München, Portland wird aufgerufen. http://www.buerger-lenggries.de/images/fs1.jpg Guten Flug allerseits Wolfgang |
Zitat:
Filemon hat bei mir gezeigt daß Ultimate Terrain sich "nen Wolf sucht" nach UtSandSu.bmp.fx und effects.cab Komme wohl um ein neues Aufziehen des Flusi nicht mehr rum oder? *seufz* |
Zu
Zitat:
Diese Effektdatei scheint laut Anwenderaussagen wirklich nicht zu existieren. Dieses fehlen muss aber nicht unbedingt ein gravierendes Problem auslösen. |
ZU
Zitat:
Ich habe das erwähnt. Es muss aber nicht unbedingt alter Code sein mit dem das passiert. Ich habe wie gesagt viele dieser Addons nicht. Mir ist es nur damals in Untersuchungen aufgefallen, dass es sich sehr häufig um alten Code handelt der zyklisch immer recht häufig abgefragt wurde. Aktueller Code war recht selten betroffen, was natürlich nicht bedeutet, dass es auch Codes neuerer Generation geben kann, wo das zutrifft. Ansonsten folgendes zu diesem Satz: " daß GlacierBay oder FlightZone Portland aufgerufen wird. Darin dürfte doch nicht viel alter Code stecken?" Kann ich zu diesen Addons wenig sagen. Aber ansonsten ist nicht ungewöhnlich auch in aktuellen Addons recht häufig noch auf den ein oder anderen alten Code zu treffen. So findet man im aktuellen Mega EDDF auch noch älteren Flattencode. Manchmal sind es gewisse Vorteile älteren Codes, die ein Designer mit neueren Code nicht realisieren kann. Dann greift er eben auch mal auf älteren Code zurück. So hat z.B der ältere AREA16N Flatten Code eine höhere Priorität als der neuere LWM2 und LWM3 Flattencode. Ein Designer kann dieses für bestimmte Zwecke nutzen. |
Zitat:
Meinst Du, Du kannst Dir mal meine Log-Datei anschauen, Jobia? Wäre echt nett von Dir! :-) |
Zu
Zitat:
Es muss übrigens nicht sein, dass dieses den FS funktionell stört. (da ich UTE nicht habe, kann ich das aber nicht testen) Allerdings sind diese Abfragen verschwendete Ressourcen die nicht nötig sind. Wenn so etwas bei vielen Addons wäre würde sich so etwas schon irgendwann störend auswirken. Für LOG Files habe ich momentan leider keine Zeit. |
@Wolfgang27
Ich kann das mit dem Absenken des AI-Traffic nur bestätigen, obwohl sich dadurch bei mir die Speicherlast auch nur unwesentlich verändert. Ich habe es bei meinen letzten Testflügen nun so gemacht, dass ich zwar mit 100% Traffic gestartet bin, am letzten VOR-Zielairport dann aber per FSUIPC Tastenbelegung auf 20% herunter schalte,was bei meinem benutzten AI-Paketen immer noch jede Menge Bewegung bringt. Und siehe da - es kommt plötzlich im Final zu keinem Crash des Flusi mehr. Ich vermute daher den Fehler inzwischen auch bei der AI-Config. Werde da noch weiter testen... |
Zitat:
|
| Alle Zeitangaben in WEZ +2. Es ist jetzt 12:25 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag