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.

Link Time Changes (/INFERASANLIBS)

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.

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!

Amy Wishnousky

Follow