Komputer zaczyna się zawieszać, aplikacja .NET zamyka się bez komunikatu albo system długo uruchamia usługę? W takich sytuacjach dziennik zdarzeń Windows często pokazuje, co wydarzyło się chwilę wcześniej i który składnik był za to odpowiedzialny. Wyjaśniam, gdzie go znaleźć, jak czytać wpisy, filtrować zdarzenia oraz wykorzystać PowerShell i .NET do sprawniejszej diagnostyki.
Najważniejsze informacje o diagnostyce zdarzeń w Windows
-
Podgląd zdarzeń uruchomisz poleceniem
eventvwr.mscalbo z menu Start. - Najczęściej analizuje się dzienniki Aplikacja, System i Zabezpieczenia.
- Sam poziom „Błąd” nie oznacza jeszcze awarii. Liczy się czas, źródło, identyfikator i treść wpisu.
- Do szybkiego filtrowania wielu rekordów najlepiej sprawdza się PowerShell i Get-WinEvent.
- Wpisy można zapisać do pliku .evtx i przekazać do dalszej analizy.
Gdzie znaleźć dzienniki zdarzeń w Windows
Najprostszym sposobem jest otwarcie menu Start i wpisanie „Podgląd zdarzeń”. Możesz też nacisnąć Win + R, wpisać eventvwr.msc i zatwierdzić Enterem. To wbudowana konsola administracyjna, która zbiera informacje z systemu, usług i aplikacji.
Po lewej stronie zobaczysz kilka głównych grup. Na początek interesują Cię przede wszystkim Dzienniki systemu Windows oraz Dzienniki aplikacji i usług. Druga grupa bywa szczególnie cenna przy diagnozowaniu konkretnych komponentów, na przykład Windows Update, sterowników, Defendera czy usług używanych przez aplikację desktopową.
| Dziennik | Kiedy go sprawdzać |
|---|---|
| Aplikacja | Gdy program zamyka się, zgłasza wyjątek albo nie może wykonać operacji. |
| System | Gdy problem dotyczy sterownika, usługi, dysku, sieci lub uruchamiania systemu. |
| Zabezpieczenia | Gdy analizujesz logowania, uprawnienia, audyt i działania związane z kontami. |
| Konfiguracja | Gdy potrzebujesz informacji o instalacji aktualizacji, składników lub zmianach systemowych. |
| Dzienniki aplikacji i usług | Gdy zwykły dziennik aplikacji nie pokazuje wystarczających szczegółów. |
Pliki dzienników są przechowywane między innymi w katalogu C:\Windows\System32\winevt\Logs, ale nie polecam otwierania ich ani modyfikowania bezpośrednio. Do odczytu używaj Podglądu zdarzeń, PowerShella albo bibliotek systemowych, ponieważ narzędzia te poprawnie interpretują strukturę plików .evtx.
Jak czytać pojedyncze zdarzenie
Lista wpisów zawiera zwykle datę i godzinę, poziom, źródło oraz identyfikator zdarzenia. Najczęściej spotkasz poziomy Informacje, Ostrzeżenie, Błąd i Inspekcja zakończona powodzeniem lub niepowodzeniem.
Nie traktuję czerwonej ikony jako gotowej diagnozy. Windows zapisuje wiele błędów przejściowych, które nie mają praktycznego wpływu na działanie komputera. Największą wartość ma korelacja kilku informacji: co wydarzyło się tuż przed problemem, jaki proces był źródłem wpisu i czy zdarzenie powtarza się regularnie.
Najważniejsze pola wpisu
- Źródło wskazuje komponent, który zapisał zdarzenie, na przykład Service Control Manager, Application Error albo konkretna usługa.
- Identyfikator zdarzenia pomaga odróżnić typy problemów w ramach jednego źródła.
- Poziom pokazuje wagę zgłoszoną przez producenta komponentu, ale nie zawsze opisuje rzeczywisty wpływ na użytkownika.
- Użytkownik i komputer wskazują kontekst, w którym zdarzenie zostało zarejestrowane.
- Zakładka Szczegóły często zawiera dane, których nie widać w krótkim opisie, na przykład nazwę modułu, kod wyjątku albo identyfikator procesu.
Przy awarii programu zwracam uwagę na wpisy Application Error i .NET Runtime. Kod wyjątku, nazwa uszkodzonego modułu oraz czas zdarzenia często pozwalają odróżnić błąd aplikacji od problemu z systemem, biblioteką DLL albo sterownikiem.
Sam identyfikator zdarzenia nie wystarcza do pewnej diagnozy. Ten sam numer może pojawić się w różnych wersjach Windows lub w odmiennych konfiguracjach, dlatego zawsze analizuj go razem ze źródłem, treścią i pełnymi szczegółami.
Jak filtrować i eksportować wpisy
Przeglądanie tysięcy rekordów jeden po drugim jest stratą czasu. W wybranym dzienniku kliknij Filtruj bieżący dziennik, a następnie zawęź zakres po poziomie, źródle, identyfikatorze zdarzenia i przedziale czasu.
Przy diagnozowaniu awarii najlepiej zacząć od okresu obejmującego kilka minut przed i po problemie. Zbyt szeroki zakres zwykle zasypuje wynikami, a zbyt wąski może pominąć zdarzenie poprzedzające właściwy błąd.
Praktyczne filtrowanie w PowerShellu
PowerShell jest wygodniejszy od interfejsu graficznego, gdy trzeba przeszukać wiele komputerów albo powtarzać analizę. Przykładowe polecenie pobiera 50 najnowszych błędów z dziennika systemowego:
Get-WinEvent -FilterHashtable @{
LogName = 'System'
Level = 2
} -MaxEvents 50Możesz też ograniczyć wynik do konkretnego źródła lub czasu:
Get-WinEvent -FilterHashtable @{
LogName = 'Application'
ProviderName = '.NET Runtime'
StartTime = (Get-Date).AddHours(-2)
} | Select-Object TimeCreated, Id, LevelDisplayName, MessageWedług dokumentacji Microsoft polecenie Get-WinEvent obsługuje zarówno klasyczne dzienniki zdarzeń, jak i zdarzenia związane z ETW. W praktyce jest szybsze i bardziej elastyczne niż starsze Get-EventLog, szczególnie przy filtrowaniu po czasie oraz wielu kryteriach.
Jeśli chcesz przekazać wpisy do dalszej analizy, wybierz w Podglądzie zdarzeń opcję Zapisz wszystkie zdarzenia jako i użyj formatu .evtx. Pojedynczy wpis można również skopiować jako tekst lub XML. Format XML jest przydatny, gdy analizujesz dodatkowe pola niewidoczne w podstawowym widoku.
Co sprawdzać przy typowych problemach
Dzienniki są najbardziej użyteczne wtedy, gdy szukasz odpowiedzi na konkretne pytanie. Nie próbuj analizować całej historii systemu naraz. Najpierw ustal moment wystąpienia problemu, a potem sprawdź wpisy z kilku minut wokół tego czasu.
Aplikacja zamyka się bez komunikatu
W dzienniku Aplikacja wyszukaj zdarzenia z czasu zamknięcia programu. Interesują Cię przede wszystkim nazwa aplikacji, kod wyjątku, moduł powodujący błąd i ewentualny wpis .NET Runtime. Jeśli aplikacja korzysta z własnego źródła zdarzeń, sprawdź również odpowiedni kanał w sekcji aplikacji i usług.
System długo się uruchamia
Sprawdź dziennik System oraz wpisy dotyczące usług. Powtarzające się problemy Service Control Manager mogą wskazywać na usługę, która startuje z opóźnieniem, kończy pracę albo czeka na zależność. Pojedynczy wpis po aktualizacji nie musi oznaczać trwałej usterki.
Komputer zawiesza się lub restartuje
Szukaj zdarzeń związanych z Kernel-Power, sterownikami, dyskiem i sprzętem. Wpis Kernel-Power o identyfikatorze 41 informuje zwykle, że system nie został prawidłowo zamknięty, ale sam nie wyjaśnia przyczyny. Może być skutkiem utraty zasilania, twardego resetu, przegrzania albo wcześniejszego błędu sterownika.
Przeczytaj również: VCRUNTIME140.dll i MSVCP140.dll - jak naprawić błąd?
Nie działa logowanie lub uprawnienia
W takich przypadkach przydatny jest dziennik Zabezpieczenia. Pamiętaj jednak, że zakres zapisywanych zdarzeń zależy od włączonych zasad audytu. Brak wpisu nie zawsze oznacza, że działanie się nie wydarzyło, lecz czasem tylko to, że system nie miał skonfigurowanego rejestrowania danego typu aktywności.
Dziennik zdarzeń w aplikacjach .NET
Jeżeli tworzysz aplikację desktopową w .NET, możesz zapisywać własne informacje w systemie zdarzeń. Ma to sens przy błędach występujących tylko u części użytkowników, problemach z konfiguracją albo awariach, których nie da się odtworzyć lokalnie.
W prostym scenariuszu użyjesz klasy EventLog:
using System.Diagnostics;
if (!EventLog.SourceExists("MojaAplikacja"))
{
EventLog.CreateEventSource("MojaAplikacja", "Application");
}
using var log = new EventLog("Application")
{
Source = "MojaAplikacja"
};
log.WriteEntry(
"Nie udało się wczytać konfiguracji.",
EventLogEntryType.Error,
1001);Tworzenie źródła zdarzeń może wymagać uprawnień administratora, dlatego nie powinno odbywać się przy każdym uruchomieniu programu. Lepiej przygotować źródło podczas instalacji aplikacji albo użyć mechanizmu logowania, który zapisuje dane do własnego pliku.
W aplikacjach produkcyjnych nie zapisuj haseł, tokenów, pełnych danych osobowych ani całych obiektów żądań. Dziennik może być dostępny dla administratorów i narzędzi monitorujących, więc powinien zawierać minimum informacji potrzebnych do diagnozy. Przy większych projektach warto połączyć logowanie lokalne z centralnym systemem obserwowalności.
Jeśli interesuje Cię także programistyczna obsługa zdarzeń, dobrym uzupełnieniem jest dokumentacja zdarzeń systemu Windows, która opisuje model kanałów, dostawców i odczytu danych przez API.
Najczęstsze błędy podczas analizy logów
Pierwszy błąd to traktowanie każdego ostrzeżenia jak awarii. System może zapisać ostrzeżenie, a mimo to działać poprawnie. Znacznie ważniejsza jest powtarzalność i zgodność czasowa z obserwowanym problemem.
Drugi błąd polega na wyszukiwaniu identyfikatora zdarzenia bez sprawdzania źródła. Zanim wyciągniesz wnioski, zanotuj pełną nazwę dostawcy, wersję systemu, godzinę i treść wpisu. Dopiero wtedy porównuj zdarzenie z dokumentacją lub innymi przypadkami.
Trzeci problem to zbyt mały rozmiar dziennika. Gdy log szybko się przepełnia, starsze wpisy mogą być nadpisywane. Właściwości każdego dziennika pozwalają ustawić maksymalny rozmiar pliku i sposób przechowywania zdarzeń, ale zwiększanie limitu ma sens tylko wtedy, gdy masz wystarczająco dużo miejsca na dysku.
Nie czyść dzienników tylko po to, by „zniknęły błędy”. Usunięcie wpisów kasuje materiał diagnostyczny i może utrudnić analizę incydentu. Jeśli potrzebujesz porządku, najpierw wyeksportuj log, a dopiero później rozważ jego wyczyszczenie zgodnie z procedurą administracyjną.
Jak zamienić pojedynczy wpis w użyteczną diagnozę
Najlepszy efekt daje krótka, powtarzalna procedura. Zanotuj dokładną godzinę problemu, sprawdź kilka minut wcześniejszych zdarzeń, porównaj wpisy z dziennika aplikacji i systemu, a na końcu wyeksportuj dane, zanim zaczniesz zmieniać konfigurację.
W praktyce nie szukam jednego „magicznego” identyfikatora. Szukam łańcucha zdarzeń, który pokazuje, co uruchomiło problem, jaki komponent zareagował i czy błąd wystąpił ponownie. Taki sposób pracy jest wolniejszy niż przypadkowe usuwanie ostrzeżeń, ale daje znacznie większą szansę na trwałe rozwiązanie.
Podgląd zdarzeń nie zastąpi monitoringu, zrzutów pamięci ani testów sprzętu, ale pozostaje jednym z pierwszych miejsc, które warto sprawdzić. Gdy połączysz go z filtrowaniem PowerShell, własnym logowaniem w aplikacji .NET i rozsądną retencją danych, otrzymasz praktyczne narzędzie do diagnozowania Windows bez zgadywania.
