We have been investing in the quality of MSVC Address Sanitizer (ASan) in several key areas over the past year, including working with LLVM upstream to stay coordinated with their changes, adding coverage for internal tools and libraries, and hardening APIs and runtime modes. 

Upstreaming to LLVM 

MSVC ASan is derived from a fork of the LLVM repository. Prior to Visual Studio 2022 version 17.12, MSVC ASan was based on outdated versions of LLVM’s compiler-rt (where the ASan source code lives), and we could not incorporate changes from newer versions of LLVM without significant delay.  

We have recently completed upstreaming major parts of the MSVC ASan runtime. Now we can start to do more work in the open, and we will be shipping improvements made by the rest of the LLVM community. As of Visual Studio 2022 version 17.12, we are taking changes from LLVM main weekly. 

There are modifications for support on Windows specific to MSVC that are not yet upstream, such as: 

• We intercept more of the memory allocators provided by Windows to support legacy apps and the more exotic allocation mechanisms exclusive to Windows. 

• We provide a “continue-on-error” mode to help fix issues in applications with many memory errors and a long iteration cycle. This is like LLVM’s halt_on_error=0 mode. 

• We provide enhanced diagnostics for new/delete mismatches. 

• We only provide the dynamic ASan runtime to support a wide range of CRT link/usage scenarios. 

MSVC tools and compiler built with ASan 

We have recently been able to focus on adopting ASan into the MSVC codebase, which means building the compiler, linker, code analysis tools, and runtime libraries for testing with /fsanitize=address. We have also done the work to enable Microsoft’s C++ Standard Library (STL) with ASan.  

Note: These are strictly used for testing purposes, and developers should not ship binaries with ASan enabled. 

It has been a massive undertaking, considering all the moving parts, and is still an ongoing effort for some components. The MSVC codebase has been around much longer than ASan. As a result, many of the bugs that ASan would identify have already been solved thanks to internal testing or defect reports. However, developers will inevitably introduce new memory safety issues, so enabling ASan will prevent shipping those defects by identifying them during continuous integration and testing. This effort allows us to run thousands of regression test scenarios with ASan enabled on each pull request, blocking developers from merging any newly introduced memory safety errors. 

In case you need any extra motivation to adopt ASan in your codebase, below is a list of the improvements we have made recently. 

Fixes in Visual Studio 2022 version 17.13 GA 

• Improved Global and Local memory management interoperability 

• These APIs have been a challenge in the past for MSVC ASan. 

• Increased surface area for intercepted APIs, fixing issues surrounding false positives when operating in legacy apps/environments. 

• Fixed issues distinguishing between memory that was allocated prior to ASan entering the process, resulting in false positives. 

• Continue-on-error reporting and interface APIs are now in the same format as the other error reporting by ASan runtime. 

• Continue-on-error can properly handle multiple subprocesses being launched with ASan in process, multiple process invocations, and multithreaded reporting. 

• Fixed issues concerning aligned_offset memory APIs, now properly respecting valid alignment and offsets. 

• Fixed issues surrounding intercepting some _Crt* APIs, and false positives resulting from incorrect interceptions. 

• Fixed interception issues surrounding new or changed instruction sequences with x64 and x86 processors. Upstreaming this effort has helped to identify and fix these issues quicker! 

• Fixed issues surrounding memcpy aliasing memmove on x86 and distinguishing between calls resulting in confusing or incorrect ASan reports. 

• Some wide string intrinsics have been added for memory tracking. 

• Changed the order of initialization to fix an issue with ASan-instrumented code being executed prior to ASan initialization. 

Try it out! 

We would love for you to download Visual Studio and give the Address Sanitizer a try. As always, we welcome your feedback. We can be reached via the comments below. If you encounter any problems with MSVC or have a suggestion for Visual Studio, please let us know via Developer Community or directly in Visual Studio through Help > Send Feedback > Report A Problem / Provide a Suggestion in the product.