Hallo Ihr fleißigen Tester!

Die Problematik mit dem "Umschalten der Sichten" kann ich auch nur bestätigen. Ab und zu ereilt mich ja auch die bekannte FSX-Meldung, und eigentlich immer dann, wenn

1. ich bereits einige Stunden in der Luft bin oder
2. pausiert habe und dann meine Reise fortsetzte und
3. ich dann durch die Sichten zappe.

Und ich ärgere mich dann immer zu Tode, wenn nach der Atlantiküberquerung kurz vor New York der FSX sich verabschiedet. Da wird das Hobby regelmäßig auf eine harte Probe gestellt (FSX interruptus, oder so).

@Klaus: Trotz Beendigung unseres Landesfestes komme ich wohl erst die Tage zum Testen. Mein Terminplan ist zurzeit prall gefüllt. Ich werde es aber auf alle Fälle mal von EDDM/EDDS probieren und berichten, versprochen!

VG
Matthes

Was das Abstürzen des FSX wegen der Menuwechsel anbelangt, da gibt es eine Lösung. Man muss einfach nur die UIAutomationCore.dll in das FSX Hauptverzeichnis kopieren und damit sollte das dann Geschichte sein. Die richtige Datei gibt es z.B. hier: UIAutomationCore.dll

Was das g3d.dll anbelangt ... Ich hasse es!!! Ich beobachte das schon sehr lange und bin mir eigentlich sicher, dass es das Ergebnis einer Interaktion vieler Faktoren ist. Vermutliche Faktoren sind die spezifische Hardware, mehrere Komplexe Szenerien gleichzeitig wie UTX, REX etc., ein anspruchsvoller Flieger wie z.B. die IFLY und ein komplexer Airport (wie hier LOWI) plus eine optimierte FSX.cfg und Tschüss sagt der Flusi. Es ist eine zeitraubende Arbeit, herauszufinden, was das gesunde Mittelmaß ist, dass der Absturz ausbleibt.

Ich hatte einen g3d.dll zuletzt in Faro X (Aerosoft) und auch immer an derselben Stelle. Ich vermute mal, dass diesem Augenblick zentrale Dateien (wohl des Airports) laden, die das Fass dann zum überlaufen bringen. Klingt so, als sei es in LOWI ähnlich, da es ja immer an derselben Stelle zu passieren scheint. LOWI selbst ist sicher nicht der Auslöser, sondern eben nur ein Baustein wegen seiner Komplexität.

Ich hasse diese Abstürze so sehr, weil sie immer genau dann kommen, wenn es am schönsten wird!

Hallo Holger,

das mit der UIAutomationCore.dll stimmt so nicht.

Ich habe sie nicht nur einfach so reinkopiert, sondern vorschriftsmässig als Administrator mit regsvr32 angemeldet.

Ich versichere Dir, ich habe einen sauberen Flusi.

Grüsse. Friedi.

Friedi,

dabei geht es nur um das Menuproblem. Es kommt auch drauf an, dass Du genau die richtige erwischt (s. Link). Einfach ins FSX Hauptverzeichnis anmelden brauchst Du nicht. Hat bei mir und bei vielen anderen zumindest das Menuproblem gelöst!

Hallo Holger,

sei doch bitte so gut und setze den Link zu Deiner "UIAutomationCore.dll" noch einmal, so wie es jetzt ist, funktioniert es leider nicht.

Danke Dir!

VG
Matthes

Hoffe jetzt geht es:

https://rapidshare.com/#!download|648tl|…ore.dll|152|R~0

Moin Männer,

War im Urlaub und klinke mich daher erst jetzt kurz ein:

ja, ich hatte auch schonmal diverse Abstürze wg G3D.dll bei Anflúg von Stuttgart aus nach LOWI über RTT.

Ich verwende UTX, GEX, ASE, REX Texturen und kann mich aber nicht mehr erinnern, welches Blech ich damals flog.
EDDS ist das Addon von Aerosoft.

Diversere mal Absturz an derselben Stelle, dann wars auf einmal wie weggeblasen und trat nicht wieder auf ...



Daher nun keine große Hilfe, sondern nur die Aussage, das irgendwo was ein wenig im argen liegt.
Aber ich habe nicht ansatzweise eine Idee, wo man da suchen solllte: LOWI, EDDS, UTX, REX Texturen, ASE etc etc. ???

Bielefeld kanns nicht sein, da inexistent!

ich bin jetzt im Urlaub zweimal mit dem Moped an LOWI vorbeigefahren und hatte keinen Absturz, daher würde ich sagen, der Fehler ist nur temporär und kann ignoriert werden

Zitat von »ubootwilli«

Zitat von »matthes_f«

