DaseinPhaos/pdb

ExceptionType: 0x4001006 terminating program, even though it's not an indicator of real exception

Closed this issue · 2 comments

While I was creating my glfw app I stumbled upon an issue where if I had obs opened in the background, my app would crash in a few seconds after launch with a stacktrace:

ExceptionType: 0x40010006, Flags: 0x0 Stacktrace:5
C:\WINDOWS\System32\KERNELBASE.dll(0:0)()
C:\WINDOWS\System32\KERNELBASE.dll(0:0)()
C:\ProgramData\obs-studio-hook\graphics-hook64.dll(0:0)()
C:\WINDOWS\System32\KERNEL32.DLL(0:0)()
C:\WINDOWS\SYSTEM32\ntdll.dll(0:0)()

So I looked up this exception code and found this:
https://stackoverflow.com/questions/12298406/how-to-treat-0x40010006-exception-in-vectored-exception-handler

So I tried running this code:

package test

import "pdb"
import "core:sys/windows"
import "core:fmt"

main :: proc()
{
  windows.AddVectoredExceptionHandler(1, pdb.dump_stack_trace_on_exception)
  windows.OutputDebugStringA("")
  for i in 1..=10
  {
     fmt.printf("Hello\n")
  }
}

And got expected result, that is:

ExceptionType: 0x40010006, Flags: 0x0 Stacktrace:7
C:\WINDOWS\System32\KERNELBASE.dll(0:0)()
C:\WINDOWS\System32\KERNELBASE.dll(0:0)()
D:\pliki\odin_funny\pdb_bug\main.odin(11:4)test.main()
C:\Odin\core\runtime\entry_windows.odin(45:21)main()
C:\WINDOWS\System32\KERNEL32.DLL(0:0)()
C:\WINDOWS\SYSTEM32\ntdll.dll(0:0)()

without any Hello\n.

Based of an answer from stackoverflow, I would guess that a fix would be to add at the beginning of dump_stack_trace_on_exception:

dump_stack_trace_on_exception :: proc "stdcall" (ExceptionInfo: ^windows.EXCEPTION_POINTERS) -> windows.LONG {
    if ExceptionInfo.ExceptionRecord.ExceptionCode < 0x8000_0000 {
        return windows.EXCEPTION_CONTINUE_SEARCH
    }
    ...

I tried it and it seems to work. It ignored OutputDebugStringA and detected writing to nil. It also made my glfw app not crash. I don't have any experience with windows api so I don't know if that is the correct way of handling this problem.

There is also an interesting thing where the only difference between master and that modification is printing stacktrace, return value is the same, but stacktrace seems to make my program actually stop with error code 1073807366 (0x40010006).

Sorry for the confusion.

I stumbled upon this myself some time ago. Unfortunately that answer on stackoverflow is not a 100% guranteed fix.
The actual problem was that AddVectoredExceptionHandler got executed before window's own SEH. With the help from folks on the HMN discord I believe the correct fix for this is to switch to using SetUnhandledExceptionFilter instead.

I've updated the demo and readme to reflect that.

See 1618b00 for the fix diff