Last year I was working on improving debugging experience for Wine/Proton and part of that work went into supporting process crashdumps. Supporting minidumps was particularly important and of course it turned out things were broken. I worked on this problem more than a year ago and things may have changed since then. This article is a reconstruction of my old notes since I find the story is quite entertaining even if it’s not so relevant today.
Minidump is a binary format that contains the information about the crashed process. It’s much smaller than a full coredump, but has enough information to reconstruct the call stacks of all threads. Native Windows applications, when run with Wine/Proton, are running as “real” Linux processes and thus can produce valid core/minidumps upon crash. Or could, before Wine 7 happened.
Wine 7+ has changed the way it transitions into the native Linux code – the thread performing a syscall now has a segmented stack: the user-space part (i.e. Windows code) and kernel-space part (i.e. Linux). These two parts are located in different locations in memory and “connected” via a special function called __wine_syscall_dispatcher (which is written in pure assembly and doesn’t have the CFI information). This causes a problem for tools that reconstruct call stacks. The solution for stack unwind was introduced in https://gitlab.winehq.org/wine/wine/-/merge_requests/1065, however minidumps still have a problem – due to the way they are created, they’re missing the memory of the user-space (i.e. Windows) part of the stack.