Jakiś czas temu napisaliśmy małą aplikację, która pozwala optymalizować czas urlopu. KiedyUrlop – bo o niej mowa działała sobie już sporo czasu – nikt nie narzekał (może poza mną gdy patrzyłem na zbyt małą liczbę pobrań), aż kilka dni temu znajomy oznajmił mi, że KiedyUrlop się nie odpala. Sprawdziłem u siebie i rzeczywiście – zaraz po starcie aplikacja zamyka się i niewiele możemy z nią zrobić. Aurę tajemniczości problemu zwiększył jeszcze fakt, że świeżo zainstalowana wersja ze sklepu działa jak trzeba. Nie było wyjścia – trzeba było problem przeanalizować…
Na pierwszy ogień poszedł EventLog. Okazało się, że był tam wpis, który tyczył się naszej aplikacji.
Hmmm – combase.dll – wujek google coś tam na ten temat mówi, ale nic oczywistego. Zacznijmy zatem bardziej szczegółową analizę. Zaczynamy od uruchomienia aplikacji w Process Monitorze.
Po odpowiednim przefiltrowaniu eventów widzimy, że uruchamia się WER – Windows Error Reporting. Usługa ta ma na celu powiadomienie MS o crash’ach aplikacji wraz z przesłaniem interesujących plików do analizy. Przeglądając wpisy WERa odnajdujemy dość szybko ścieżkę gdzie te pliki sobie zapisał
Wśród plików mamy też dwa pliki .dmp/.hdmp, które to będziemy mogli sobie podejrzeć. Visual Studio całkiem dobrze sprawdza się w analizowaniu dumpów (co nie każdy wie), zatem otwórzmy je sobie w nim.
Po wczytaniu wybieramy “Debug with Mixed” i lądujemy w kodzie z naszym wyjątkiem
Jakiś paskudny NullReferenceException – rzeczywiście miliardowa pomyłka świata IT 🙂 ale prócz tego niewiele. Nic – trzeba analizować dalej…
Ponownie w ruch poszedł Process Monitor – tym razem jednak postanowiłem przyjrzeć się logowi (logu?) pod innym kątem. Tool ma fajną opcję – potrafi zagregować dane i pokazać je w formie zbiorczej. Oto co ukazało się po wybraniu jako agregowaną daną kolumnę Result.
Zakładając, że nasz błąd to sytuacja wyjątkowa możemy iść od najrzadszych resultatów i sprawdzać jakich eventów i obiektów dotyczą. Podejrzanie wygląda ta wartość CANCELLED z 4 wystąpieniami. Dwuklikamy ten element na liście i w głównym oknie wyfiltrowują nam się tylko te wpisy, które takim rezultatem się zakończyły.
Hmm…przecież to pliki odpowiedzialne za przechowywanie informacji o dniach wolnych. Sprawdźmy jak zachowa się aplikacja gdy je skasujemy. Przechodzimy do nich za pomocą opcji Jump To z Process Monitora i kasujemy. Odpalamy KiedyUrlop ponownie i voilà. Aplikacja uruchamia się bez problemu. Skoro już wiemy co naprawia błąd – teraz pozostało jeszcze zdiagnozować go w VS i znaleźć przyczynę. Po uruchomieniu w VS i podrzuceniu plików versionFile.json oraz actualYearDataFile.json VS ładnie przywitał nas wyjątek na linijce tworzenia zapisu danych do pliku:
CreateFileAsync(filename)
Wystarczyło dopisać jako drugi parametr CreationCollisionOption.ReplaceExisting i gotowe. Bug zlokalizowany. Naprawiony. Dzięki ci Mark Russinovich za świetne narzędzia. Nowa wersja aplikacji w Store i po pobraniu aktualizacji wszystko działa.
Founder of Octal Solutions a .NET software house.
Passionate dev, blogger, occasionally speaker, one of the leaders of Wroc.NET user group. Microsoft MVP. Podcaster – Ostrapila.pl