Findet man Ort von Absturz mit Hexeditor o.ä. Werkzeug?!

[Leutnant Triebisch]

Absturz game_exe.exe_.jpg (196.5 KiB) 2420 mal betrachtet

Moin Fans,

zu Abstürzen (besond. nach Moddingversuchen) von Sudden Strike & Co gibt es ja im Windows stets eine Ereignisanzeige - ich habe mal eine von Win 7 unten angehängt.

Jetzt kam mir die Idee einfach mal die Fehlerbeschreibung in Windows genauer anzuschauen - zum VerVergleich wird unter Win XP sogar eine Art Hex-Code angezeigt, der offenbar den ganz genauen Dateiort des Absturzes angibt. Zunächst kann man mit den Zahlenwerten natürlich wenig anfangen.

Gebe es denn eine Chance sich den genauen Dateifehlerort (welche Datei hat den Fehler verursacht, statt nur grob zu lesen dass die game_exe.exe abgestürzt ist!) mit einm Hexeditor oder etwas besseres anzeigen zu lassen?! - Also dass man sich der Hilfe eines speziellen Tools annimmt.

Gruß von
Leutnant Triebisch

[Gareth]

Dazu müsste man sich zunächst mal näher mit dem grundsätzlichen Aufbau solcher Log-Daten auseinandersetzen, damit man weiß, was für Informationen da eigentlich im Hexadezimalcode angegeben werden. Es wird sicher die eine oder andere Speicheradresse und die darin zum Absturzzeitpunkt enthaltenen Daten darunter sein. Ob das hilfreich ist, würde ich mal bezweifeln, da Windows den Arbeitsspeicher ja dynamisch verwaltet und daher bei unterschiedlichen Spielstarts die gleichen Daten an ganz verschiedenen Adressen liegen können. Was mit diesen Werten im abgestürzten Programm dargestellt wurde, ist auch nicht unbedingt zu erkennen. Von solchen Windows-Interna habe ich allerdings herzlich wenig Ahnung. Hatte noch nie wirklich Bedarf, mich damit zu beschäftigen.
Ganz allgemein zum Hexcode: Nur weil Daten im Hexadezimalsystem dargestellt werden, sind sie nicht automatisch hilfreich. Und ein Hexeditor ist auch keine Wunderwaffe, sondern einfach nur ein Programm, das beliebige Dateien in Hexadezimaldarstellung anzeigen kann. Das ist einfach nur eine Art, Zahlen darzustellen, sonst nix. Kürzer als die Binärdarstellung, aber zur Darstellung von Speicherinhalten besser geeignet als die Dezimaldarstellung, da 4 Bit immer genau eine Hexadezimalziffer ergeben: 0000=0; 0001=1;...; 1111=F. Das lässt sich einfach gut formatiert anzeigen, weil der Arbeitsspeicher auf Bytebasis strukturiert ist und 1 Byte=8 Bit mit 2 Hexziffern darstellbar ist. Anders als 4 Bits im Dezimalsystem: 0000=0;...0111=7;...;1111=15. Da kommen ein- und zweistellige Zahlen vor, was für die Darstellung weniger hübsch ist als die einheitliche Stellenanzahl im Hexcode.

[Leutnant Triebisch]

Grüzi Gareth,

danke für deine Antwort. Alles sehr interessant.
Kennst du evtl. noch andere bessere Experten-Tools/ Programme, welche mit Speicheradressenfindung also der von mir mit meinen laienhaften Worten dargestellten Problematik zurechtkommen/ geeignet wären?


Freundliche Grüße von
Leutnant Triebisch

[Gareth]

Nein, leider kenne ich keine solchen Programme. Ich habe auch keinen wirklichen Bedarf dafür, weil ich nur "für den Hausgebrauch" programmiere. Ein bisschen Hintergrund ist durch ein Informatikstudium zwar da, aber ich habe mich beruflich vor Jahren völlig neu orientiert, so dass Informatik in meinem Leben nicht mehr so präsent ist. Ich habe aber auch eher die theoretische Informatik, weniger die angewandte Informatik als Studienschwerpunkt gehabt.
Ich bin nicht sicher, ob es solche Programme, wie du sie suchst, in der Form überhaupt gibt. Man kann natürlich die Einträge aus dem Event-Log genau auswerten, wenn man sich damit auskennt. Ob man aber an diesen Log-Informationen wirklich erkennen kann, worauf der Absturz SuSt-intern zurückzuführen ist, das möchte ich mal bezweifeln. Meines Wissens landet in so einem Log nur das, was Windows von dem Absturz mitbekommt. Das ist aber vor allem das, was von Windows in gewissem Maße mitverwaltet wird (Aufrufe von Windows-Funktionen, Speicher- und Festplattenzugriffe und so Zeug). Windows schaut also: Was hat das Programm, das da eben abgeschmiert ist, zuletzt gemacht und mit mir "abgesprochen"? Es wird eher nicht so sein, dass SuSt beim oder gar nach dem Absturz noch zu Windows sagt: Ich habe gerade die Datei xyz aufgemacht, weil Einheit abc auf der Map bla explodiert ist, aber an dem Inhalt der Datei habe ich mir den Magen verdorben. Ich dachte mir, ich stürz' jetzt mal ab.
Bei diesen Überlegungen bzgl. der Fehlersuche laufen wir mMn einfach immer wieder vor die Wand, hinter der sich die spielinternen Strukturen verbergen. Ohne die zu kennen, muss man wohl mit Versuch und Irrtum arbeiten und das ist eben mühselig. Hölpt allns nix, wie man hier im Norden sagt...

