MSVC Address Sanitizer – One DLL for all Runtime Configurations

Amy Wishnousky

With Visual Studio 2022 version 17.7 Preview 3, we have refactored the MSVC Address Sanitizer (ASan) to depend on one runtime DLL regardless of the runtime configuration. This simplifies project onboarding and supports more scenarios, particularly for projects statically linked (/MT, /MTd) to the C Runtimes. However, static configurations have a new dependency on the ASan runtime DLL.

Summary of the changes:

  • ASan now works with /MT or /MTd built DLLs when the host EXE was not compiled with ASan. This includes Windows services, COM components, and plugins.
  • Configuring your project with ASan is now simpler, since your project doesn’t need to uniformly specify the same runtime configuration (/MT, /MTd, /MD, /MDd).
  • ASan workflows and pipelines for /MT or /MTd built projects will need to ensure the ASan DLL (clang_rt.asan_dynamic-<arch>.dll) is available on PATH.
  • The names of the ASan .lib files needed by the linker have changed (the linker normally takes care of this if not manually specifying lib names via /INFERASANLIBS)
  • You cannot mix ASan-compiled binaries from previous versions of the MSVC Address Sanitizer (this is always true, but especially true in this case).

Motivation and Effects

When building a project, you must specify how you want to link to the C and C++ Runtime Libraries. Using the /MD option will link dynamically to the runtimes and have DLL dependencies provided by the Windows operating system (ex: ucrtbase.dll) and the VC++ Redistributable (ex: vcruntime140.dll, msvcp140.dll). This is a great default option to choose, as it allows you to take advantage of the latest available on the system and minimizes memory usage. The /MT option specifies that the runtime libraries will be statically linked (via libucrt.lib, libvcruntime.lib, libcpmt.lib, etc) in your program such that you have no VC++ DLL dependencies. This option is useful when dynamically linking complicates deployment and is most frequently used with projects like plugins or drivers.

Prior to Visual Studio 2022 v17.7 Preview 3, MSVC Address Sanitizer followed the same methodology and treated itself as one of the runtime libraries. If /MD was specified, ASan would be available as a DLL (clang_rt.asan_dynamic-<arch>.dll). If /MT was specified, ASan would be linked into the EXE. ASan can only have one instance at a time, so DLLs that were statically linked would assume the EXE of the process was also built with ASan and would call into that EXE for support. This caused problems for any software that could not recompile the host EXE with ASan enabled: plugins, COM components, Windows services, etc. Here is an example reported on Developer Community. Additionally, since each runtime configuration had its own version of ASan, you could not mix components with different runtime configurations.

As of Visual Studio v17.7 Preview 3, runtime configuration is no longer considered and there is one Address Sanitizer DLL per architecture. In addition to supporting more scenarios, this can also significantly simplify onboarding a complex project with ASan. A side effect is that projects statically linked with /MT or /MTd now have a dependency on the ASan runtime DLL.

When /fsanitize=address is passed to the compiler, /INFERASANLIBS will automatically be passed to the linker, which will take care of the link time requirements for Address Sanitizer.

If you use /INFERASANLIBS:NO in your build and manually specify which ASan libraries you link with, you will also need to change which .lib files are passed to the linker.

/INFERASANLIBS prior to VS 2022 v17.7 Preview 3
/MT clang_rt.asan_cxx-<arch>.lib EXE: /wholearchive:clang_rt.asan-<arch>.lib
DLL: /wholearchive:clang_rt.asan_dll_thunk-<arch>.lib
/MTd clang_rt.asan_cxx_dbg-<arch>.lib EXE: /wholearchive:clang_rt.asan_dbg-<arch>.lib
DLL: /wholearchive:clang_rt.asan_dbg_dll_thunk-<arch>.lib
/MD clang_rt.asan_dynamic-<arch>.lib /wholearchive:clang_rt.asan_dynamic_runtime_thunk-<arch>.lib
/MDd clang_rt.asan_dbg_dynamic-<arch>.lib /wholearchive:clang_rt.asan_dbg_dynamic_runtime_thunk-<arch>.lib
/INFERASANLIBS as of VS 2022 v17.7 Preview 3
/MT clang_rt.asan_dynamic-<arch>.lib /wholearchive:clang_rt.asan_static_runtime_thunk-<arch>.lib
/MTd clang_rt.asan_dynamic-<arch>.lib /wholearchive:clang_rt.asan_static_runtime_thunk-<arch>.lib
/MD clang_rt.asan_dynamic-<arch>.lib /wholearchive:clang_rt.asan_dynamic_runtime_thunk-<arch>.lib
/MDd clang_rt.asan_dynamic-<arch>.lib /wholearchive:clang_rt.asan_dynamic_runtime_thunk-<arch>.lib

