Wat Windows 10-logboeken je over systeemfouten kunnen vertellen
Wanneer er iets fout gaat of je hebt de indruk dat Windows, een applicatie of een hardwarecomponent niet helemaal functioneert zoals het hoort, dan is de kans best groot dat Windows zelf je een bruikbare indicatie geeft over de mogelijke oorzaak van het probleem. We duiken in de Windows 10-logboeken!
In dit artikel gaan we uit van wat lastigere probleemscenario’s, waarbij je vooral zelf naar oorzaak en oplossing moet zoeken. In dit geval kan Windows je alsnog nog zinvolle aanwijzingen geven. Het besturingssysteem houdt namelijk uitgebreide logboeken bij en probeert zelfs in de hoogste nood nog snel nuttige informatie bij elkaar te sprokkelen.
Als je de Windows-module Services erbij neemt (services.msc), dan zie je als je naar onderen scrolt, dat Windows Event Log standaard automatisch geactiveerd wordt. Dat houd je maar beter zo, want deze service registreert en archiveert talloze gebeurtenissen die op je systeem plaatsvinden. Je kunt deze logboeken bereiken door bijvoorbeeld met rechts op de startknop te klikken en de optie Logboeken te selecteren, of door Windows-toets+R in te drukken en eventvwr.msc uit te voeren.
Wanneer je vervolgens in het linkerdeelvenster op het submapje Windows-logboeken klikt, krijg je het aantal geregistreerde gebeurtenissen evenals de bestandsgrootte van elk Windows-logboek te zien, waaronder Toepassing, Beveiliging, Setup en Systeem.
Logboekbeheer
Via de optie Eigenschappen in het contextmenu van zo’n item kun je het pad en de maximale logboekgrootte instellen. Je legt hier tevens vast wat er hoort te gebeuren als het plafond is bereikt. Met Logboek wissen verwijder je een logboek, waarbij je wel nog de kans krijgt het eerst te bewaren in een evtx-bestand, dat je dan na een dubbelklik terugvindt in het linkerdeelvenster bij Opgeslagen logboeken.
Of je gebruikt een gratis tool als FullEventLogView om logboeken te bekijken (er is ook een Nederlands taalbestand beschikbaar). Dat doe je dan met Bestand / Gegevensbron kiezen / Gebeurtenissen laden van de externe map met logbestanden, of je gebruikt het opdrachtregelcommando met de nodige parameters (zie de NirSoft-website).
Wil je het logboek bewaren zonder het eerst te wissen, klik dan met rechts op het logboek in het linkerdeelvenster en kies Alle gebeurtenissen opslaan als.
In het eigenschappenvenster vind je ook het tabblad Abonnementen, maar dit is vooral interessant als je bepaalde gebeurtenissen van remote clients via het WS-Management Protocol lokaal wilt opslaan. Aangezien dit vooral voor een domeinnetwerk nuttig is, gaan we hier niet verder op in.
Stel, je ondervindt een of ander probleem met Windows (of een applicatie). Dan is de kans relatief groot dat je daar sporen van terugvindt in de logboeken. Het gaat weliswaar om meerdere logboeken met soms duizenden regels, maar er zijn gelukkig methodes om gerichter te zoeken naar de mogelijke oorzaak.
Heeft het te maken met aanmeldproblemen of met rechtenkwesties, dan kijk je best eerst in het logboek Beveiliging. Het logboek Setup verzamelt gebeurtenissen tijdens het installeren en upgraden van Windows. Voor de logs van sommige applicaties en services kijk je onder Toepassing, maar raadpleeg zeker ook de onderdelen in het submapje Logboeken Toepassingen en Services, aangezien applicaties ook hier een eigen logboek kunnen bijhouden. Voor de meeste systeemgerelateerde problemen raadpleeg je het logboek Systeem.
In het middelste deelvenster sorteer je vervolgens op diverse criteria, door één of twee keer op een kolomtitel te klikken (twee keer om de volgorde om te draaien). Vooral Datum en tijd (voor de momenten waarop het probleem optrad) en Niveau (vooral de types Fout en Kritiek) kunnen interessant zijn.
Er zijn nog andere criteria mogelijk. Klik met rechts op een kolomtitel en kies Kolommen toevoegen/verwijderen om ook andere items te selecteren. Zo kan Proces-id nuttig zijn in combinatie met de informatie die je krijgt in Windows Taakbeheer (druk op Ctrl+Shift+Esc), in de kolom PID (en Opdrachtregel).
Logboeken filteren
Vanuit het contextmenu van een logboek is de zoekfunctie beschikbaar, die niet alleen zoekt binnen de kolominformatie, maar ook in de informatie uit het Details-deelvenster.
Vanuit het deelvenster Acties kun je ook zeer nauwkeurig filteren. Selecteer het beoogde logboek en kies Huidig logboek filteren. Op het tabblad Filter kun je vervolgens filteren op onder meer een tijdsbereik (stel Geregistreerd bijvoorbeeld in op Afgelopen 24 uur), op een of meer gebeurtenisniveaus (zoals Fout en Kritiek) en ook aan de hand van opties als Op logboek of Op bron (bijvoorbeeld .NET Runtime of PowerShell). Selecteer je Op logboek, dan kun je verder inzoomen op onder meer een of meer Gebeurtenis-id’s en Gebruikers.
Denk je deze filtering naderhand nog te gebruiken, kies dan voor Aangepaste weergave maken. Na het instellen van de criteria geef je een naam voor je gefilterde weergave op en duid je aan waar je die wilt bewaren (standaard is dat bij Logboeken / Aangepaste weergaven).
Dat kunnen ook zeer specifieke weergaven zijn. Stel, je wilt snel inzoomen op gebeurtenissen die aangeven dat het opstarten van Windows niet optimaal verloopt. Dan kun je Niveau instellen op Kritiek en Fout, Op logboek zet je op Logboeken Toepassingen en Services / Microsoft / Windows / Diagnostics-Performance / Operational en de logs beperk je tot gebeurtenis-id’s 100-110. Om uit te zoeken welke filters je het best activeert, gebruik je gewoon een zoekmachine op internet.
Foutenanalyse
Er worden dus tig gebeurtenissen vastgelegd door Windows en sommige applicaties, maar wat leveren die eigenlijk op? Dat hangt af van de detailinformatie die je te zien krijgt in het onderste deelvenster wanneer je dubbelklikt op zo’n gebeurtenis. Je kunt deze informatie trouwens ook in zuiver tekstformaat opvragen vanuit het contextmenu van zo’n gebeurtenis: klik op Kopiëren / Details als tekst kopiëren en plak de tekst in een editor.
Soms kun je al uit de beschrijving, in combinatie met de symptomen afleiden wat precies het probleem veroorzaakt. De Microsoft-link Help online op het tabblad Algemeen geeft helaas zelden bruikbare informatie en kun je beter vervangen door een link naar de service van EventID.Net, met de bron en ID als zoekparameters. Druk hiervoor op Windows-toets+R en voer regedit uit.
Navigeer naar HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Event Viewer. Dubbelklik in het rechterpaneel op MicrosoftRedirectionURL en vervang de bestaande url door http://www.eventid.net/display.asp. Hierna merk je dat klikken op Help online meestal veel zinvoller is. De informatie die EventID.Net wordt doorgaans nog interessanter als je er een jaarabonnement van zo’n 43 euro voor over hebt.
Met enig speurwerk via Google (of een andere zoekmachine) kom je natuurlijk ook al een eind. Of bezoek eens de pagina met Windows Security Log Events op Ultimate Windows Security), waar tientallen gebeurtenissen over allerlei beveiligingsissues voorzien van commentaar staan.
Forceer een BSoD
Windows registreert dus tal van gebeurtenissen, maar het kan gebeuren dat die zo ingrijpend zijn dat het systeem daardoor helemaal vastloopt. In dit geval krijg je je meestal een zogenoemde stopfout ofwel bugcontrolefout te zien, gemeenzaam ook BSoD (Blue Screen of Death) genoemd. Je kunt ook nuttige informatie halen uit de geheugendump die je op dat moment kunt laten maken.
Om met deze materie te kunnen experimenteren, is het natuurlijk lastig wachten tot zo’n BSoD zich daadwerkelijk voordoet. Je kunt echter op elk moment zelf (veilig) een stopfout genereren en een bijbehorende geheugendump laten maken. Dat vereist wel een register-ingreep.
Klik met rechts op Register-editor in het startmenu en kies Als administrator uitvoeren. Navigeer naar HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters (voor PS/2-toetsenborden) of naar […]\kbdhid\Parameters (voor usb-toetsenborden). Maak een nieuwe DWORD-waarde (32 bits), geef die de naam CrashOnCtrlScroll en vul 1 in bij Waardegegevens. Na een herstart kun je dan een BSoD genereren door de rechterCtrl-toets ingedrukt te houden, terwijl je twee keer achter elkaar op de ScrollLock-toets drukt.
Over geheugendumps
Tot slot laten we zien wat zo’n geheugendump voor je kan betekenen, maar we vertellen eerst hoe je er zeker van bent dat een geheugendump daadwerkelijk wordt gemaakt als Windows zelf een BSoD genereert.
Dat gaat het makkelijkste vanuit het Configuratiescherm. Open hier Systeem en beveiliging / Systeem / Geavanceerde systeeminstellingen. Op het tabblad Geavanceerd klik je bij Opstart- en herstelinstellingen op Instellingen. Plaats een vinkje bij Een gebeurtenis in het systeemlogboek registreren (zodat tevens een melding in dit logboek wordt opgenomen) en verwijder bij voorkeur het vinkje bij De computer automatisch opnieuw opstarten (zodat je meer tijd krijgt om het BSoD te lezen).
In het uitklapmenu bij Foutopsporingsgegevens registreren selecteer je vervolgens een van de beschikbare dumptypes, waarbij je kennisneemt van de bijbehorende opslaglocatie. In principe kun je volstaan met een Kleine geheugendump: die bevat de stopcode met parameters, de geladen apparaatdrivers, informatie over het huidige proces evenals de kernelstack van de thread die de crash veroorzaakte.
Eventueel kies je voor een Automatische geheugendump of een Kernelgeheugendump (beide bevatten alleen geheugenpagina’s in kernelmodus – niet die in usermodus). Wil je absoluut ook usermodus-processen, die doorgaans niet verantwoordelijk zijn voor BSoD’s, dan kies je Actieve geheugendump of zelfs Volledige geheugendump.
Wanneer je zelf een BSoD genereert zoals we hierboven hebben beschreven, dan lees je bij stopcode Manually_initiated_crash (die overeenkomt met bugcontrolecode 0xE2).
In zo’n BSoD krijg je tevens het webadres www.windows.com/stopcode te zien. Dat is een eenvoudige helppagina met Nederlandstalige instructies om de oorzaak van het BSoD te vinden. Je geeft antwoord op de vraag wanneer het probleem zich heeft voorgedaan: Na de installatie van een update of Tijdens het gebruik van mijn apparaat.
In het eerste geval raadt Microsoft je aan je pc in veilige modus op te starten en recente updates te verwijderen. In het tweede geval doet Microsoft het voorstel om, na een herstart in veilige modus, eerst recent geïnstalleerde software van derden te verwijderen; vervolgens stuurprogramma’s terug te draaien, uit te schakelen of desnoods te verwijderen; of het te proberen door nieuw aangesloten hardware weg te halen. Het is opvallend hoe al deze instructies mooi aansluiten bij Microsofts stelling dat 70% van de BSoD’s te wijten is aan drivers van derde partijen.
Specifieke oplossingen
Met de juiste tools kun je het probleem ook meteen zo gericht mogelijk troubleshooten. In eerste instantie kun je googelen naar de hexadecimale bugcontrolecode (0x, gevolgd door acht andere tekens) en de beschrijving die in het BSoD zelf te vinden is. Via deze link vind je bijvoorbeeld links naar probleemoplossende instructies voor bijna twintig verschillende bugcontrolecodes.
Je kunt ook gebruikmaken van de gratis, portable tool BlueScreenView (er is een Nederlandstalig taalbestand beschikbaar). De tool haalt automatisch de geheugendumps op uit de standaardlocatie %systemroot%\minidump die je vervolgens op basis van Crashtijd kunt selecteren, maar via Opties / Geavanceerde opties / Eén MiniDump-bestand laden kun je ook naar een specifieke geheugendump verwijzen.
In het bovenste venster lees je onder meer de crashtijd af, het stuurprogramma met bestandsbeschrijving dat vermoedelijk de crash veroorzaakte, evenals het stackadres. In het onderste venster krijg je een vollediger overzicht van de drivers die toen waren geladen, en de drivers die vermoedelijk aan de crash gelinkt zijn heeft BlueScreenView met rood gemarkeerd.
Een vergelijkbare tool is WhoCrashed (ook beschikbaar in een gratis versie). Het volstaat de Analyze-knop in te drukken of bij Options / Directories eerst zelf aan te geven in welke map de tool naar dumpbestanden moet zoeken. Je kunt hier trouwens via Tools / Crash Dump Test op elk moment ook een BSoD als test forceren.
Dieper graven
Tools als BlueScreenView en WhoCrashed zullen meestal volstaan. Bij sommige bugcontrolecodes (zoals die met 0xa) wijzen die tools echter al snel Ntoskrnl.exe als potentiële dader aan. Dat komt doordat Windows zelf de verantwoordelijke driver niet kan duiden en aangezien de crash in kernelmodus optrad, verwijzen de tools gemakshalve dan maar naar de kernelmodule Ntoskrnl.exe. Tenzij Windows zwaar aangetast is, is de kans echter klein dat je het euvel hier daadwerkelijk moet zoeken.
Voor een meer betrouwbare analyse heb je een grondigere debugtool als Windbg nodig, eventueel in combinatie met een automatische of kernel-geheugendump. In het kort ga je hier als volgt mee aan de slag.
Download het installatieprogramma (dus niet het iso-bestand) van Windows 10 SDK. Plaats alleen een vinkje bij Debugging Tools for Windows. Na de installatie klik je in het startmenu met rechts op Start WinDbg (x..) en kies je Als administrator uitvoeren. Ga naar File / Open Crash Dump en verwijs naar het gewenste dumpbestand. Even later klik je in het Command-venster op de link !analyze -v.
De kans is groot dat een foutmelding verschijnt in verband met symbolen. Open in dat geval File / Symbol File Path en vul srv*c:\symbols*https://msdl.microsoft.com/download/symbols in. Als het goed is, verschijnt wat later de Bugcheck Analysis met onder meer de STACK_TEXT en andere informatie. Deze gegevens zijn vooral geschikt voor de gevorderde gebruiker.