[Issue] ASan Interception Error (unhandled instruction) on Windows - dev-2026-04

Help
1

Title: ASan Interception Error: “unhandled instruction” with MSVC 19.50 / Odin dev-2026-04

Problem: I am encountering an AddressSanitizer interception error on Windows when running a basic “Hello World” program. While the program completes, ASan reports an unhandled instruction. This suggests the ASan runtime is failing to properly hook a function within the Windows CRT/UCRT.

Environment:

  • Odin Version: dev-2026-04
  • OS: Windows 11 (25H2)
  • MSVC Build Tools: 19.50.35726 (VS 2026)
  • Bundled Clang/ASan: 18.1.8
  • Command: odin run . -debug -sanitize:address

Error Output:
==7708==interception_win: unhandled instruction at 0x7ff79bad445b: 84 d2 75 3f 41 83 e0 0f Hello World

Context: This occurs even with a bare-bones main function. The hex sequence 84 d2 75 3f 41 83 e0 0f appears to be an instruction sequence that the bundled Clang 18.1.8 ASan library doesn’t recognize or know how to patch safely. Given that I’m on MSVC 19.50, I suspect a recent change in the Windows CRT assembly is tripping up the interceptor.

Questions:

  1. Is Clang 18.1.8 known to have issues with the latest MSVC 19.50 toolset?
  2. Is there a recommended way to update the bundled clang_rt.asan-x86_64.lib to a version compatible with newer Windows updates?
  3. Are there any ASAN_OPTIONS (like intercept_tls_get_addr=0 or similar) that might stabilize this on Windows?
2

I’m on Windows 11 with clang version 20.1.8. I get the same error when using ‘odin run . -debug -sanitize:address’, but not when using ‘odin build . -debug -sanitize:address’. I wonder if this has more to do with the fact that ‘run’ temporarily creates an exe and then deletes it after execution, which may be occurring to quickly for the sanitize process to complete. This is only a guess.

1 Like
3

Thank you, xuul.

I wasn’t using the run command previously, but I’ve since rebuilt Odin. Interestingly, while I’m still seeing the ‘inception error,’ ASan on Windows is now successfully detecting stack Use-After-Free (UAF).

A few observations from my testing:

  • Stack UAF: For ASan to catch stack UAF, you must explicitly enable detect_stack_use_after_return in your active session (see below).
  • Heap UAF & Poisoning: ASan on Windows doesn’t seem to be catching heap UAFs natively in my tests (even with debug prints). To mitigate this, I’m currently manually poisoning freed heap memory by assigning pointers to nil immediately after freeing. This ensures that any subsequent access triggers a clean segfault at a zero address rather than silent corruption.

For anyone interested, here is the debug target I’m using in my build.bat. Note how I export the ASAN_OPTIONS through the endlocal barrier so they persist in your terminal after the script finishes:

:: ==========================================
:: TARGET: DEBUG (Ultra-Conservative EXE)
:: ==========================================
:debug
echo [INFO] Target: Debug EXE (Conservative Validation, Warnings-as-Errors, Flashlight Tracking)
set "OUT_FILE=app.exe"
odin build . -out:!OUT_FILE! -debug -sanitize:address -vet -strict-style -warnings-as-errors
set BUILD_STATUS=!ERRORLEVEL!
call :summary

:: Export ASAN_OPTIONS through the setlocal barrier so it persists in your active terminal
endlocal & set "ASAN_OPTIONS=windows_hook_rtl_allocators=false:detect_stack_use_after_return=true" & exit /b !BUILD_STATUS!