Informacje o wyłączeniu systemu w dzienniku zdarzeń: kto, kiedy i dlaczego?
Jeśli pamiętacie mój artykuł o uptime (czas pracy systemu od uruchomienia do danej chwili), to na pewno zgodzicie się, że administrator od czasu do czasu chce również wiedzieć, ile razy dana maszyna była wyłączana, dlaczego i KTO ośmielił się to zrobić:). Takowe informacje skrywa w sobie Dziennik Zdarzeń i dzisiaj podpowiem jak je łatwo wyciągnąć i zinterpretować.
Daty i godziny wpisów, to mniej więcej czas wyłączenia /restartu systemu, a ilość tych wpisów to ilość owych wyłączeń i restartów. Jak widać stacja robocza może mieć ich sporo, a serwer nie powinien.
Szybkie czytanie logów na wielu zdalnych maszynach
Odsyłam do wcześniejszej porady, w której opisałem narzędzie EvencombMT.exe. Przeczesanie wielu maszyn na raz zaowocuje zrzuceniem szukanych informacji do pliku nazwa_komputera-System_LOG.txt. Ze wspomnianego wpisu dowiecie się jak odfiltrować konkretne numery eventów i jak zmienić na przykład ramy czasowe ich występowania.
„Zimne” restarty
Słusznie zgadujecie, że opisana wyżej metoda nie wykryje nagłych restartów na przykład spowodownych brakiem zasilania. Warto jednak wiedzieć, że
W idealnym świecie zatem ilość wpisów 6005 będzie zawsze o jeden mniejsza niż 6006.
Kto restartował maszynę?
Powód może być wpisany ręcznie dzięki narzędziu „Shutdown Event Tracker”. Może też być podany jako parametr w narzędziach typu shutdown.exe i psshutdown.exe. Często jest wpisywany automatycznie przez system, jeśli jest to na przykład restart po poprawkach bezpieczeństwa.
Oto kilka przykładów. Użytkownik wymusza restart wybierając z listy powód „Operating System: Reconfiguration (Planned)” i swój komentarz „zmiany w bazie”:
Event Source: USER32
Event Category: None
Event ID: 1074
Date: 3/22/2010
Time: 11:11:20 AM
User: domena\użytkownik123
Computer:
Description:
The process Explorer.EXE has initiated the shutdown of computer
of user domena\użytkownik123 for the following reason: Operating System:
Reconfiguration (Planned)
Reason Code: 0x84020004
Shutdown Type: restart
Comment: zmiany w bazie
W tym przykładzie system restartuje się sam po instalacji poprawek bezpieczeństwa. Aby to dokładniej potwierdzić, należałoby to wydarzenie porównać z logiem poprawek (windowsupdate.log) lub innymi wpisami w Dzienniku Zdarzeń (frazy: „wuauclt”, „Windows Update”):
Source: USER32
Date: 10/02/2013 3:11:21 AM
Event ID: 1074
Task Category: None
Level: Information
Keywords: Classic
User: SYSTEM
Computer:
Description:
The process C:\Windows\system32\svchost.exe (server name) has initiated the restart of computer
Reason Code: 0x80020002
Shutdown Type: restart
Tutaj lokalny administartor wyłącza maszynę:
Source: USER32
Date: 7/12/2013 11:00:16 PM
Event ID: 1074
Task Category: None
Level: Information
Keywords: Classic
User:
Computer:
Description:
The process C:\Windows\system32\winlogon.exe
Reason Code: 0x500ff
Shutdown Type: power off
I znowu potwierdza się plotka, że admin wie i widzi wszystko 🙂 Jeśli uważacie, że coś warto dodać lub któreś z poruszonych zagadnień warto omówić dokładniej – piszcie:)
W treści jest cytuję: „W idealnym świecie zatem ilość wpisów 6005 będzie zawsze o jeden mniejsza niż 6006.” Oczywiście będzie odwrotnie. Jeśli system nieoczekiwanie pada to wpisów 6005 będzie więcej niż 6006.
Ale w świecie idealnym nie ma nieoczekiwanych wyłączeń bo to uszkadza pc, a w idealnym świecie nic nie jest uszkodzone, proszę myśleć
Dziękuje
W idealnym świecie zdarzeń 6006 (z2) jest tyle samo, co 6005 (z1). Stanem początkowym maszyny jest jej nieaktywność, więc i taki będzie jej też stan ostateczny. W stanie przejściowym – maszyna jest uruchomiona – ilość zdarzeń zawsze będzie wyrażona stosunkiem z1 > z2, ponieważ jej wejście w stan uruchomienia nie może pojawić się tak samo nagle, jak zanik napięcia (jeśli). Oznacza to, że z1 zawsze zostanie zarejestrowane, a z2 niekoniecznie (w idealnym zawsze).
Witam, poniżej skopiowane dane z dziennika zdarzeń systemu:
Informacje 2017-05-09 14:40:46 Kernel-Processor-Power 26 (4)
Krytyczne 2017-05-09 14:40:45 Kernel-Power 41 (63)
Informacje 2017-05-09 14:40:38 FilterManager 6 Brak
Informacje 2017-05-09 14:40:38 FilterManager 6 Brak
Informacje 2017-05-09 14:40:55 EventLog 6013 Brak
Informacje 2017-05-09 14:40:55 EventLog 6005 Brak
Informacje 2017-05-09 14:40:55 EventLog 6009 Brak
Błędy 2017-05-09 14:40:55 EventLog 6008 Brak
Informacje 2017-05-09 14:40:35 Kernel-General 12 Brak
Informacje 2017-05-09 14:38:22 Service Control Manager 7036 Brak
Informacje 2017-05-09 14:34:12 Service Control Manager 7036 Brak
Pracownik zgłosił nieoczekiwane zamknięcie systemu, komputer jest pod UPS-em i tutaj można wykluczyć nagły brak zasilania. Dziwi mnie jedna nieścisłość, godziny zdarzeń 6013. 6005, 6009 odnotowane zostały z godzinami ( dokładnie sekundy ) późniejszymi niż rzeczywiste. Jaka może być przyczyna takiego stanu rzeczy ? Pozdrawiam