Investigate Windows Unwinding involving `RtlDispatchException`

[Swatinem]

We have a customer (with retained minidumps and usable debug files; sentry employees should know which one I mean) that reports incomplete / truncated stack traces for Windows minidumps that involve RtlDispatchException.

We recently improved our handling of UWOP_SET_FPREG which is used by this function. I have also verified again that a previously broken minimal reproduction in https://github.com/getsentry/sentry-native/issues/582 now processes correctly.

The investigation should focus on the following points:

• UWOP_SET_FPREG relies on $rbp being available. Is it? If not, why? And can we get it from somewhere?
• NOTE: $rbp is a preserved / non-volatile / callee saves register. So if CFI does not explicitly state how to restore it, we should be able to assume it is not modified by the function.
• Maybe some other frames in the stack use UWOP_PUSH_MACHFRAME, and we are running into https://github.com/rust-minidump/rust-minidump/issues/637 ?

---

`RtlDispatchException` unwind info

You need a patched llvm-objdump for this.

Function Table:
  Start Address: 0x51210
  End Address: 0x51578
  Unwind Info Address: 0x146454
    Version: 1
    Flags: 3 UNW_ExceptionHandler UNW_TerminateHandler
    Size of prolog: 48
    Number of Codes: 12
    Frame register: RBP
    Frame offset: 64
    Unwind Codes:
      0x1f: UOP_SaveNonVol RBX [0x0220]
      0x18: UOP_SetFPReg 
      0x13: UOP_AllocLarge 58
      0x0c: UOP_PushNonVol R15
      0x0a: UOP_PushNonVol R14
      0x08: UOP_PushNonVol R13
      0x06: UOP_PushNonVol R12
      0x04: UOP_PushNonVol RDI
      0x03: UOP_PushNonVol RSI
      0x02: UOP_PushNonVol RBP

---

STACK CFI INIT 51210 368
  .cfa: $rbp 464 +
  $rbp: .cfa 16 - ^
  $rsi: .cfa 24 - ^
  $rdi: .cfa 32 - ^
  $r12: .cfa 40 - ^
  $r13: .cfa 48 - ^
  $r14: .cfa 56 - ^
  $r15: .cfa 64 - ^
  $rbx: $rbp 480 + ^
  .ra: .cfa 8 - ^

More details are also in https://github.com/getsentry/symbolic/issues/546

[marekr]

I just got a new RtlDispatchException that did come in correctly callstack wise

https://sentry.io/organizations/kicad/issues/3524857869/?project=6266565

Except there's another layer from the windows kernel KiUserExceptionDispatch before RtlDispatchException, sentry isn't aware it should ignore that and go up one more level in the call stack for identifying the error in LIB_SYMBOL::ClearCaches instead.

[Swatinem]

I think that is rather a grouping concern, and not about unwinding the call stack. We do want to have KiUserExceptionDispatch in the call stack, as it is probably also what Visual Studio would give you.