EQ EduQuill

Unreal Engine Debugging

Fixing Address Sanitizer Crashes in Unreal Editor on Windows

I recently hit a wall trying to enable Address Sanitizer in the Unreal Editor on Windows. Instead of a smooth debugging session, I was met with silent failures and an editor that simply refused to launch, eventually pointing toward a massive, bloated executable that broke the underlying Windows memory management expectations.

Published March 13, 2026 6 min read Unreal Engine

Need environments, meshes, materials, or reference packs to validate this Unreal workflow inside a larger scene?

Open on 3DCGHub

1. The Symptom of a Bloated Binary

My initial attempt to run an ASan-enabled build resulted in an immediate failure during the launch sequence. It wasn't a standard runtime crash or a predictable access violation, but rather a failure to initialize that seemed tied to the sheer volume of instrumented code generated by the compiler.

After checking the disk, I realized the resulting editor binary was ballooning well beyond what the system could reliably map. It became clear that the standard modular build structure was essentially multiplying the overhead, pushing the executable size toward a threshold that Windows handles poorly in this context.

  • Verified that standard modular builds were generating binaries exceeding 2.5 GiB.
  • Observed failed initialization sequences on Windows startup.
  • Confirmed that instrumented overhead scales non-linearly in standard builds.

2. Revisiting the Build Strategy

My first thought was to adjust memory limits, but that was a red herring. The real issue was the interaction between modular DLLs and the sanitizer's instrumentation. Each module introduces its own overhead, and the cumulative cost of managing cyclic dependencies under ASan was destroying the stability of the editor startup.

I decided to switch to a monolithic build configuration. By bundling everything into a single executable, I removed the complexity of inter-module instrumentation and gave the linker a better chance at optimizing the final memory footprint.

  • Switched project target to a monolithic build type.
  • Evaluated the impact on link-time optimization.
  • Isolated the instrumentation overhead within a single binary block.

3. Optimizing Instrumentation Output

Even with a monolithic build, the executable was still far too large to be practical. I started looking into how Clang handles instrumentation, specifically focusing on how it inlines these checks into every function. This is where the outline instrumentation flag became critical.

By offloading the instrumentation checks to an outlined function, I significantly reduced the inline bloat. This change alone brought my executable size down from 2.7 GiB to 2.0 GiB, keeping the project within the effective limits for Windows execution.

  • Enabled -fsanitize-address-outline-instrumentation in the Clang toolchain.
  • Prevented excessive function inlining of debug checks.
  • Validated the reduction in total binary size.

4. Finalizing and Validating Stability

The last mile was applying compiler optimization settings tailored for size. By forcing the compiler to prioritize size over raw performance for this specific build, I managed to drop the footprint down to 1.59 GiB.

This brought the binary well under the unofficial 1.85 GiB limit that seems to be the ceiling for ASan-enabled Windows applications. The editor finally launched, providing me with the telemetry I needed to start tracking down those elusive memory issues.

  • Applied size-optimization flags to the build target.
  • Confirmed final executable size is below the 1.85 GiB stability threshold.
  • Ensured the editor remains functional for local testing.

Key snippets

Observed error signal 1

log

Exact error text captured from the first post.

This question was created in reference to: [Failed to build a working address sanitizer UnrealEditor on win64 (Engine version [Content removed]

Applying Outline Instrumentation

bash

Required compiler flag to reduce binary bloat by moving instrumentation logic outside of inlined functions.

-fsanitize-address-outline-instrumentation

FAQ

Why use monolithic builds for ASan?

Modular builds introduce significant overhead due to inter-module dependencies and shared state tracking. Monolithic builds consolidate this, reducing the memory pressure and linker complexity.

What is the primary benefit of outline instrumentation?

It prevents the compiler from inlining instrumentation code into every function, which dramatically reduces binary size at the cost of a minor performance penalty during runtime checks.

References