Debuggowanie FSXa. Jak rozwiązywać problemy?

Zawieszenia i przycięcia FSXa? To niestety problemy, z którymi zmagają się użytkownicy Flight Simulatora i podobnych otwartych platform. Jak znaleźć przyczynę kiedy używamy dziesiątków dodatków i reinstalacja nie wchodzi w grę? Trzeba szukać. Tu przeczytasz jak? i gdzie?

Przykładowy problem

Przykładowy ale realny. Czyli mój. Dzisiejszy. A właściwie mój z ostatnich dni. Czasami latając zauważałem przycięcia. Klatkowanie po ostatnich zabiegach (przeczytaj tekst o niewłaściwym tweakowaniu) jest już idealne, wrażenia wizualne są doskonałe, ale coś nie gra. Startuję z Gdańska i mniej więcej co minutę obraz zastyga. Czasem na sekundę, czasem na trzy. Rzadko na pięć ale i to się zdarza. Próbuję lotu gdzie indziej – Warszawa – to samo. Alaska – całkiem dobrze. Afryka – też dobrze. To pierwsza wskazówka! Problem nie jest globalny. Mimo to potraktuję go, jakby globalnym był, bo może dotyczyć co najmniej dwóch różnych scenerii. Na liście kandydatów są:

• openLC Europe (ORBX)
• Gdańsk (Drzewiecki Design)
• Warszawa (Drzewiecki Design)
• Okęcie (Drzewiecki Design)
• Wizualizacja punktów VFR
• 3d Landmarks dla Polski
• Ruch statków (darmowy dodatek ze statkami i ich szlakami żeglugowymi)

AI Traffic akurat mam wyłączony, ale to też zawsze dobry kandydat. No i standardowo kandydatem jest AS16. Bo czemu by go wyłączyć z listy podejrzanych? To, że nigdy nie powodował problemów nic tu nie znaczy – może jakaś specyficzna pogoda je wywołuje?

Podejrzanymi oczywiście są też samoloty – ale problemu u mnie występuje na każdym, który sprawdzałem – w tym na domyślnej cessnie, która jest świetną maszyną do testów.

Poradnik a CTD

Ten poradnik zasadniczo dotyczy tych problemów, które nie powodują wyłączenia symulatora. Jeśli wyłączenie następuje to pierwszym krokiem jest zbadanie przyczyny za pomocą podglądu zdarzeń Windowsa lub za pomocą aplikacji AppCrashView, która pomoże wskazać plik, który bezpośrednio lub pośrednio (częściej pośrednio) odpowiada za awarię. AppCrashView opiszę przy innej okazji, ale zachęcam do dalszej lektury – metody postępowania są podobne.

Myśl szeroko!

Jeśli szukam problemu z FSX to zawsze podchodzę do możliwości z otwartą głową. To, że coś działało tydzień temu nie oznacza, że musi działać dziś. Może coś zmieniłem w konfiguracji? Może jakieś ustawienia systemu wywołują teraz konflikt (a system się co chwilę aktualizuje). Możliwości jest mnóstwo i śledząc dyskusje w sieci widzę, że jedną z przyczyn problemów jest zamykanie oczu na nie.

Backup!

Procedura testów zaczyna się u mnie zawsze (ZAWSZE!!!) od wykonania kopii zapasowej istotnych plików. Kopie tworzę dwie – jedna ląduje obok plików konfiguracyjnych, w których będę grzebał, druga – na pulpicie (lokalizacja jest dowolna – chodzi o to, żeby mieć jakąś „twardą” kopię, z której nie korzystamy podczas prac – tego pliku nie wolno dotykać dopóki nie jest faktycznie potrzebny do ratowania się po skasowaniu potrzebnych danych).

Gdzie szukać?

Szukam problemu w trzech miejscach:

• Scenery Library
• dll.xml
• exe.xml

Oba pliki xml znajdują się w folderze z fsx.cfg. Scenery Library zapisana jest w folderze: C:\ProgramData\Microsoft\FSX

Pierwszym krokiem jest wykonanie kopii zapasowej. W przypadku Scenery Library kopiuję plik scenery.cfg – jedna kopia trafia na pulpit, druga z dopiskiem -bak w nazwie trafia do tego samego folderu. Podobnie dzieje się z dll i exe.

Jak testować?

Testując problemy szukam miejsca, w którym danym problem występuje. Akurat takie przycięcia łatwo przetestować, bo występują „szeroko”. Więc zapisuję lot nad lotniskiem i za każdym razem wczytam sobie ten zapisany lot – tak będzie szybciej.

