Błędy systemowe enova365 – wyjątki .NET, błędy bazy danych, awarie serwisu – wymagają metodycznej diagnostyki opartej na logach i śladzie stosu wywołań. Bez precyzyjnej diagnozy nawet doświadczony serwisant może tracić czas na nieskuteczne próby naprawy. Dysponujemy narzędziami i metodologią pozwalającą sprawnie zidentyfikować i usunąć przyczynę każdego błędu systemowego enova365.
Źródła informacji diagnostycznych
Diagnozę błędów enova365 opieramy na kilku źródłach: dziennik zdarzeń Windows (Event Viewer → Logi aplikacji → zawiera wyjątki .NET z pełnym śladem stosu), pliki logów enova365 (zlokalizowane w katalogu instalacji lub katalogu danych aplikacji, zawierają logi operacji aplikacyjnych i błędów połączeń), SQL Server Error Log (błędy na poziomie silnika bazy danych) oraz logi serwisu enova.svc (dla błędów warstwy pośredniej).
Analiza śladów stosu .NET
Błędy aplikacyjne enova365 generują ślad stosu .NET (stack trace) wskazujący dokładnie, w którym miejscu kodu nastąpił wyjątek. Analizujemy ślad stosu identyfikując: typ wyjątku (NullReferenceException, SqlException, OutOfMemoryException), metodę, w której wystąpił błąd i ciąg wywołań prowadzący do błędu. Ta informacja pozwala precyzyjnie określić, czy błąd wynika z danych, konfiguracji czy kodu aplikacji, i jakie działanie naprawcze jest właściwe.
Debugowanie w środowisku testowym
Dla błędów trudnych do zdiagnozowania na produkcji tworzymy kopię środowiska i odtwarzamy błąd w izolacji – możemy wtedy eksperymentować bez ryzyka. Używamy narzędzi profilowania .NET (np. JetBrains dotTrace lub Visual Studio Diagnostic Tools) do analizy zużycia pamięci i czasu wykonania. Dokumentujemy kroki reprodukcji błędu i wyniki analizy, co jest niezbędne do zgłoszenia błędu do Sonety jeśli okaże się bugiem aplikacyjnym.