Ich habe zwei Flüge von LSZH 2012 nach LOWI X mit der iFly 737-600 gemacht und hatte sowohl mit einem LOD-Radius von 3,5.... als auch mit 8,5.... keinen Absturz. Ich konnte von Rattenberg kommend problemlos den Decent einleiten, auf der 26 landen und ausrollen - alles ohne jeglichen Fehler.

Hallo Matthes,

leider kann ich das so nicht bestätigen , Du könntest aber mal von EDDM oder EDDS einfliegen ....

Hallo Klaus,

wie versprochen habe ich eben einen Flug von EDDM nach LOWI unternommen. Pünktlich kurz vor TULSI hatte ich einen prima Absturz des FSX. Tolle Show.

Hier das Beweisfoto:


LOD war im Übrigen auf 8,5.... gestellt und alles andere war auch wie letztens beim Flug von LSZH nach LOWI, der ja bekanntlich ohne jegliche Probleme über die Bühne ging.

Morgen starte ich dann noch einmal von EDDS.

VG
Matthes

Hallo Matthes,

beim Anflug auf einen kleinen Flugplatz Nähe Brisbane mit dem Trike!! blieb das Bild stehen, der Mauszeiger (Kreis) drehte sich. Durch Rechtsklick konnte ich den Ton ein-und ausschalten, sonst ging keine Taste mehr.

Frage: der Absturz passiert ja immer in Sichtweite des Airports. Zufall oder Systematik. Würdest Du trotzdem mal festhalten, wie lange Dein Flug dauert, unterschiedliche Zeitlänge oder immer gleich lang bis zum Absturz des PC.

Danke. Grüße. Friedi.

Zitat von »Friedi«

Hallo Matthes,

beim Anflug auf einen kleinen Flugplatz Nähe Brisbane mit dem Trike!! blieb das Bild stehen, der Mauszeiger (Kreis) drehte sich. Durch Rechtsklick konnte ich den Ton ein-und ausschalten, sonst ging keine Taste mehr.

Frage: der Absturz passiert ja immer in Sichtweite des Airports. Zufall oder Systematik. Würdest Du trotzdem mal festhalten, wie lange Dein Flug dauert, unterschiedliche Zeitlänge oder immer gleich lang bis zum Absturz des PC.

Danke. Grüße. Friedi.

Hallo Friedi,

wunschgemäß die zeitliche Auflistung von EDDS nach Lowi von heute:

18.42 h - Start Win7
18.45 h - Start ASA EVO
18.47 h - Start FSX
18.48 h - Auswahl iFly 737-600
18.49 h - Auswahl EDDS, gate 16
18.49 h - aktuelle Zeit, 18:49:49 h
18.50 h - Flug starten
18.51 h - at the Gate
18.51 h - 19.03 h - Tanken, Checklisten usw.
19.03 h - Start Engines
19.12 h - Takeoff
19.40 h - Absturz bei ca. D16



Da sich bei mir vor dem Urlaub viele Dinge drängen würde ich gern (Dein Einverständnis vorausgesetzt ) darauf verzichten, die anderen Anflüge nochmals durchzuführen und die einzelen Zeiten zu notieren. Es ist halt, wie es ist!

VG

Matthes

Auf AVSIM gibts ja auch nen Thread dazu und die haben sich anscheinend auf eine geänderte LOD eingeschossen: http://forum.avsim.net/topic/338148-ctd-…e-ifly-install/

Vielleicht ist das eine Spur?

Hallo Günter,

das bekommen wir nie oder als Zufallstreffer mal raus.

Wieso soll es an LOWI liegen? Ich bin dort nicht abestürzt. Viele hatten damit Probleme.

Genauso die Frage: warum fliege ICH im Anflug mit dem Trike! auf das RAAF Point Cook Airfield (Nähe Melbourne) gegen die unsichtbare Wand?

Grüße. Friedi.

Das Thema g3d.dll ist ja momentan wieder richtig in Mode. Auch im Orbx Forum gibt es dazu einen ellenlangen Thread. In der dortigen Situation hatte ich ebensowenig ein Problem wie in Innsbruck (gut bei LOD > 4.5 ist bei mir die Performance grottenschlecht, aber kein CTD). Dafür hatte ich jüngst an anderer Stelle ein Problem:

Ich habe eine Route, die ich häufiger fliege: EAFS - EDLW (GAP2), im FSX mit AccPack, mit folgendem Gerät: PC12, ERJ145, F33, Cessna Mustang und der Lancair, immer auf 2 praktisch identischen Routen (abhängig von der RWY Richtung), Wetter meistens FSX default "Schönes Wetter". Dabei hatte ich nie einen g3d.dll Fehler. Gestern bin ich die Route mal wieder geflogen mit der Lancair, und ca. 15 nm vor EDLW hatte ich den Fehler. Bin dann am Abend die gleiche Route mit exakt den gleichen Einstellungen wieder geflogen, und siehe da, kein Fehler. Also, an was lag es jetzt?
IMHO könnte man den Fehler nur dann einkreisen, wenn er bei ALLEN IMMER in der GLEICHEN Situation (heisst alles gleich: Software, Hardware, Treiber, Einstellungen etc.) reproduzierbar ist. Und das war bisher noch nicht der Fall und wird auch nicht möglich sein.

