Troubleshooting external error R6025 - pure virtual function call

Question

I have a VS2017 .NET program that has started to crash with this dialog message:

---

Microsoft Visual C++ Runtime Library

Runtime Error!

Program: [program.exe]

R6025
-pure virtual function call

---

This dialog box is spawned outside my program.

When I debug the program in VS2017, then after a while the dialog appears, but the program is still running as normal. Only after I click "OK", does my program stop. I get an invoke of AppDomain.CurrentDomain.ProcessExit, but there is no information about what caused the program to exit.

The Windows event log shows that one of the dlls involved is MSVCR110.dll:

Faulting application name: XXX.exe, version: 1.0.0.0, time stamp: 0x5c4aecde
Faulting module name: MSVCR110.dll, version: 11.0.51106.1, time stamp: 0x5098858e
Exception code: 0x40000015
Fault offset: 0x000a327c
Faulting process id: 0x128c
Faulting application start time: 0x01d4b6d3eed97aed
Faulting application path: C:\Users\dkrewind\AppData\Local\Apps\2.0\DBXO5LPH.PYZ\PTX522V3.2EO\insq..tion_1733f97596464edb_0001.0000_013e50ce80c4530d\XXX.exe
Faulting module path: C:\Windows\system32\MSVCR110.dll

How can I learn more about this error? Is it possible to find out where the illegal call is coming from that causes the crash? The program solution has several 3rd-party dlls as well as some C++-projects.

Answer 1

What you're seeing is a "default handler" for a virtual call.

In C++, a pure virtual function is defined like virtual void foo() = 0 . A class with a pure virtual function cannot be instantiated on its own, but it can be a base class. The derived class must override the pure virtual function.

Now in C++, during the construction of a derived class, the type of the object changes as the constructors run. The base class ctor runs first, and during this phase the type of the object is still the base type. This means you are not allowed to call the pure virtual function; the override from the derived class only becomes available when the derived ctor runs. This makes sense; the override may very well need members of the derived class that aren't initialized yet.

Visual C++ puts in a placeholder function for the pure virtual function. This is allowed by the Standard; calling a pure virtual function is Undefined Behavior so a dialog box is perfectly OK. You can at this point attach a debugger and inspect the call stack. That should tell you directly where the call is coming from.