Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: Friendly Flusi. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

matthes_f

Teststreifen

Beiträge: 690

Wohnort: Frankfurt am Main

Beruf: Spürhund

  • Nachricht senden

41

Mittwoch, 22. Juni 2011, 22:18

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. :leider:

Morgen starte ich dann noch einmal von EDDS.

VG :bier:
Matthes
Intel® Core™ i7-3930K@4,5 GHz
G.Skill DIMM 32 GB DDR3-2133 Quad-Kit
Asus Rampage IV Extreme
Gainward GTX 780 GLH
be quiet! Dark Power Pro P7, 850 W
Samsung 840 Evo 2,5" SSD 250 GB", (WIN7)
Samsung 840 Evo 2,5'' SSD 500 GB (FSX)
Gehäuse Corsair Obsidian 800D, Wasserkühlung Innovatek i7 Dual + Konvekt-O-Matic ULTRA-plus (CPU, GPU)

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »matthes_f« (22. Juni 2011, 22:18)


Beiträge: 1 303

Wohnort: Frankfurt-Zeilsheim

Beruf: ...ääämm

  • Nachricht senden

42

Mittwoch, 22. Juni 2011, 22:49

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.

matthes_f

Teststreifen

Beiträge: 690

Wohnort: Frankfurt am Main

Beruf: Spürhund

  • Nachricht senden

43

Donnerstag, 23. Juni 2011, 21:21

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! :bussi

VG

Matthes
Intel® Core™ i7-3930K@4,5 GHz
G.Skill DIMM 32 GB DDR3-2133 Quad-Kit
Asus Rampage IV Extreme
Gainward GTX 780 GLH
be quiet! Dark Power Pro P7, 850 W
Samsung 840 Evo 2,5" SSD 250 GB", (WIN7)
Samsung 840 Evo 2,5'' SSD 500 GB (FSX)
Gehäuse Corsair Obsidian 800D, Wasserkühlung Innovatek i7 Dual + Konvekt-O-Matic ULTRA-plus (CPU, GPU)

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »matthes_f« (23. Juni 2011, 21:23)


44

Samstag, 25. Juni 2011, 13:43

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?
Günter

endlich Berliner! :lol:
i7 930@4.2Ghz WaKü, GTX 580 3GB, 12GbRAM1600, Win10 64 Prof


Beiträge: 1 303

Wohnort: Frankfurt-Zeilsheim

Beruf: ...ääämm

  • Nachricht senden

45

Samstag, 25. Juni 2011, 15:43

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.

46

Samstag, 25. Juni 2011, 16:12

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.
Gruß,
Otto

Beiträge: 1 303

Wohnort: Frankfurt-Zeilsheim

Beruf: ...ääämm

  • Nachricht senden

47

Samstag, 25. Juni 2011, 16:48

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.

gianni

Polygonist

  • »gianni« ist der Autor dieses Themas

Beiträge: 925

Wohnort: at the end of the rainbow

  • Nachricht senden

48

Sonntag, 3. Juli 2011, 12:12

Wolfgang aus dem Salzkammergut hat beobachtet und im aeroSOFT-Supportforum gepostet, dass zumindest bei seinem Setting die Wasserdarstellung Einfluss auf derlei Abstürze haben könnte. Ein Zurückdrehen auf 1fache Darstellung hat bei ihm geholfen.

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...

lg
"gianni"

49

Sonntag, 3. Juli 2011, 12:18

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 :hm:
Gruß Klaus


Mein PC:ASUS Max VI / i7-4770K @ 4,5 GHz/GIGABYTE GTX 760 4095 MB / G.Skill 16GB DDR3-1866 / WD Black 1 TB / Sys: 256 GB ForceGS /FSX: 500 GB 840 EVO / TM-Warthog / FSX - ACC / OS: Win 7 64-Bit

gianni

Polygonist

  • »gianni« ist der Autor dieses Themas

Beiträge: 925

Wohnort: at the end of the rainbow

  • Nachricht senden

50

Sonntag, 3. Juli 2011, 12:22

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 :hm:
Kann ich Dir nicht sagen - ich denke aber, dass sich das auf die GRAKA bezieht.
"gianni"

Beiträge: 1 303

Wohnort: Frankfurt-Zeilsheim

Beruf: ...ääämm

  • Nachricht senden

51

Sonntag, 3. Juli 2011, 13:24

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

#grüße. Friedi.

gianni

Polygonist

  • »gianni« ist der Autor dieses Themas

Beiträge: 925

Wohnort: at the end of the rainbow

  • Nachricht senden

52

Montag, 4. Juli 2011, 13:01

Die Hinweise verdichten sich, dass die Wassereinstellungen was mit dem Problem zu tun haben. Bitte das prioritär testen, wenn's geht.
Dankeschön jedenfalls!

:tag:
"gianni"

Beiträge: 1 303

Wohnort: Frankfurt-Zeilsheim

Beruf: ...ääämm

  • Nachricht senden

53

Mittwoch, 6. Juli 2011, 10:44

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.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Friedi« (6. Juli 2011, 10:47) aus folgendem Grund: Schreibfehler


54

Mittwoch, 6. Juli 2011, 11:46

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
Gruß,
Otto

Beiträge: 1 303

Wohnort: Frankfurt-Zeilsheim

Beruf: ...ääämm

  • Nachricht senden

55

Mittwoch, 6. Juli 2011, 12:35

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.

56

Mittwoch, 6. Juli 2011, 15:02

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.
Gruß,
Otto

Beiträge: 1 303

Wohnort: Frankfurt-Zeilsheim

Beruf: ...ääämm

  • Nachricht senden

57

Donnerstag, 7. Juli 2011, 13:21

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.
»Friedi« hat folgende Datei angehängt:

gianni

Polygonist

  • »gianni« ist der Autor dieses Themas

Beiträge: 925

Wohnort: at the end of the rainbow

  • Nachricht senden

58

Freitag, 8. Juli 2011, 10:56

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

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

Herzlichen Dank an alle, die diesen Test absolviert haben. Es dürfte nun klar sein, dass die Szenerie selbst nicht der primäre Auslöser möglicher g3d.dll Probleme ist (wobei ich auf die zusätzlichen Erkenntnisse im offiziellen aeroSOFT-Support Forum verweisen möchte). Es scheint so zu sein, dass die Meldung von MSFSX, wonach es ein Problem mit der genannten Datei gibt, mehrdimensionale Ursachen hat. Es ist also nicht möglich, das Problem wirklich zu reproduzieren oder wirklich einzugrenzen.

Grosso Modo haben wir die Erkenntnis gewonnen, dass in manchen Konstellationen die Speicher und die Grafik-Engine nicht mehr fehlerfrei miteinander kommunizieren.

DesignTeam stellt daher die Ursachenforschung ein. Ich lasse den Thread aber offen, damit allenfalls neue Erkenntnisse gepostet werden können.

lg und danke nochmals :)
"gianni"

59

Sonntag, 31. Juli 2011, 23:38

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 ...
Günter

endlich Berliner! :lol:
i7 930@4.2Ghz WaKü, GTX 580 3GB, 12GbRAM1600, Win10 64 Prof


gianni

Polygonist

  • »gianni« ist der Autor dieses Themas

Beiträge: 925

Wohnort: at the end of the rainbow

  • Nachricht senden

60

Montag, 1. August 2011, 11:36

Hi,

es ist klar, dass der Fehler immer an derselben Stelle auftritt - kurz nach RTT NDB werden ja die Texturen der Szenerie geladen. Es wäre jetzt interessant zu wissen, ob die Entfernung von der Szenerie ein möglicher Auslöser ist; dann müßte der gd3.dll Fehler ja immer im selben Radius um LOWI auftreten. Wäre das nicht der Fall, dann hängt es vielleicht mit dem NDB zusammen.

Allerdings - wie Du richtig vermerkst, ist es offensichtiglich nicht die Szenerie, die zu den Fehlern führt, sondern das Zusammenwirken vieler Faktoren beim einzelnen User. Vielleicht wird der FSX der jeweiligen User einfach mit der Textur-Menge und/oder -Größe fertig. Bei Brisbane von ORBX gibt es das Problem ja auch. Workarounds scheinen zu sein:

1) das Herunterstellen des LOD-Levels

2) das Herunterstellen der Autogendichte

3) das Herunterstellen der Wasserdarstellung
"gianni"

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »gianni« (1. August 2011, 11:37)


Zur Zeit ist neben Ihnen 1 Benutzer in diesem Thema unterwegs:

1 Besucher