Von daher bin ich der gleichen Meinung wie Friedi: Das Problem werden wir nie oder bestenfalls durch Zufall lösen.

gestern hatte ich noch die Einstellung im Jobscheduler im Verdacht, meine Einstellung beim Vierkerner war AffinityMask=14. Aber es passiert mit dieser Einstellung, mit 15 = 4 Kerne oder auch wenn man keinen Eintrag in die fsx.cfg schreibt, da ja dann automatisch ausgeführt wird.

Ich hatte beim Fliegen den Taskmanager im Blickfeld und mir ist dabei aufgefallen, daß der für den Flusi nicht genutzte Core 0 von etwa ständig 10% Auslastung auf einmal für ca. 2 Sekunden auf 100% hochschnellte und sich der Flusi daraufhin verabschiedete.

Also, was passiert da? Was wird in Gang gesetzt, daß auf dem Core, der für den Flusi gesperrt ist, auf einmal eine kurze 100 %-ige Auslastung stattfindet, die dann das FSX-Programm killt?

Grüße. Friedi.

Zitat von »gianni«

Es wäre insofern nachvollziehbar, dass die g3d.dll Fehler im Zusammenhang mit Speicherüberlastungen stehen. Hochkomplexes Mesh, viele Texturen und höchste Wassereinstellungen könnten tatsächlich manche Hardware überfordern.

Wäre eine Überprüfung sicher wert...

ist das auf den Speicher der GRAKA bezogen oder den RAM Speicher des PCs ?

8 GB Arbeitsspeicher sollten meiner Meinung nach schon ausreichen ... oder

dann laß ich mal GPU-Z mitlaufen, da wird die Speicherauslastung angezeigt.

#grüße. Friedi.

so, ich habe nochmal getestet, ohne einen einzigen Absturz:

LOD_RADIUS=8.500000 !!!
Wasser: Niedrig 2x, liegt also über Hoch 1x (sollte wohl ausreichen, wenn Wasser der Schuldige ist)
FPS gelockt bei 30
kein BufferPools
kein AffinityMask (4 Kerne von FSX verwaltet, lt. Windows Task Manager meist zwischen 96% und 100%) FSX kann ja bis zu 32 Kerne verwalten
kein FIBER_FRAME_TIME_FRACTION gepatcht

1. installiert ist alles von Deutschland + alles von ORBX, kein Austria Professionell, kein LOWI-X

Start in Salzburg über RTT nach LOWI
Durchschnittlich 25-30 FPS ab und zu mal "Microruckler" bis 9.5 FPS (nach Flusi-Fix)
In Höhe von RTT 2x kleine Aussetzer, einmal 4 FPS, einmal 6 FPS kein Absturz, Landung in LOWI


2. installiert wie Nr. 1, zusätzlich Austria

Start und FPS wie oben.
in Höhe von RTT 2 kleine Aussetzer, einmal 6 FPS, einmal 7.5 FPS ab und zu mal "Microruckler" bis 9.5 FPS
auch hier sicher Landung in LOWI


3. installiert wie 2, zusätzlich Innsbruck
Start und FPS wie oben
in Höhe von RTT hatte ich KEINE Aussetzer abgesehen von "Microruckler" bis 9.5 FPS


Mein Fazit:
Wie Mopperle schon im AS-Forum bemerkte, 999 unterschiedliche Möglichkeiten. Weder Wasser Niedrig 2x noch LOD_RADIUS=8.500000 hatten bei mir einen Absturz bewirkt.

Spekulationen über Innsbruck von gianni als Verursacher sind nicht haltbar. Entweder ist es ein Problem der verwendeten Hardware oder ein Problem der getunten FSX.cfg.

Ich hatte schon mal einen Absturz mit AffinityMask=14 (also Kern "Null" ausgeschaltet, Kern 1-3 für Flusi reserviert). Hier hatte ich beim Absturz einen blitzartigen Anstieg auf Kern "Null" von ca. 30% Auslastung auf 100% und aus war es.

Frage: Kern "Null" wird hier nicht vom FSX genutzt, sondern von Windows. Was hat hier geladen werden sollen, das entweder nicht gefunden wurde oder nicht schnell genug ausgeführt werden konnte, sodaß FSX beendet werden mußte, weil ein Fehler aufgetreten ist?


Grüße. Friedi.

Zitat