Potencjalne przyczyny najlepiej eliminować zaczynając od tych, które najłatwiej przywrócić. Program pogodowy – uruchamiam FSX bez AS16, wczytuję lot, robię dwa kółka wokół lotniska – problem występuje. AS16 jest prawdopodobnie niewinny. EZCA – to samo. Uruchamiam symulator bez EZCA’i (po każdym teście wyłączam FSXa i uruchamiam ponownie) – problem występuje. Potencjalnie niewinny. Dalej.

Piszę „potencjalnie niewinny”, bo problemy mogą mieć kilka przyczyn. O niewinności dodatku świadczy to, że problemu w dłuższych testach po jego rozwiązaniu nie widać ponownie. Na razie tylko eliminujemy kandydatów.

A może to sceneria?

Pora na scenerie. Skoro problem występuje nad Polską, a nad USA i Kanadą już nie – sceneria jest dobrym kandydatem. Więc kolejno wyłączam scenerie sprawdzając kiedy problem zniknie. Zanim zrobisz jak piszę – poczytaj niżej o optymalizacji wyszukiwania problemów – oszczędzisz czasu.

Po wyłączeniu Gdańska – problem został rozwiązany. To sprawdzam nad Warszawą – dalej występuje. Wyłączam Warszawę i Okęcie – zniknął.

Oczywiście wyłączenie scenerii to nie jest rozwiązanie w tym przypadku. Gdyby to była jakaś pobrana w pośpiechu sceneria darmowa – skasowałbym ją i uznał problem za rozwiązany. Ale chodzi o różne scenerie renomowanego developera, bez których latać nie chcę. No to szukam dalej. Takie same poszukiwania należałoby przeprowadzić gdyby testy scenerii rezultatu nie dały.

A może do moduły (dll i exe)?

Po kolei biorę się za pliki dll.xml i exe.xml, które sterują uruchamianiem modułów współpracujących z FSXem. Oba zawierają wpisy kontrolujące kolejno uruchamiane dodatki. Jeden wpis wygląda tak:

<Launch.Addon>
<Name>VRS_TacPack</Name>
<Disabled>False</Disabled>
<ManualLoad>False</ManualLoad>
<Path>Modules\VRS_TacPack\VRS_TacPack.dll</Path>
</Launch.Addon>

Gdzie pogrubione części wpisu to nazwa i ścieżka do modułu. Pola Disabled i ManualLoad oznaczają, że moduł jest odpowiednio wyłączony lub wymaga załadowania ręcznego. Aby wyłączyć moduł wystarczy zmienić False na True w pozycji Disabled. Można też usunąć cały wpis (co właśnie robiłem).

Czyli usuwamy kolejno wpisy i testujemy rezultaty. Znów – zanim to zrobisz – przeczytaj o optymalizacji wyszukiwania – nie wyobrażam sobie 50 czy 150 uruchomień (mam sporo dodatków).

Po pewnym czasie wybrałem moduł, którego wyłączenie rozwiązuje problem – SODE. Krótka analiza problemu w myślach – SODE to dodatek obsługujący sterowanie sceneriami – otwiera drzwi do hangarów, bramy, zapala światła i tak dalej. Drzewiecki Design go używa w swoich sceneriach. Pasuje? Pasuje! To może go wyłączyć? Można, ale będą straty – jeśli dobrze pamiętam bez SODE na Okęciu nie ma rękawów (nie to, że nie działają – w ogóle ich nie ma). Czyli trzeba szukać dalej rozwiązania.

SODE

Czas na badanie SODE. W głównym folderze programu nie ma żadnych logów, więc szukam jeszcze w innych standardowych lokalizacjach, czyli w C:\Users\Username\AppData\Roaming, C:\Users\Username\AppData\Local i w C:\ProgramData\

W tym trzecim znalazłem folder 12bPilot (nazwa developera) i w nim SODE, a głębiej – Log.

W jednym z pliku logów w czasie dokładnie odpowiadającym moim problemem pojawił się wpis: sode Not able to create SimObject

Użyj google na końcu

Z tym już sam nic nie umiem zrobić. Kopiuję więc wpis z logów i wklejam do google pamiętając, żeby nie przeklejać konkretnego obiektu, którego SODE nie umiało utworzyć. Kopiowanie nazwy obiektu jedynie utrudni wyszukiwanie.

