Microsoft Visual C++ 2012 X64 Additional Runtime

[Shantelle Wenske]

TheVisual C++ Redistributable installs Microsoft C and C++ (MSVC) runtime libraries. Many applications built using Microsoft C and C++ tools require these libraries. If your app uses those libraries, a Microsoft Visual C++ Redistributable package must be installed on the target system before you install your app. The Redistributable package architecture must match your app's target architecture. The Redistributable version must be at least as recent as the MSVC build toolset used to build your app. We recommend you use the latest Redistributable available for your version of Visual Studio, with some exceptions noted later in this article.

Unlike older versions of Visual Studio, which have infrequent redist updates, the version number isn't listed in the following table for Visual Studio 2015-2022 because the redist is updated frequently. To find the version number of the latest redist, download the redist you're interested in using one of the following links. Then, look at its properties using Windows File Explorer. In the Details pane, the File version contains the version of the redist.

Some of the downloads that are mentioned in this article are currently available on my.visualstudio.com. Log in using a Visual Studio Subscription account so that you can access the download links. If you're asked for credentials, use your existing Visual Studio subscription account. Or, create a free account by choosing the No account? Create one! link.

Visual Studio versions since Visual Studio 2015 share the same Redistributable files. For example, any apps built by the Visual Studio 2015, 2017, 2019, or 2022 toolsets can use the latest Microsoft Visual C++ Redistributable. However, the version of the Microsoft Visual C++ Redistributable installed on the machine must be the same or higher than the version of the Visual C++ toolset used to create your application. For more information about which version of the Redistributable to install, see Determining which DLLs to redistribute. For more information about binary compatibility, see C++ binary compatibility between Visual Studio versions.

These links download the latest available en-US Microsoft Visual C++ Redistributable packages for Visual Studio 2013.You can download other versions and languages from Update for Visual C++ 2013 Redistributable Package or from my.visualstudio.com.

These links download the latest available en-US Microsoft Visual C++ Redistributable packages for Visual Studio 2012 Update 4. You can download other versions and languages from Microsoft Visual C++ Redistributable Packages for Visual Studio 2012 Update 4 or from my.visualstudio.com.

Does anyone know the root causes of "Debug Error!" from Microsoft Visual C++ Runtime Library that is often accompanied by a message that says "Damage before 0x0... which was allocated by aligned routine"?

I'm getting this error in one of my codes when I run the executable build with Debug configuration for Intel 64 (64-bit) with the /dbglibs setting for Fortran Run-time libraries. But the executable built with Release configuration runs with no such error. So I rebuilt the Debug configuration executable with non-debug libraries (i.e., /dbglibs setting removed) and this error disappeared.

However I was not getting such an error in my code earlier, so some of my recent changes must have caused this to happen. But I can't figure out what. Note I've unit-tested thoroughly and separately each and every change. The code is quite proprietary, so I can't post it here.

Fyi I'd run into a similar problem earlier - mentioned in this forum topic -us/forums/topic/500781 - and the symptoms now are very similar. Since the previous report was about a missing "finalizer", I've checked the FINAL bindings on all the Fortran "classes" I'm using and have not discovered any problems with any "finalizer" yet.

I suspect (perhaps this is obvious) that you are seeing the error as a result of the additional checking that the debug runtime library does for memory allocations. It does things such as setting guard bytes at the head and tail of any memory allocation, that it can use to check for "damage". There is also support for heap consistency checking in the operating system level library that both the debug and release runtime use, but I think the resulting error messages are different.

The C debug runtime library includes a number of helper routines that you can call from Fortran at various times in your program to try and track down the point at which the apparent heap corruption occurs. Similar support exists in the operating system runtime.

Fortran bindings for some of the C debug runtime functions attached. Due to an unfortunate name clash I can't locate the ones for the operating system routines. Note that these will have been put together on a 32 bit machine and I don't recall ever checking/testing them on 64 bit - though I see I've made some attempt to make things bit generic. _CrtCheckMemory is the one that might help to scatter around. You need to be linking to the static debug runtime for these routines to be relevant.

Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.

Last October, we announced AddressSanitizer support for Windows as part of the x86 retail MSVC toolset. This included an IDE experience in Visual Studio with AddressSanitizer error reporting, visualized in dialog boxes anchored to the source code where the error was caught. AddressSanitizer was designed by Google to improve memory safety in programs by identifying violations. It reports precise errors using source lines and symbols. Most importantly, it reports no false positives.

As of Visual Studio 2019 version 16.7, we support both x64 and x86 targets. Both targets also have full support for Debug and fully optimized Release builds. These compilers produce the new code generation and metadata required to interop with the AddressSanitizer runtime. They support this new functionality with all levels of optimization.

For more information on how to get started, including installing the necessary components for Visual Studio, enabling build system integration, and running ASan from the command line or IDE, take a look at our previous blog post, AddressSanitizer for Windows with MSVC.

__declspec(no_sanitize_address)For certain scenarios, developers might want to opt out of instrumenting entire functions or specific variables. For these uncommon situations, we extended the C/C++ front-ends to annotate variables and functions. We will provide the details of the exact syntax with 16.8 updates.

Automatically link appropriate librariesIn 16.7, the developer must explicitly add the correct AddressSanitizer .lib files to the link line when creating a .EXE or .DLL. We have a linker improvement rolling out in 16.8 to remove the need to do this. This will allow the developer to focus only on whether the CRT being targeted is dynamic or is statically linked to the binary being built. Until then, see the Building from CMD section.

Use-after-returnThis requires code generation that utilizes two stack frames for each function with locals that are tracked by the AddressSanitizer runtime. Running two stacks for one function is complex and just like Clang, a user will have to opt into this feature. It is slow, but it is effective at finding subtle stack corruption bugs impacting reliability or for the security inclined, possible ROP attacks. This is achieved with a simple re-compile.

We have been working hard to make sure the AddressSanitizer toolset and runtimes for Windows can be used with all existing compiler and linker flags so that this technology can drop into complex legacy build systems across a broad number of topologies. This includes external developers, large ISVs, and large teams internal to Microsoft (e.g. Office, Windows, and SQL).

In 16.7, a user will have to explicitly add the specific .LIB files needed to link the AddressSanitizer runtime to their existing application. The AddressSanitizer .LIB files needed to build your .EXE or .DLL depend on your choice of CRT:

These flags tell the compiler to generate code and layout out stack frames that will interop with the AddressSanitizer runtime. The /Zi flag will ensures that debug information will be emitted for optimized code. This information ensures the stack-walker can print stack frames with function names and source line numbers when reporting an error in your code.

We have added a new static library that is automatically used when building AddressSanitizer from the IDE and project system. For command line builds, depending on your version of Visual Studio, an additional step may be required.

For older versions of Visual Studio, if you are building from the command line, you must manually link this library to the binary you are building. The library can be used to capture failures to disk for offline viewing in Visual Studio. This can help with automated test systems and cloud-based workflows that use the AddressSanitizer.

This will save a snapshot file when an error is caught by the AddressSanitizer. The meta-data that is saved in the dump file is parsed by the new Visual Studio IDE. You can set this variable on a per test basis and store these binary artifacts and then view these in the IDE with proper source indexing.

The code the compiler needs to generate (for all alignment scenarios) can get complex, and this is an area we are finishing up with extended stress testing. In the meantime, bugs in this area will result in false positives.

3a8082e126