Was hat hier geladen werden sollen, das entweder nicht gefunden wurde oder nicht schnell genug ausgeführt werden konnte, sodaß FSX beendet werden mußte, weil ein Fehler aufgetreten ist?

Friedi, kannst Du mit dem ProcessMonitor von sysinternals umgehen? Der könnte die Frage ev. beantworten

Hallo Otto,

ich kann mich nicht mehr entsinnen, aber vor längerer Zeit hatte ich mal ein Programm, das hat mir alle Prozesse vom laufenden Windows und ausgeführten Programmen aufgezeichnet. Aber eine Analyse war in meinen Augen nicht machbar, da in einem Zeitraum von 12 Sekunden über einhunderttausend!! Einträge in der Liste standen.

Jetzt stell Dir vor, Du läßt das Programm , sagen wir, eine Stunde mitlaufen um eine Datei zu finden die nicht gefunden wurde oder die abgewürgt wird, weil sie zu lange zum Laden braucht.

In der neuen Chip steht was über "Blitzlösungen für Softwarepannen". Das lese ich mir nochmal durch. Da gibt es Hinweise auf Analyse-Tools.

Grüße. Friedi.

Zitat

Jetzt stell Dir vor, Du läßt das Programm , sagen wir, eine Stunde mitlaufen um eine Datei zu finden die nicht gefunden wurde oder die abgewürgt wird, weil sie zu lange zum Laden braucht.

Genau vor dem Problem stand ich auch. Dachte, es gibt da vielleicht eine Möglichkeit das einzugrenzen. Leider gibt es das Forum von sysinternals nicht mehr, sonst hätte ich dort mal eine Frage eingestellt.

Hallo,

da ich einen Absturz Nähe RTT Richtung LOWI nicht provozieren konnte, habe ich es mit ORBX in Brisbane geschafft (man möge es mir verzeihen, das mit ORBX). Aber es geht ja um einen Absturz durch g3d.dll

Ich habe den Absturz mit dem Freeware Tool WhatIsHang auslesen können und habe die Fehlermeldung als zip-Datei hier angehängt. Hoffe, das hat auch richtig funktioniert, hatte ich noch nie gemacht.

gianni hat bestimmt eine Möglichkeit einen Profi zu finden, der die Datei auswerten kann, evtl. finden wir so eine Lösung zum Problem.


Nochmal kurz die Voraussetzung zum Absturz:

Habe in der fsx.cfg AffinityMask=14 eingestellt.

Das soll die 4-Kern-CPU dazu veranlassen, den FSX auf den Kernen 1, 2 und 3 auszuführen, Kern 0 = null bleibt für Windows direkt.

Mir ist aufgefallen, daß Kern Null im Windows Task Manager immer bei ca 20% bis 30% Auslastung angezeigt wird. Nur direkt vor einem Absturz geht die Kurve blitzartig auf 100% hoch und dann Absturz. Also denke ich mir, passiert da was unter Windows und nicht direkt im FSX.

Wenn man ohne AffinityMask arbeitet und alle 4 Kerne bei fast 100% arbeiten, ist der Kurvenanstieg natürlich nicht zu sehen. Logo.


Grüße. Friedi.

Habe heute wieder mal ein wenig "rumgetestet"

(Dies soll jetzt nicht dazu dienen, LOWI als Ursache hinzustellen - glaube ich nicht - es soll nur helfen, wenn jemand evtl hierin auch eine Lösung findet)


Habe zu 100% einen G3D fehler reproduzieren können bei Anflug auf LOWI über RTT.
Ansturz passierte immer an der exakt selben Stelle: RTT überflogen, danach auf 253 LOC eingeschwenkt. Bei 18 nm Entfernung des LOWI DME dann crash.

Flug war immer von Start München (Aerosoft Megaairport) - Flugzeug immer PMDG J41

1)
Ein geladener Flug, den ich kurz nach RTT (also etliche Meilen vorm Absturzpunkt) gespeichert hatte, gab keinen Crash!
Crashes wirklich nur wenn ich in München gestartet bin!
Dabei war es aber auch möglich, einen crash mit der Schnellverstellung ("Y") zu erzeugen


2)
AES verkehr deaktivert in München und LOWI --> trotzdem crash
Virtuali.dll in der DLL.XML deaktiviert --> trotzdem crash
Virtuali.dll als "not trusted" (beim FSX start) eingestuft --> trotzdem crash

ergo: AES ist es wohl nicht


3)
MyTraffic deaktivert --> trotzdem crash


letztliche Lösung
LOD Radius von 6.5 auf standard 4.5 reduziert.
Seiteher bei etlichen Flügen kein crash mehr


Wie gesagt: ich weiß aus zahllosen Threads, dass es keine Universallösung gibt.
Dies und den Weg dahin nur der Vollständigkeit halber und vielleicht hilfts ja irgendwie irgendwann einaml ...