[Leutnant Triebisch]

@Gareth

...klar ist schade, aber hatte schon damit gerechnet. Allerdings fällt mir noch eines ein. Ein Kumpel meinte, dass es generell von Seiten der Spielentwickler Prüftools geben muss, mit welchen die die Spielfähigkeit des Game auf Fehler überprüfen, bevor es dann in den offiziellen Vermarktung/Verkauf geht. Siehst du da Möglichkeiten an sowas ranzukommen?!

Schönen Gruß von
Leutnant Triebisch

[Gareth]

Ein Kumpel meinte, dass es generell von Seiten der Spielentwickler Prüftools geben muss, mit welchen die die Spielfähigkeit des Game auf Fehler überprüfen, bevor es dann in den offiziellen Vermarktung/Verkauf geht. Siehst du da Möglichkeiten an sowas ranzukommen?!

In der Allgemeinheit würde ich die Aussage deines Kumpels mal in Frage stellen. Was soll denn so ein Programm tun? Den Code des Spiels in irgendeiner Form „durchrechnen“ und dann sagen, dass die „Spielfähigkeit“ gegeben ist? Das ist in der Form so viel Aufwand, dass der Entwickler den nicht treiben wird. Eine vollständige Programmverifikation wird nicht umsonst nur bei extrem sicherheitskritischen Anwendungen durchgeführt, aber garantiert nicht bei Spielen.
Sicher werden von der Qualitätssicherung Tools benutzt, aber was das für welche sind, dürfte sehr unterschiedlich sein. Das kann vom Standard-Debugger der Entwicklungsumgebung bis zu speziell für ein bestimmtes Spiel und dann wohl auch für ganz bestimmte Aspekte dieses Spiels erstellten Tools gehen. Vieles wird aber nach wie vor ganz altmodisch getestet, indem die Tester das Spiel spielen und dabei versuchen, auch völlig abstruse Aktionen auszuführen, um zu sehen, ob das Spiel darauf sinnvoll reagiert oder nicht.
Und selbst wenn Fireglow genau so ein Tool entwickelt und benutzt hätte, dann dürfte dafür dasselbe gelten wie für den SuSt-Quelltext: Lost in Limbo...

[Leutnant Triebisch]

Many Thanks Gareth,

mir fiel noch etwas ein: Es gab doch mal die zusätzl. Sudden-Strike-CD's (Total Victory u.a. für Sudden Strike 2) von der Firma INTEX Publishing (Sitz der Firma war glaub ich in Karlsruhe). Die schienen ja auch ziemliche Kenntnisse von den Sudden-Strike-Strukturen zu haben. Gab ja auf den CD's auch ein Modding-Tutorial. War auch alles sehr gut beschrieben an Modding-Bespielen erklärt.

Weißt du zufällig ob es da noch Kontakte gibt zu Membern von INTEX oder kennst jemanden der mal Kontakt hatte?


Schönen Gruß von
Leutnant Triebisch

[Gareth]

