It looks like while the main process's module has proper address metadata in a minidump, at least some dynamic libraries don't. For example, I have a minidump produced by the diskwrite example pulling in #42. The top frame of its call stack should be __psynch_cvwait in libsystem_kernel.dylib, but the base_of_image value reported for the libsystem_kernel.dylib module is 0x1802ed000 - too small. It looks like there's no ASLR on this module for some reason, so I used LLDB on a separate run and it reports the base address as 0x18e935000. That lines up properly with the instruction pointer at the start of the thread's stack frame in the minidump.
Here's the dump of this module:
module[12]
MINIDUMP_MODULE
base_of_image = 0x1802ed000
size_of_image = 0x38000
checksum = 0x0
time_date_stamp = 0x0 1970-01-01T00:00:00Z
module_name_rva = 0x29cd
version_info.signature = 0xfeef04bd
version_info.struct_version = 0x10000
version_info.file_version = 0x1f54:0x790003
version_info.product_version = 0x0:0x0
version_info.file_flags_mask = 0x0
version_info.file_flags = 0x0
version_info.file_os = 0x0
version_info.file_type = 0x0
version_info.file_subtype = 0x0
version_info.file_date = 0x0:0x0
cv_record.data_size = 47
cv_record.rva = 0x2a1d
misc_record.data_size = 0
misc_record.rva = 0x0
(code_file) = "/usr/lib/system/libsystem_kernel.dylib"
(code_identifier) = "03f48dc5caa73678af611a3c7fa8b06e"
(cv_record).cv_signature = 0x53445352
(cv_record).signature = 03f48dc5-caa7-3678-af61-1a3c7fa8b06e
(cv_record).age = 0
(cv_record).pdb_file_name = "libsystem_kernel.dylib"
(misc_record) = (null)
(debug_file) = "libsystem_kernel.dylib"
(debug_identifier) = "03f48dc5-caa7-3678-af61-1a3c7fa8b06e"
(version) = "0.8020.121.3"
And the register state of the thread:
thread[0]
MINIDUMP_THREAD
thread_id = 0xc03
suspend_count = 0
priority_class = 0x0
priority = 0x0
teb = 0x0
stack.start_of_memory_range = 0x16d47dfd0
stack.memory.data_size = 0x2030
stack.memory.rva = 0xa8
thread_context.data_size = 0x31c
thread_context.rva = 0x20d8
CONTEXT_ARM64_OLD
context_flags = 0x80000006
x0 = 0x13c6042d0
x1 = 0x100000100
x2 = 0x0
x3 = 0x0
x4 = 0x0
x5 = 0xa0
x6 = 0x0
x7 = 0x0
x8 = 0x16d47dfe8
x9 = 0x1
x10 = 0x13c6042a8
x11 = 0x2
x12 = 0x0
x13 = 0x0
x14 = 0x0
x15 = 0x0
x16 = 0x131
x17 = 0x1e89ff638
x18 = 0x0
x19 = 0x13c604290
x20 = 0x13c6042d0
x21 = 0x102fd8660
x22 = 0x0
x23 = 0x0
x24 = 0x0
x25 = 0x1
x26 = 0x100
x27 = 0x0
x28 = 0x0
x29 (fp) = 0x16d47e060
x30 (lr) = 0x18e97483c
sp = 0x16d47dfd0
pc = 0x18e93a270
cpsr = 0x40001000
fpsr = 0x0
fpcr = 0x0
And the full minidump: minidump.tar.gz
It looks like while the main process's module has proper address metadata in a minidump, at least some dynamic libraries don't. For example, I have a minidump produced by the diskwrite example pulling in #42. The top frame of its call stack should be
__psynch_cvwaitinlibsystem_kernel.dylib, but thebase_of_imagevalue reported for the libsystem_kernel.dylib module is0x1802ed000- too small. It looks like there's no ASLR on this module for some reason, so I used LLDB on a separate run and it reports the base address as0x18e935000. That lines up properly with the instruction pointer at the start of the thread's stack frame in the minidump.Here's the dump of this module:
And the register state of the thread:
And the full minidump: minidump.tar.gz