Troubleshooting

The MSVC AddressSanitizer does not attempt to maintain compatibility with older versions, unlike other MSVC libraries. You should deploy a version of the AddressSanitizer DLL that matches the version of the toolset used when compiling your ASan-instrumented code. Here are some common issues you may see if you are mixing ASan-enabled projects built before and after Visual Studio 2022 17.7 Preview 3:

“The code execution cannot proceed because clang_rt.asan_dynamic-x86_64.dll was not found.”

“The code execution cannot proceed because clang_rt.asan_dynamic-i386.dll was not found.”

These messages are displayed when an ASan binary was deployed in an environment without the AddressSanitizer DLL. If you are seeing this immediately after updating to Visual Studio 2022 17.7 Preview 3 and you are statically linking to the C Runtime (/MT, /MTd), that binary has a new dependency on the ASan DLL named and must be included in the environment. Please update the PATH to include clang_rt.asan_dynamic-x86_64.dll (x64) or clang_rt.asan_dynamic-i386.dll (x86).

“The procedure entry point __sanitizer_override_function could not be located in the dynamic link library.”

“The procedure entry point __sanitizer_register_weak_function could not be located in the dynamic link library.”

These messages are displayed when a binary built with 17.7 Preview 3 is deployed in an environment with an AddressSanitizer DLL from a toolset prior to 17.7 Preview 3. Please update clang_rt.asan_dynamic-x86_64.dll (x64) or clang_rt.asan_dynamic-i386.dll (x86) to the latest version included with your current version of Visual Studio.

Let us know what you think!

Please check out the new MSVC AddressSanitizer improvements in Visual Studio 2022 v17.7 Preview 3 and let us know if you have any comments, questions, or other feedback in the comments below or on Developer Community!

 

Posted in C++

5 comments

Comments are closed. Login to edit/delete your existing comments

  • Peter 0

    ASan complied and linked exe crashes immediately in version 17.8.0 Preview 1.0 (previous preview was OK):
    Faulting application name: RegressionTest.exe, version: 0.0.0.0, time stamp: 0x64d4b60b
    Faulting module name: clang_rt.asan_dynamic-x86_64.dll, version: 0.0.0.0, time stamp: 0x64b851ff
    Exception code: 0xc0000005
    Fault offset: 0x0000000000051c87
    Faulting process id: 0x0x2734
    Faulting application start time: 0x0x1D9CB792E9C57D9
    Faulting application path: C:\Projects\xxxx\RegressionTest.exe
    Faulting module path: C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.38.32919\bin\HostX64\x64\clang_rt.asan_dynamic-x86_64.dll
    Report Id: f426514e-34c0-48cc-a528-52b30422d9df
    Faulting package full name:
    Faulting package-relative application ID:

    • Mahmoud SalehMicrosoft employee 0

      Hi Peter,
      Thanks for reporting this issue. Can you please open a feedback report on Developer Community providing the repro details using this link: https://developercommunity.visualstudio.com/cpp/report

  • Michael Litwak 0

    I’ve never before been able to get my AddressSantizer builds to link properly. All of my static libraries, DLLs and EXEs (some are MFC or use ATL) are statically linked. I’ll try soon with Visual studio 2022 build 17.7.1 — I’m hopeful the new AddressSanitizer runtime DLL will allow me to fully build and run AddressSanitizer builds for the first time.

    Thanks for making this a priority.

  • Mustafa Adaoglu 0

    Address Sanitizer is super useful for debug builds. Unfortunately, C++ 20 modules fail to compile with the Address Sanitizer enabled. This has been an active/under investigation issue for over 2 years but unfortunately seems to have been forgotten. Anyone else experiencing similar errors?
    https://developercommunity.visualstudio.com/t/Compilation-fails-when-both-C-Modules/1359160

    • Nicole MazzucaMicrosoft employee 0

      This should be fixed in 17.9 (preview 2, hopefully) – sorry for it taking so long!

Feedback usabilla icon