[File] [PATCH] Magdir/windows MS Windows crash dump- wrong details + extension
Jörg Jenderek
joerg.jen.der.ek at gmx.net
Sat May 13 16:43:19 UTC 2023
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
Some weeks ago i send patch for X-Window screen dump image. Sometimes
the file name suffix dmp is used. For control reason i looked for
other file formats with that suffix. That suffix is also used for
Microsoft Windows crash dumps.
When running file command version 5.44 and newer on such DMP samples
i get an at first glance not bad looking output like:
043022-18703-01.dmp: MS Windows 64bit crash dump
, 8341923 pages
050322-24890-01.dmp: MS Windows 64bit crash dump
, 3142425 pages
MEMORY-full.DMP: MS Windows 64bit crash dump
, 4992030524978970960 pages
MEMORY.DMP: MS Windows 64bit crash dump
, 4992030524978970960 pages
Mini111013-01.dmp: MS Windows 32bit crash dump
, PAE
, 1162297680 pages
With option -i only generic application/octet-stream and with
option --extension only ??? is displayed.
For comparison reason i run the file format identification utility
TrID ( See https://mark0.net/soft-trid-e.html). The 64-bit samples
are described with highest priority as "Windows 64bit Memory Dump" by
dmp-64.trid.xml. The 32-bit samples are described with highest
priority as "Windows memory dump" by dmp.trid.xml (See appended
trid-v-dmp.txt.gz).
For comparison reason i also run the file format identification
utility DROID ( See https://sourceforge.net/projects/droid/).
Here my examples are not recognized.
The mentioned web site does not exist any more. So i changed it to an
archived variant. In the end i found and used win_dump_defs.h
C-header file of qemu. That is expressed inside Magdir/windows by
comment lines like:
# https://web.archive.org/web/20101125060849/
# https://computer.forensikblog.de/
# en/2008/02/64bit_magic.html
# Reference: http://mark0.net/download/triddefs_xml.7z
# defs/d/dmp.trid.xml
# https://gitlab.com/qemu-project/qemu/-/blob/master/
# include/qemu/win_dump_defs.h
In current Magdir/windows the description starts by lines like:
0 string PAGE
>4 string DUMP MS Windows 32bit crash dump
>>0x05c byte 0 \b, no PAE
>>0x05c byte 1 \b, PAE
>>0xf88 lelong 1 \b, full dump
>>0xf88 lelong 2 \b, kernel dump
>>0xf88 lelong 3 \b, small dump
>>0x068 lelong x \b, %d pages
>4 string DU64 MS Windows 64bit crash dump
>>0xf98 lelong 1 \b, full dump
The first test looks for string PAGE (called char Signature[4] in
header file). Then the second test afterwards look for string DUMP or
DU64 for 64-bit variant (called char ValidDump[4] in header file).
For the 64 bit variant the dump type should be printed by following
lines like:
>>0xf98 lelong 1 \b, full dump
>>0xf98 lelong 2 \b, kernel dump
>>0xf98 lelong 3 \b, small dump
But these lines are false! That is not visible at first glance. In
the advanced system settings GUI on Windows, i changed the conditions
but i get no output here. So first i replaced/added a line like:
>>0xf98 ulelong x \b, DumpType %#x
Then i get on Windows 8/10/11 3 different values:
value german english
4 Kleines Speicherabbild (256 KB) small
5 vollständiges Speicherabbild full
6 Kernelspeicherabbild kernel
Then i count variables and length according to c-header file.
According to that at offset 3992 (=0xf98) the variable uint32_t
DumpType is stored. So far as i can see that must be expressed by
lines like:
>>0xf98 ulelong x \b,
>>>0xf98 lelong 5 full dump
>>>0xf98 lelong 6 kernel dump
>>>0xf98 lelong 4 small dump
>>>0xf98 default x DumpType
>>>>0xf98 ulelong x (%#x)
Just in case that more than 3 observed cases occur print DumpType
with hexadecimal value. I tried to understand why the dump types are
reported wrong. On server learn.microsoft.com i found a page with
Overview of memory dump file options for Windows. There the current
used values are listed. But these values are used for variable
CrashDumpEnabled inside Windows registry. There is not written that
these values are stored inside crash dumps itself. So i add the other
fields of header. Some maybe are not so interesting to i add such
fields as comment lines. After verifying by mentioned tools i show
some interesting facts. The version (with major and minor version)
is shown by lines like:
>>8 ulelong x \b, version %u
>>12 ulelong x \b.%u
So for major version i get value like 15 and for minor version i get
values like 9600 19041 22621. This depends on or described the used
windows system.
The number of processors is shown by variable NumberProcessors via
line like:
>>52 ulelong x \b, %u processors
So here i get values like 2 or 4.
For 64-bit branch the MachineImageType variable value is always 8664
hexadecimal. So this just an additional hint for correct
interpretation of fields by line like:
>>48 ulelong !0x8664 \b, MachineImageType %#x
I tried to verify the variables and values by NirSoft and tool of
Windows Kit by lines like:
Dumpchk.exe 043022-18703-01.dmp
BlueScreenView.exe 043022-18703-01.dmp
Unfortunately the last items are there not shown, but other facts are
shown.
The last line was
>> 0x090 lequad x \b, %lld pages
Here i get values like:
3142425 8341923 8366500 1162297680 4992030524978970960
Some values are too high in my opinion. So i do not know if this is
true, but according to header source at offset 144 (=0x090) this is
also stored as uint64_t NumberOfPages inside WinDumpPhyMemDesc64.
Maybe an windows expert can check it this right or false. So i just
keep it.
Then do the same steps for 32 bit branch. Here i get 14c (for intel
x86) and the processor type is done like above but at other offset.
This is done by lines like:
>>32 ulelong !0x14c \b, MachineImageType %#x
>>36 ulelong x \b, %u processors
Unfortunately for 32 bit the situation is more unclear. According
to header file i get value 45474101 for uint32_t reserved0. This is
interpreted by lines like:
>>0x05c byte 0 \b, no PAE
>>0x05c byte 1 \b, PAE
So i do not know if this is true. Maybe an expert can check this.
The dump type is interpreted similar to 64 bit branch, but at other
offset. This is done by lines like:
>>0xf88 lelong 1 \b, full dump
>>0xf88 lelong 2 \b, kernel dump
>>0xf88 lelong 3 \b, small dump
But according to qemu source at offset 3976 (=0xf88) this is part
of uint8_t reserved1[3200] in dump header. But for the one of my
observed sample i also got value 4 here. So i add afterwards one
more line like:
>>0xf88 lelong >3 \b, dump type (%#x)
The last line in 32 bit branch was
>>0x068 lelong x \b, %d pages
Here i get again high value like: 1162297680
This value is too high in my opinion. So i do not know if this is
true, but according to header source at offset 104 (=0x068) this is
also stored as uint32_t NumberOfPages inside WinDumpPhyMemDesc32.
Maybe an windows expert can check it this right or false. So i just
keep this.
Instead of generic application/octet-stream i choose an user
defined one. The dump examples are stored as c:\Windows\MEMORY.DMP
or something like c:\Windows\Minidump\020322-18890-01.dmp or
043022-18703-01.dmp. So these facts are now expressed by additional
lines like>
!:mime application/x-ms-dmp
!:ext dmp
After applying the above mentioned modifications by patch
file-5.44-windows-dmp.diff then my dump samples are now described
with more correct details. This now then looks like:
043022-18703-01.dmp: MS Windows 64bit crash dump
, version 15.9600, 4 processors
, small dump
, 8341923 pages
050322-24890-01.dmp: MS Windows 64bit crash dump
, version 15.19041, 2 processors
, small dump
, 3142425 pages
MEMORY-full.DMP: MS Windows 64bit crash dump
, version 15.22621, 2 processors
, full dump
, 4992030524978970960 pages
MEMORY.DMP: MS Windows 64bit crash dump
, version 15.22621, 2 processors
, kernel dump
, 4992030524978970960 pages
Mini111013-01.dmp: MS Windows 32bit crash dump
, version 15.2600, 2 processors, PAE
, dump type (0x4)
, 1162297680 pages
With best wishes,
Jörg Jenderek
- --
Jörg Jenderek
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iF0EARECAB0WIQS5/qNWKD4ASGOJGL+v8rHJQhrU1gUCZF++JwAKCRCv8rHJQhrU
1lOEAJ0ehPh5/2rLVz7MzMRblUddUwo5FgCfbBd3jI0HPmNqD8aXe+la4ncjJss=
=UZe4
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trid-v-dmp.txt.gz
Type: application/x-gzip
Size: 634 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20230513/b6914e66/attachment.bin>
-------------- next part --------------
--- file-5.44/magic/Magdir/windows.old 2022-12-02 17:18:19.000000000 +0100
+++ file-5.44/magic/Magdir/windows 2023-05-13 18:34:51.571690000 +0200
@@ -95,25 +95,157 @@
>>40 lestring16 x "%s"
# Summary: Windows crash dump
-# Extension: .dmp
# Created by: Andreas Schuster (https://computer.forensikblog.de/)
-# Reference (1): https://computer.forensikblog.de/en/2008/02/64bit_magic.html
+# https://web.archive.org/web/20101125060849/https://computer.forensikblog.de/en/2008/02/64bit_magic.html
# Modified by (1): Abel Cheung (Avoid match with first 4 bytes only)
+# Modified by (2): Joerg Jenderek (addtional fields, extension, URL)
+# Reference: http://mark0.net/download/triddefs_xml.7z/defs/d/dmp.trid.xml
+# https://gitlab.com/qemu-project/qemu/-/blob/master/include/qemu/win_dump_defs.h
+# Note: called "Windows memory dump" by TrID
+# and verified by like Windows Kit `Dumpchk.exe 043022-18703-01.dmp`
+# and partly by NirSoft `BlueScreenView.exe 043022-18703-01.dmp`
+# char Signature[4]
0 string PAGE
+# char ValidDump[4]
>4 string DUMP MS Windows 32bit crash dump
+#!:mime application/octet-stream
+!:mime application/x-ms-dmp
+# like: Mini111013-01.dmp
+!:ext dmp
+# major version like: 15
+>>8 ulelong x \b, version %u
+# minor version like: 2600
+>>12 ulelong x \b.%u
+# DirectoryTableBase like: 709000
+#>>16 ulelong x \b, DirectoryTableBase %#x
+# PfnDatabase like: 805620c8
+#>>20 ulelong x \b, PfnDatabase %#x
+# PsLoadedModuleList like: 8055d720
+#>>24 ulelong x \b, PsLoadedModuleList %#x
+# PsActiveProcessHead like:805638b8
+#>>28 ulelong x \b, PsActiveProcessHead %#x
+# MachineImageType like: 14c (intel x86)
+>>32 ulelong !0x14c \b, MachineImageType %#x
+# NumberProcessors like: 2
+>>36 ulelong x \b, %u processors
+# BugcheckCode like: e2
+#>>40 ulelong x \b, BugcheckCode %#x
+# BugcheckParameter1 like: 0
+#>>44 ulelong x \b, BugcheckParameter1 %#x
+# BugcheckParameter2 like: 0
+#>>48 ulelong x \b, BugcheckParameter2 %#x
+# BugcheckParameter3 like: 0
+#>>52 ulelong x \b, BugcheckParameter3 %#x
+# BugcheckParameter4 like: 0
+#>>56 ulelong x \b, BugcheckParameter4 %#x
+# VersionUser[32]; like "PAGEPAGEPAGEPAGEPAGEPAGEPAGEPAGE" ""
+#>>60 string x \b, VersionUser "%.32s"
+# uint32_t reserved0 like: 45474101
+#>>92 ulelong x \b, reserved0 %#x
>>0x05c byte 0 \b, no PAE
>>0x05c byte 1 \b, PAE
+# KdDebuggerDataBlock like: 8054d2e0
+#>>96 ulelong x \b, KdDebuggerDataBlock %#x
+# uint8_t PhysicalMemoryBlockBuffer[700]
+# WinDumpPhyMemDesc32 NumberOfRuns like: 45474150
+#>>100 ulelong x \b, NumberOfRuns %#x
+# WinDumpPhyMemDesc32 uint32_t NumberOfPages like: 1162297680
+#>>104 ulelong x \b, NumberOfPages %#x
+# WinDumpPhyMemRun32 Run[86]; 688 bytes
+#>>108 ulelong x \b, BasePage %#x
+#>>112 ulelong x \b, PageCount %#x
+# uint8_t reserved1[3200]
+#>>800 string x \b, reserved "%s"
+#>>4000 ulelong x \b, RequiredDumpSpace %#x
+# uint8_t reserved2[92];
+#>>4004 string x \b, reserved2 "%s"
>>0xf88 lelong 1 \b, full dump
>>0xf88 lelong 2 \b, kernel dump
>>0xf88 lelong 3 \b, small dump
+# like: 4
+>>0xf88 lelong >3 \b, dump type (%#x)
+# WinDumpPhyMemDesc32 uint32_t NumberOfPages like: 1162297680
+# GRR: IS THIS TRUE? VALUE IS SOMETIMES VERY HIGH!
+#>>104 ulelong x \b, NumberOfPages %#x
>>0x068 lelong x \b, %d pages
+# Reference: http://mark0.net/download/triddefs_xml.7z/defs/d/dmp-64.trid.xml113o
+# Note: called "Windows 64bit Memory Dump" by TrID
+# char ValidDump[4]
>4 string DU64 MS Windows 64bit crash dump
->>0xf98 lelong 1 \b, full dump
->>0xf98 lelong 2 \b, kernel dump
->>0xf98 lelong 3 \b, small dump
+#!:mime application/octet-stream
+!:mime application/x-ms-dmp
+# like: c:\Windows\Minidump\020322-18890-01.dmp c:\Windows\MEMORY.DMP
+!:ext dmp
+# major version like: 15
+>>8 ulelong x \b, version %u
+# minor version like: 9600 19041 22621
+>>12 ulelong x \b.%u
+# DirectoryTableBase like: 001ab000
+#>>16 ulequad x \b, DirectoryTableBase %#llx
+# PfnDatabase like: fffffa8000000000
+#>>24 ulequad x \b, PfnDatabase %#llx
+# PsLoadedModuleList like: fffff800c553f650
+#>>32 ulequad x \b, PsLoadedModuleList %#llx
+# PsActiveProcessHead like: fffff800c5525400
+#>>40 ulequad x \b, PsActiveProcessHead %#llx
+# MachineImageType like: 00008664
+>>48 ulelong !0x8664 \b, MachineImageType %#x
+# NumberProcessors like: 2 4
+>>52 ulelong x \b, %u processors
+# BugcheckCode like: 1000007e
+#>>56 ulelong x \b, BugcheckCode %#x
+# unused0
+#>>60 ulelong x \b, unused0 %#x
+# BugcheckParameter1 like: ffffffffc0000005
+#>>64 ulequad x \b, BugcheckParameter1 %#llx
+# BugcheckParameter2 like: fffff801abb2158f
+#>>72 ulequad x \b, BugcheckParameter2 %#llx
+# BugcheckParameter3 like: ffffd000290d4288
+#>>80 ulequad x \b, BugcheckParameter3 %#llx
+# BugcheckParameter4 like: ffffd000290d3aa0
+#>>88 ulequad x \b, BugcheckParameter4 %#llx
+# VersionUser[32]; like "" "PAGEPAGEPAGEPAGEPAGEPAGEPAGEPAGE" ""
+#>>96 string x \b, VersionUser "%.32s"
+# KdDebuggerDataBlock like: fffff800c550c530
+#>>128 ulequad x \b, KdDebuggerDataBlock %#llx
+# uint8_t PhysicalMemoryBlockBuffer[704]
+# WinDumpPhyMemDesc64 NumberOfRuns like: 6 7 0x45474150
+#>>136 ulelong x \b, NumberOfRuns %#x
+# WinDumpPhyMemDesc64 unused like: 0 0x45474150
+#>>140 ulelong x \b, unused %#x
+# WinDumpPhyMemRun64 Run[43] BasePage like: 1
+#>>152 ulequad x \b, BasePage %#llx
+# WinDumpPhyMemRun64 Run[43] PageCount like: 57h
+#>>160 ulequad x \b, PageCount %#llx
+# uint8_t ContextBuffer[3000] like: "" "\001" "\0207J\266\001\340\377\377&8\007\312"
+#>>840 string x \b, ContextBuffer "%s"
+# WinDumpExceptionRecord ExceptionCode
+#>>3840 ulelong x \b, ExceptionCode %#x
+# WinDumpExceptionRecord ExceptionFlags
+#>>3844 ulelong x \b, ExceptionFlags %#x
+# WinDumpExceptionRecord ExceptionRecord
+#>>3848 ulequad x \b, ExceptionRecord %#llx
+# WinDumpExceptionRecord ExceptionAddress
+#>>3856 ulequad x \b, ExceptionAddress %#llx
+# WinDumpExceptionRecord NumberParameters
+#>>3864 ulelong x \b, NumberParameters %#x
+# WinDumpExceptionRecord unused
+#>>3868 ulelong x \b, unsed %#x
+# WinDumpExceptionRecord ExceptionInformation[15]
+#>>3872 ulequad x \b, ExceptionInformation[0] %#llx
+# https://learn.microsoft.com/en-us/troubleshoot/windows-server/performance/memory-dump-file-options
+# but DumpType like: 4~small 5~full (MEMORY.DMP) 6~kernel (MEMORY.DMP)
+>>0xf98 ulelong x \b,
+>>>0xf98 lelong 5 full dump
+>>>0xf98 lelong 6 kernel dump
+>>>0xf98 lelong 4 small dump
+# This probably never occur
+>>>0xf98 default x DumpType
+>>>>0xf98 ulelong x (%#x)
+# WinDumpPhyMemDesc64 uint64_t NumberOfPages like: 3142425 8341923 8366500 1162297680 4992030524978970960
+# GRR: IS THIS TRUE? VALUE IS SOMETIMES VERY HIGH!
>>0x090 lequad x \b, %lld pages
-
# Summary: Vista Event Log
# Created by: Andreas Schuster (https://computer.forensikblog.de/)
# Update: Joerg Jenderek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file-5.44-windows-dmp.diff.sig
Type: application/octet-stream
Size: 2420 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20230513/b6914e66/attachment.obj>
More information about the File
mailing list