Nein, da habe ich keine Informationen zu. Die Firma Intex Publishing hat sich schon vor Jahren in eine andere Richtung entwickelt. Mit Spielen haben die lange nichts mehr am Hut. Ob sich in der Firma überhaupt noch jemand daran erinnert, dass sie mal was für SuSt auf den Markt gebracht haben (und ja auch "Winterschlacht in den Ardennen 1944" entwickelt haben, wenn ich mich recht erinnere)?
Bei dem Editor Kit bin ich aber auch der Meinung, dass die Infos darin im wesentlichen aus den damals noch zahlreich vorhandenen verschiedenen Foren zusammengetragen und dann hübsch aufbereitet verkauft wurden. Ich erinnere mich z.B. daran, dass in der Anleitung noch völlige Unkenntnis bzgl. der inf-Dateien geäußert wurde. Das spricht mMn nicht unbedingt dafür, dass die Leute bei Intex mehr und tiefere Einsichten in SuSt hatten als wir das mittlerweile durch die Arbeiten der Community haben. Auch die von Intex entwickelten Map Packs Total War und Total Victory sprechen eher nicht für geballtes SuSt-Knowhow, die Missionen darin erreichen ja nicht einmal das Niveau der Missionen aus Vanilla SuSt.
Winterschlacht in den Ardennen 1944 war dann aber "ganz nett", hatte aber natürlich nichts mit SuSt zu tun. Ich könnte mir auch vorstellen, dass Intex damals einfach ein paar Missionen auf der Basis der Engine von Digital Reality (aus D-Day und AKvsDR) erstellt hat, um das Ganze dann als neues Spiel zu verkaufen. Neue Features gab es da aber nach meiner Erinnerung auch nicht, also haben sie die Engine wohl nur im Auftrag oder in Lizenz benutzt, aber nicht erweitert.

Ich fürchte, du musst dich damit abfinden, dass uns keine SuSt-Erleuchtung mehr bevorsteht...

[Leutnant Triebisch]

Besten Dank für deine Zeilen. Ja, hast schon recht Gareth, die Hoffnung stirbt zuletzt.

Aber andererseits: Man soll nie aufgeben - alter militärischer Grundsatz!


Greetings from
Leutnant Triebisch

[zarathustra]

Gebe es denn eine Chance sich den genauen Dateifehlerort (welche Datei hat den Fehler verursacht, statt nur grob zu lesen dass die game_exe.exe abgestürzt ist!) mit einm Hexeditor oder etwas besseres anzeigen zu lassen?

Beim Start werden Karte und Mission in einen temporären Ordner entpackt:
..\xchng\ToGame\

[Leutnant Triebisch]

Thanks zarathustra,

vielen Dank für den Hinweis. Interessant, ich schaue mir deinen Tipp mal näher an, kannte ich überhaupt noch gar nicht...man lernt eben nie aus.


Schönen Gruß von
Leutnant Triebisch

[Gareth]

Bin beim Blättern in meinem Archiv auf Informationen gestoßen, die man hier im Forum findet. Dort werden Hinweise auf mögliche Absturzursachen gegeben.

[Leutnant Triebisch]

Moin Gareth,

ja danke dir, den Artikel hatte ich auch vor kurzem entdeckt, sehr aufschlussreich. Zu dem LOG noch einmal eine Frage an Dich. Kenne das aus 'Battlefield 2' - Von vornherein gibt es dort auch keine LOG-Datei. Im Netz fand ich aber eine Anleitung wie man diese sich schaffen kann. Funktioniert auch tadellos.
Könnte man aus Programmierersicht (die Leute können eher so eine Möglichkeit aufzeigen wie man das hinbekommt) das Sudden Strike dazu auch bringen ähnlich wie in BF 2 eine LOG-Datei auszugeben?!


Schönen Gruß von
Leutnant Triebisch

[Gareth]

Dazu müsste ich erstmal wissen, wie es bei BF2 geht. Spontan würde ich aber bezweifeln, dass man bei SuSt ein aussagekräftiges Log „nachrüsten“ kann.
Dazu müsste SuSt entweder intern Log-Funktionen haben, die man aufrufen kann (wissen wir nicht), oder wir müssten wissen, wo im Speicher die relevanten Daten stehen, die wir in einer Log-Datei sehen wollen (wissen wir auch nicht).

[Leutnant Triebisch]

Hi Gareth,

so, jetzt habe ich erstmal dieses LOG-File von BF2 auf meinem Game-Rechner gefunden. Siehe unten angehängt (-> die Endung *.txt musste ich machen, da er sonst meckert beim Hochladen wegen falscher Dateiendung?!!).

Wir hatten die Anleitung dazu letztes Jahr im Februar im Netz gefunden. Zwar habe ich im Browserverlauf im "Feurigen Fuchs" nachgeschaut, aber die Seite in einem ersten Suchlauf zunächst nicht mehr gefunden. Wenn ich bei Google dazu einen eindeutigen Suchbegriff eingebe, findet er komischerweise auch nichts...?! Gebe aber nicht auf und schaue nochmal.

Wiegesagt das "mylogfile.log" gibt es so bei Battlefield 2 nicht. Konnte aber mit der Anleitung ohne Probleme erstellt werden (weil wir oft auch das Problem bei BF2 hatten, dass der Host nicht dem Spiel beitreten konnte angeblich weil modifizierter Server-ein bekanntes nerviges Problem im BF2-LAN).

Wenn ich die Anleitung gefunden habe, poste ich das hier noch rein.

Hitzigen Gruß von
Leutnant Triebisch