Nedbrudsdumps og fejlrapporter (WER)

Forside › Windows-forensik · Gennemgået oktober 2026 · Af John Nielsen

Når et program eller hele Windows går ned, kan der blive skrevet en fejlrapport og eventuelt en hukommelsesdump. Fejlrapporterne fra Windows Error Reporting (WER) viser, hvilket program der kørte, fra hvilken sti, og hvornår det fejlede. Dumpene kan indeholde dele af programmets hukommelse på nedbrudstidspunktet. Kilden er niche, men den kan bekræfte programkørsel og tid i sager, hvor andre spor er ryddet eller aldrig blev logget. Artiklen er skrevet til SOC-analytikere og sagkyndige.

Dvalefil, sidefil og den generelle sammenhæng mellem hukommelse og disk er beskrevet i hiberfil, pagefile og swap. Her er fokus på WER og de dumps, der knytter sig til nedbrud.

Tre slags kilder

WER-rapporter. Ved et programnedbrud danner WER en rapportmappe med en tekstfil, typisk Report.wer, og eventuelle bilag. Rapporterne ligger i C:\ProgramData\Microsoft\Windows\WER under ReportQueue (ikke sendt) og ReportArchive (behandlet), og der kan være tilsvarende mapper i brugerens profil under AppData\Local\Microsoft\Windows\WER. Arkivet kan ifølge Microsoft som standard rumme op til 1.000 rapporter (MaxArchiveCount), men indstillingerne kan ændres via gruppepolitik.

Lokale brugertilstandsdumps. WER kan konfigureres til at gemme fulde eller mindre dumps af et program, der går ned. Funktionen er ifølge Microsoft ikke slået til som standard og styres af nøglen HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps. Standardmappen er %LOCALAPPDATA%\CrashDumps, og der gemmes som standard højst 10 dumps, før de ældste overskrives. Udviklere og IT-afdelinger slår det ofte til ved fejlsøgning og glemmer at slå det fra igen.

Systemnedbrud (bugcheck). Ved en blå skærm skriver Windows efter indstillingerne under HKLM\SYSTEM\CurrentControlSet\Control\CrashControl en dump til %SystemRoot%\Memory.dmp, som overskrives ved næste nedbrud, og eventuelt små dumps til %SystemRoot%\Minidump, hvor hver fil bevares med datoen i filnavnet. Derudover kan Windows danne såkaldte live kernel reports i %SystemRoot%\LiveKernelReports uden at systemet går ned.

Hændelseslogs

Nedbrud efterlader også spor i hændelsesloggen. I Application-loggen registreres programnedbrud typisk som hændelse 1000 fra kilden Application Error, med programnavn, version, modul og fejlkode, og WER’s behandling som hændelse 1001 fra Windows Error Reporting. Et systemnedbrud registreres efter genstart i System-loggen, bl.a. som hændelse 1001 fra kilden BugCheck. Hændelseslogs har deres egen opbevaring og overskrivning; se Windows-hændelseslogs.

Hvad en fejlrapport kan vise

En WER-rapport indeholder typisk:

• Programmets navn og fulde sti, også hvis det kørte fra en USB-nøgle, en midlertidig mappe eller en netværksdeling.
• Programmets version og eventuelt det modul, der fejlede.
• Tidspunkt for hændelsen, ofte som FILETIME i rapportfilen; se tidsstempelformater.
• Fejlkode og undtagelsestype.
• En liste over indlæste moduler, som kan afsløre plugins eller injicerede biblioteker.

Det gør rapporten til et supplement til Prefetch, Amcache og Shimcache. Et program, der er slettet, og hvis Prefetch-fil er ryddet, kan stadig optræde i en WER-rapport, hvis det på et tidspunkt gik ned.

Hvad en dump kan vise

En dump er et øjebliksbillede af hukommelse. Afhængigt af typen kan den indeholde:

• Kommandolinje og miljøvariabler for processen.
• Åbne filer, netværksforbindelser og indlæste moduler.
• Dele af dokumenter, beskeder eller webindhold, som programmet havde i hukommelsen.
• I nogle tilfælde adgangsoplysninger, sessionstokens eller nøgler.

En fuld dump af et program kan derfor rumme følsomme data. Den skal behandles som en beviskopi med tilsvarende adgangskontrol, og analysen skal afgrænses til det, opdraget handler om. Hvordan hukommelse analyseres, er beskrevet i memory forensics.

Sikring

WER-mapper og dumps er almindelige filer og kommer med i et fuldt forensisk image. Ved målrettet indsamling skal følgende med:

1. C:\ProgramData\Microsoft\Windows\WER med undermapper.
2. Brugerprofilernes AppData\Local\Microsoft\Windows\WER og AppData\Local\CrashDumps.
3. %SystemRoot%\Memory.dmp, %SystemRoot%\Minidump og %SystemRoot%\LiveKernelReports.
4. Eventuelle alternative dumpmapper angivet i LocalDumps.
5. Registreringsnøglerne for WER og CrashControl, så det kan dokumenteres, hvordan maskinen var sat op.
6. Application- og System-loggen som EVTX.

Store dumps kan fylde flere gigabyte. Kopiér dem uændrede, og beregn hashværdi ved sikringen. Analyse sker på en arbejdskopi.

Hvor kilden typisk er værdifuld

WER og dumps er sjældent det første sted, man leder, men nogle situationer gør dem relevante:

• Udvikler- og testmaskiner. Her er lokale dumps ofte slået til, og programmer går hyppigere ned. Dumps kan indeholde kildekode, konfiguration eller data, der ikke længere findes på disken.
• Servere med fagsystemer. Gentagne nedbrud i et fagsystem kan være en del af selve tvisten, fx om stabilitet eller fejl i en leverance. Rapporterne giver en uafhængig liste over, hvornår og hvordan systemet fejlede.
• Mistanke om ondsindede programmer. Skadelig kode er ofte ustabil og får værtsprocesser til at gå ned. Modullisten i en rapport kan vise et fremmed bibliotek, før det blev fjernet.
• Ryddede maskiner. Oprydningsprogrammer sletter ofte browserdata og Prefetch, men overser WER-arkivet.

Analyse

Rapportfilerne er tekst og kan læses direkte. Dumps analyseres med en debugger eller et værktøj til hukommelsesanalyse, og det skal dokumenteres, hvilke symbolfiler der er brugt, da de påvirker, hvad værktøjet kan vise. Søgning efter tekststrenge i en dump er hurtig, men uden kontekst siger et fund kun, at strengen var i hukommelsen, ikke hvorfor.

Fejlkilder i fortolkningen

• Nedbrudstid er ikke starttid. Rapporten viser, hvornår programmet fejlede, ikke hvornår det blev startet eller hvor længe det kørte.
• Nedbrud er ikke brug. Et program kan gå ned ved opstart, ved en automatisk opdatering eller fordi en anden proces påvirkede det, uden at en bruger aktivt brugte det.
• Rapporter kan være slettet eller sendt. Diskoprydning og politikker kan tømme arkivet. Fravær af rapporter siger intet om, at et program ikke har kørt.
• Forkert konto. En rapport i ProgramData siger ikke i sig selv, hvilken bruger der kørte programmet. Kobl til brugerprofilens WER-mappe, procesrevision eller logon; se event 4688.
• Overskrevne dumps. Memory.dmp og lokale dumps ud over grænsen overskrives. Den dump, der findes, er den seneste, ikke nødvendigvis den relevante.

Hvad kilden kan og ikke kan bevise

WER-rapporter kan bekræfte, at et bestemt program med en bestemt sti fandtes og blev forsøgt kørt på et bestemt tidspunkt. Dumps kan vise, hvad et program havde i hukommelsen, da det gik ned. Ingen af delene viser alene, hvem der startede programmet, eller hvad det gjorde før nedbruddet. Kilden er stærkest som en brik i en tidslinje sammen med andre artefakter.

I rapporten bør det fremgå, hvilke WER-mapper og dumps der blev fundet, hvor mange rapporter arkivet indeholdt, hvilke indstillinger maskinen havde for arkiv og lokale dumps, og om der er tegn på, at arkivet er tømt. Uden de oplysninger kan læseren ikke vurdere, om fraværet af en bestemt rapport betyder noget. Citér de relevante felter fra rapportfilen ordret, med tidsstemplet omregnet til UTC og den oprindelige værdi angivet.

Kilder og versioner

• Microsoft Learn: Collecting User-Mode Dumps
• Microsoft Learn: WER Settings
• Microsoft Learn: Memory dump file options

Senest gennemgået: oktober 2026.

Næste skridt

• Windows-artefakter: LNK, jump lists, shellbags og USB-spor
• Event 4624 og 4625: logontyper og fortolkning
• Eksport af Windows-hændelseslogs (EVTX) til en sag

Del af: Windows-forensik

Læs også: Event 4688: proceskørsel og kommandolinje i Windows-loggen · WSL og lokale virtuelle maskiner

→ Forensisk undersøgelse af en computer · For IT-sikkerhed og SOC · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT