Get-EventLog -LogName Application – log aplikacji

Get-EventLog -LogName Application zwraca zdarzenia z dziennika aplikacji — starsze polecenie, stopniowo zastępowane przez bardziej wydajne Get-WinEvent.

Czym jest polecenie Get-EventLog -LogName Application

Get-EventLog -LogName Application to polecenie dostępne w klasycznym Windows PowerShell, służące do odczytywania wpisów zapisanych w dzienniku zdarzeń Application. Ten dziennik gromadzi komunikaty tworzone przez programy działające w systemie Windows, a także przez niektóre składniki systemowe związane z uruchamianiem, wykonywaniem i zamykaniem aplikacji. W zależności od rodzaju zdarzenia można znaleźć w nim informacje diagnostyczne, ostrzeżenia oraz błędy.

Po uruchomieniu polecenia zwracana jest lista obiektów reprezentujących zdarzenia. Typowy wpis może zawierać między innymi identyfikator zdarzenia, poziom ważności, źródło komunikatu, datę i godzinę wystąpienia, nazwę komputera oraz opis zapisany w polu wiadomości. Dzięki temu możliwe jest prześledzenie, co działo się w systemie w chwili awarii programu, nieoczekiwanego zamknięcia aplikacji albo problemu z instalacją aktualizacji.

Warto pamiętać, że jest to starszy sposób pracy z dziennikiem zdarzeń. Polecenie pozostaje przydatne podczas prostych czynności serwisowych i w starszych skryptach, jednak w nowszych zadaniach administracyjnych częściej stosuje się Get-WinEvent. Nowocześniejsze polecenie lepiej obsługuje różne typy dzienników oraz udostępnia wygodniejsze mechanizmy filtrowania dużej liczby wpisów.

Kontekst techniczny i porównanie z Get-WinEvent - Get-EventLog -LogName Application – log aplikacji

Najprostsze użycie polecenia ogranicza się do wskazania nazwy dziennika:

Get-EventLog -LogName Application

Wynik może obejmować wiele zdarzeń, dlatego przy praktycznej analizie często zawęża się go do określonej liczby najnowszych wpisów. Pomocne jest również sortowanie według czasu, odczytanie pełnego opisu zdarzenia albo wyszukanie wpisów należących do konkretnego źródła. Przykładowo:

Get-EventLog -LogName Application -Newest 20

Parametr -Newest pozwala pobrać określoną liczbę najświeższych zdarzeń, co ogranicza ilość danych wyświetlanych w konsoli. Do dalszego filtrowania można wykorzystać polecenia potokowe PowerShell, na przykład Where-Object, aby wybrać wpisy o określonym poziomie, źródle lub zakresie czasu.

W porównaniu z Get-EventLog polecenie Get-WinEvent jest przeznaczone do bardziej uniwersalnej obsługi dzienników zdarzeń. Umożliwia pracę z dziennikami aplikacji, systemu i zabezpieczeń, a także z innymi kanałami udostępnianymi przez system Windows. W rozbudowanych zapytaniach może korzystać z filtrów opartych na właściwościach zdarzeń, co zmniejsza ilość danych przekazywanych do dalszej obróbki. Ma to znaczenie przy dużych dziennikach, w których ręczne przeglądanie wszystkich pozycji byłoby czasochłonne.

Różnica dotyczy również zgodności z typami dzienników. Get-EventLog korzysta ze starszego mechanizmu i nie obsługuje wszystkich nowoczesnych kanałów zdarzeń. Jeżeli polecenie nie zwraca oczekiwanych danych albo pojawia się komunikat o braku dziennika, zasadne jest sprawdzenie tej samej lokalizacji za pomocą Get-WinEvent oraz upewnienie się, że użyto prawidłowej nazwy logu.

Typowe problemy i błędy podczas odczytu logu

