Faulting module name: MSVCR110.dll, version: 11.0.51106.1

Question

_{Wednesday, August 5, 2020 8:58 AM}

Dear Community ,

We have few C++ modules running as windows services. It is live at customer machines. In one particular machine the windows services stops with the below mentioned error in the event viewer. I know it is related to do with VC++ Redistributable  package 2012. Since it is a live environment, can you please guide me on how to rectify this error? In many cases I had seen MSVCR110.dll will be missing if VC++ package is not installed. But, here the package is installed but it says it is faulty.

Faulting application name: VigilEntAgent.exe, version: 9.1.0.2, time stamp: 0x58d4a7aa
Faulting module name: MSVCR110.dll, version: 11.0.51106.1, time stamp: 0x5098858e
Exception code: 0xc0000409
Fault offset: 0x000a326c
Faulting process id: 0x2b90
Faulting application start time: 0x01d669a1042366f2
Faulting application path: C:\Program Files (x86)\NetIQ\ChangeGuardianAgent\bin\VigilEntAgent.exe
Faulting module path: C:\windows\SYSTEM32\MSVCR110.dll
Report Id: 4845eef4-d594-11ea-80f6-b4b52f605d48
Faulting package full name: 
Faulting package-relative application ID:

karthick Prathap Singh

All replies (2)

_{Wednesday, August 5, 2020 10:49 AM | 1 vote}

The Exception Code 0xC0000409 means Stack Buffer Overrun (https://social.msdn.microsoft.com/Forums/vstudio/en-US/a197c527-da91-4ef0-8230-330f58f9abb4). Probably some of arrays or variables, allocated on stack, are incorrectly overwritten dues to some possible defects of your code.

Try adding the /GS compiler option (/en-us/cpp/build/reference/gs-buffer-security-check) and see if you get more details (maybe a stack trace too). Determine the portions of your code that lead to error.

You can also try running the Debug version of your service if you have the libraries.

_{Wednesday, August 5, 2020 4:19 PM | 1 vote}

While I totally agree with Viorel_'s answer, there is one thing that should be made clear.

The faulting module reported by Windows isn't necessarily the module that the problem is in. In other words, a module can be reported as causing a crash when it wasn't responsible. An example of this is:

#define _CRT_SECURE_NO_WARNINGS
#include <cstring>

int main()
{
    char buf[50];

    memcpy(buf, nullptr, 50);

    return 0;
}

The null pointer as the source should be obvious. If you run this then it will crash, but what may not be obvious is that it will show that it crashed in one of the Visual C++ runtime files. For Visual Studio 2019 as an example it would be:

Exception thrown at 0x00007FFB0DA01530 (vcruntime140d.dll) in meh.exe: 0xC0000005: Access violation reading location 0x0000000000000000.

This is where the memcpy function is.

Your exact problem can be caused in a few ways, like putting large buffers on the stack or very deep recursion without tail call optimisation.

Also, if you really do need that amount of stack space then you should rebuild the application but increase the stack space.

This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.