Pierwszy wynik – forum 12bPilot. Pierwsza odpowiedź w temacie – developer stwierdza:

I suspect that the fsx.cfg is missing the lines for the SODE related SimObjects. This can be fixed by running the SODEPlatformManager.exe and unregister and register again the SODE modules for your platform. I’m guessing that you’re using FSX…

Czyli wystarczy pobrać SODEPlatformManager.exe i sprawdzić czy mój program jest odpowiednio zarejestrowany w FSX. Okazuje się, że nie był (brak wpisu w fsx.cfg). Rejestracja, test – wszystko działa.

Czemu google na końcu? Dla weryfikacji tej teorii opisałem mój problem typowymi słowami kluczowymi i poszukałem rozwiązań. Znalazłem kilkanaście dyskusji, w których wiele osób wypowiadało się bez najmniejszego pojęcia w temacie. Co najmniej połowa wypowiedzi nie dotykała problemu – ich autorzy po prostu czuli niepohamowaną potrzebę wypowiedzenia się. W bodajże tylko dwóch dyskusjach pojawiło się SODE jako potencjalny powód. Wśród rad było odinstalowanie. Wśród rad było też przeinstalowanie FSX i skasowanie fsx.cfg (co akurat w moim przypadku było przyczyną problemu). Dlatego wyszukiwarki należy w takich przypadkach używać kiedy problem jest mniej więcej zlokalizowany i potrzebna jest wiedza bardzo specjalistyczna.

SODE Platform Manager powinien dawać taki wynik. Jeśli nie daje – kliknij „Register” lub „Activate” (lub oba).

Optymalizacja wyszukiwania

Pisałem wcześniej, że trzeba zlokalizować moduły lub scenerie odpowiedzialne za problem. Na niektórych forach czytałem „wyłączaj po jednym” i to ma sens… jeśli masz 5 scenerii i 3 inne dodatki. Ja mam trochę więcej i to nie wchodzi w grę. Dlatego moim zdaniem najlepiej działać masowo, eliminując całe grupy. Przykładowo ze sceneriami – zacząłem od stwierdzenia czy to sceneria, czy może jednak nie? Więc załadowałem Scenery Library z samymi domyślnymi elementami. Problem zniknął – czyli sceneria. Potem potrzebna jest izolacji problemu – skoro występuje nad Polską to wyłączę wszystkie „nie polskie” scenerie. Problem dalej występuje. No to (trochę na wyczucie) wszystkie nie wydane przez DD (lotniska komunikacyjne są bardziej skomplikowane więc są dobrym kandydatem). Znów – problem został – to czas na najbliższe lotnisko – koło Gdańska wyłączyłem Gdańsk – problem rozwiązany! Powtórzyłem eksperyment z Warszawą w locie koło Warszawy – znów – zadziałało. Nie ma potrzeby sprawdzania innych lotnisk – trzeba przejść do plików dll.xml i exe.xml (przy włączonych sceneriach, które powodują problem).

Pierwszy ruch – wyczyściłem całkiem dll.xml – nie pomogło. Więc przywróciłem go i zająłem się exe.xml. W moim jest 8 wpisów, więc łatwo to testować. Ale też zaczynam od usunięcia wszystkiego – pomogło! Więc to któryś z tych wpisów. Tu przydaje się trochę intuicji – wywaliłem wszystko poza SODE i trafiłem. Gdybym nie miał tej intuicji (nazwij ją doświadczeniem) to kasowałbym po połowie wpisów. Jeśli problem występuje – trzeba kasować dalej. Jeśli zniknie – trzeba przywrócić skasowane wpisy i usunąć pozostałe. A potem usunąć połowę tych, wśród których jest felerny. I tak do znalezienia tego jednego.

Wizualizacja problemu

Przycięcia monitorowałem Performance Monitorem Windowsa i GPU-Z – program pokazującym parametry karty graficznej. Ten ostatni idealnie oddaje co się działo:

Po prawej stronie wykresu (wykresy narastają z prawej do lewej co sekundę) widzicie obciążenie generowane przez FSX w locie. Test trwał trzy minuty, więc cały wykres nie został zapełniony. Zwróćcie uwagę na te regularne spadki – najlepiej je widać na wykresie GPU Memory Clock i GPU Load. Przerwa to właśnie przycięcie – przez pięć sekund nic się nie działo. Potem program podejmował działanie.

Po naprawie wykres wygląda tak:

Ładnie?