Jednym z częstszych problemów jest wpisanie nieprawidłowej nazwy dziennika. Nazwa wyświetlana w narzędziu Podgląd zdarzeń może być mylona z nazwą kanału używaną przez PowerShell. Dla klasycznego dziennika aplikacji poprawna nazwa to zazwyczaj Application, ale w przypadku innych kanałów należy sprawdzić ich rzeczywiste oznaczenie.

Drugą trudnością bywa zbyt duża liczba zwróconych rekordów. Jeżeli dziennik był używany przez długi czas, polecenie może wyświetlić obszerny wynik, a właściwe zdarzenie zostanie przeoczone. W takiej sytuacji warto ograniczyć wynik parametrem -Newest, sortować wpisy według daty albo filtrować je na podstawie źródła i identyfikatora zdarzenia.

Sam wpis w dzienniku nie zawsze wskazuje bezpośrednią przyczynę awarii. Zarejestrowany błąd może być skutkiem wcześniejszego problemu, na przykład nieudanego odczytu pliku, przerwanego procesu, błędnej konfiguracji, niedostępnej biblioteki albo konfliktu między składnikami programu. Dlatego analizuje się nie tylko pojedynczy rekord, lecz także zdarzenia występujące kilka minut przed nim i po nim.

Warto zwrócić uwagę na pola Source, EventID, EntryType, TimeGenerated oraz Message. Źródło wskazuje komponent, który zapisał wpis, identyfikator pozwala porównywać zdarzenia tego samego rodzaju, a czas wystąpienia pomaga zestawić log z momentem pojawienia się problemu. Pole wiadomości często zawiera opis czytelny dla człowieka, ale jego treść może zależeć od dostępnych plików opisów i od wersji używanego programu.

Niektóre wpisy mogą wymagać uruchomienia PowerShell z odpowiednimi uprawnieniami. Brak uprawnień, uszkodzony dziennik, ograniczenia zasad systemowych albo wyłączone usługi rejestrowania zdarzeń mogą skutkować błędem odczytu lub niepełnym wynikiem. Należy też odróżnić brak nowych wpisów od sytuacji, w której dziennik nie jest dostępny. Są to dwa różne przypadki i wymagają odmiennych czynności diagnostycznych.

W jakich sytuacjach warto oddać urządzenie do diagnozy - Get-EventLog -LogName Application – log aplikacji

Samodzielne sprawdzenie dziennika aplikacji jest przydatne, gdy problem występuje sporadycznie i można dokładnie zapisać godzinę jego pojawienia się. Jeżeli jednak program zamyka się bez komunikatu, system regularnie zgłasza błędy, aktualizacje kończą się niepowodzeniem albo wpisy w logu są niezrozumiałe, potrzebna może być szersza analiza komputera. Pojedynczy identyfikator zdarzenia rzadko wystarcza do postawienia pewnej diagnozy.

Do serwisu warto zgłosić się również wtedy, gdy błędy dotyczą kilku aplikacji jednocześnie, pojawiają się po zmianie sterowników lub aktualizacji systemu, a także gdy komputer działa niestabilnie mimo ponownego uruchomienia. W takich przypadkach sprawdza się nie tylko dzienniki, lecz także zależności między aplikacjami, stan plików systemowych, konfigurację uruchamiania oraz objawy występujące poza samym logiem.

Przydatne jest przekazanie informacji o nazwie programu, dokładnej godzinie awarii, sposobie jej wywołania i zmianach wykonanych tuż przed wystąpieniem problemu. Można również przygotować treść kilku powiązanych wpisów z dziennika, bez usuwania ich kontekstu czasowego. Tak zebrane dane ułatwiają odróżnienie błędu samej aplikacji od problemu dotyczącego systemu Windows lub konfiguracji urządzenia.

W Warszawskim Pogotowiu Komputerowym 24/7 można zlecić sprawdzenie takich objawów, gdy analiza dziennika nie prowadzi do jednoznacznych wniosków. Pozwala to połączyć informacje z Application z rzeczywistym zachowaniem komputera i ustalić, czy źródła problemu należy szukać w konkretnym programie, systemie operacyjnym, konfiguracji lub podzespołach.