AddressSanitizer (ASan) for Windows with MSVC

Augustin Popa

⌚ This post was last updated on March 24th, 2021 with the latest information on ASan support.

Note: This feature is now generally available. To get started, take a look at the official AddressSanitizer for Windows with MSVC documentation. Many experience improvements have been made since this blog post was published, and our docs have the latest information.

We are pleased to announce AddressSanitizer (ASan) support for the MSVC toolset. ASan is a fast memory error detector that can find runtime memory issues such as use-after-free and perform out of bounds checks. Support for sanitizers has been one of our more popular suggestions on Developer Community, and we can now say that we have an experience for ASan on Windows, in addition to our existing support for Linux projects.

At Microsoft, we believe that developers should be able to use the tools of their choice, and we are glad to collaborate with the LLVM team to introduce more of their tooling into Visual Studio. In the past, we also incorporated tools like clang-format, and most recently, clang-tidy. MSVC support for ASan is available in our second Preview release of Visual Studio 2019 version 16.4.

To bring ASan to Windows and MSVC, we made the following changes:

• The ASan runtime has been updated to better target Windows binaries
• The MSVC compiler can now instrument binaries with ASan
• CMake and MSBuild integrations have been updated to support enabling ASan
• The Visual Studio debugger now can detect ASan errors in Windows binaries
• ASan can be installed from the Visual Studio installer for the C++ Desktop workload

When you’re debugging your ASan-instrumented binary in Visual Studio, the IDE Exception Helper will be displayed when an issue is encountered, and program execution will stop. You can also view detailed ASan logging information in the Output window.

Installing ASan support for Windows

ASan is included with the C++ Desktop workload by default for new installations. However, if you are upgrading from an older version of Visual Studio 2019, you will need to enable ASan support in the Installer after the upgrade:

You can click Modify on your existing Visual Studio installation from the Visual Studio Installer to get to the screen above.

Note: if you run Visual Studio on the new update but have not installed ASan, you will get the following error when you run your code:

LNK 1356 – cannot find library ‘clang_rt.asan_dynamic-i386.lib’

Turning on ASan for Windows MSBuild projects

You can turn on ASan for an MSBuild project by right-clicking on the project in Solution Explorer, choosing Properties, navigating under C/C++ > General, and changing the Enable Address Sanitizer (Experimental) option. The same approach can be used to enable ASan for MSBuild Linux projects.

Note: Right now, this will only work for x86 Release targets, though we will be expanding to more architectures in the future.

Turning on ASan for Windows CMake projects

To enable ASan for CMake projects targeting Windows, do the following:

1. Open the Configurations dropdown at the top of the IDE and click on Manage Configurations. This will open the CMake Project Settings UI, which is saved in a CMakeSettings.json file.
2. Click the Edit JSON link in the UI. This will switch the view to raw .json.
3. Under the x86-Release configuration, add the following property: “addressSanitizerEnabled”: true

You may get a green squiggle under the line above with the following warning: Property name is not allowed by the schema. This is a bug that will be fixed shortly – the property will in fact work.

Here is an image of the relevant section of the CMakeSettings.json file after the change:

We will further simplify the process for enabling ASan in CMake projects in a future update.

Contributions to ASan Runtime

To enable a great Windows experience, we decided to contribute to the LLVM compiler-rt project and reuse their runtime in our implementation of ASan. Our contributions to the ASan project include bug fixes and improved interception for HeapAlloc , RtlAllocateHeap , GlobalAlloc , and LocalAlloc , along with their corresponding Free , ReAllocate , and Size functions. Anyone can enable these features by adding the following to the ASAN_OPTIONS environment variable for either Clang or MSVC on Windows:

set ASAN_OPTIONS= windows_hook_rtl_allocators=true

Additional options can be added with a colon at the end of the line above.

Changes to MSVC to enable ASan

To enable ASan, c1.dll and c2.dll have been modified to add instrumentation to programs at compile time. For a 32-bit address space, about 200 MB of memory is allocated to represent (or ‘shadow’) the entire address space. When an allocation is made, the shadow memory is modified to represent that the allocation is now valid to access. When the allocation is freed or goes out of scope, the shadow memory is modified to show that this allocation is no longer valid. Memory accesses which are potentially dangerous are checked against their entry in the shadow memory to verify that the memory is safe to access at that time. Violations are reported to the user as output from either stderr or an exception window in Visual Studio. The allocation data in the shadow memory is checked before the access happens. The AddressSanitizer algorithm enables error reports to show exactly where the problem occurred and what went wrong.

This means that programs compiled with MSVC + ASan also have the appropriate clang_rt.asan library linked for their target. Each library has a specific use case and linking can be complicated if your program is complex.

Compiling with ASan from the console

If you are on Visual Studio version 16.9 Preview 3 or later, if thefsanitize=address compiler flag is specified, ASan libraries are automatically linked (both for console and IDE builds).

For console compilation, if you are on Visual Studio version 16.9 Preview 2 or earlier, you will have to link the ASan libraries manually. Here are the libraries required for an x86 target:

• clang_rt.asan-i386.lib – static runtime compatible with /MT CRT.
• clang_rt.asan_cxx-i386.lib -static runtime component which adds support for new and delete, also compatible with /MT CRT.
• clang_rt.asan_dynamic-i386.lib – dynamic import library, compatible with /MD CRT.
• clang_rt.asan_dynamic-i386.dll – dynamic runtime DLL, compatible with /MD.
• clang_rt.asan_dynamic_runtime_thunk-i386.lib – dynamic library to import and intercept some /MD CRT functions manually.
• clang_rt.asan_dll_thunk-i386.lib – import library which allows an ASAN instrumented DLL to use the static ASan library which is linked into the main executable. Compatible with /MT CRT.

Once you have selected the correct ASan runtime to use, you should add /wholearchive:<library to link> to your link line and add the appropriate library to your executables. The clang_rt.asan_dynamic_i386.dll is not installed into System32, so when running you should make sure it is available in your environment’s search path.

Some additional instructions:

• When compiling a single static EXE: link the static runtime (asan-i386.lib) and the cxx library if it is needed.
• When compiling an EXE with the /MT runtime which will use ASan-instrumented DLLs: the EXE needs to have asan-i386.lib linked and the DLLs need the clang_rt.asan_dll_thunk-i386.lib. This allows the DLLs to use the runtime linked into the main executable and avoid a shadow memory collision problem.
• When compiling with the /MD dynamic runtime: all EXE and DLLs with instrumentation should be linked with copies of asan_dynamic-i386.lib and clang_rt.asan_dynamic_runtime_thunk-i386.lib. At runtime, these libraries will refer to the clang_rt.asan_dynamic-i386.dll shared ASan runtime.

The ASan runtime libraries patch memory management functions at run-time and redirect executions to an ASan wrapper function which manages the shadow memory. This can be unstable if the runtime environment differs from what the libraries have been written to expect. Please submit any compile or run time errors which you encounter while using ASan via the feedback channels below!

Note: Loading ASan-instrumented DLLs with an non-ASan-instrumented EXE without linking the clang_rt.asan_dynamic and clang_rt.asan_dynamic­_runtime_thunk library will result in false positive ASan reports. This is due to allocations being created in-between program initialization and whenever the ASan instrumented DLL is loaded. Any allocations which are created during this window will result in an erroneous bug report when they are passed into the newly intercepted CRT functions. These false positive reports are avoidable if you link the dynamic import libraries into the main executable; since linking the dynamic runtime libraries in this manner allows the interceptors to initialize at the proper time. Be sure to use the /wholearchive linker flag to ensure asan’s init routines are not optimized away in the main exe.

Send us feedback!

Your feedback is key for us to deliver the best experience running ASan in Visual Studio. We’d love for you to try out the latest Preview version of Visual Studio 2019 version 16.4 and let us know how it’s working for you, either in the comments below or via email. If you encounter problems with the experience or have suggestions for improvement, please Report A Problem or reach out via Developer Community. You can also find us on Twitter @VisualC.

Augustin Popa Senior Product Manager, Microsoft C++ Team

Follow