4

Background information: Our application uses a componenent written by an external vendor. That component sometimes crashes with the C++ runtime error "Pure virtual function called" dialog. We have the application deployed on a LCD display and we would like the crash to simply crash, as we have a process in place to restart the application if it crashes.

We identified the source of the problem to be in the vendor supplied component, which we cannot modify since we do not have the source. We could wait for a vendor supplied solution if we were able to automatically restart application upon the crash. The problem is that the application does not crash before the user click on the OK button of the error so we cannot detect that the process stopped running.

I built a small test application, a vanilla Win32 GUI application to which I added the following code:

class A
{
    public:
        A();

    protected:
        virtual void  myTest() = 0;

        void zubzub();
};

class B : public A
{
    protected:
        virtual void  myTest();
};

A::A()
{
    zubzub();
}

void B::myTest()
{
}

void A::zubzub()
{
    this->myTest();
}

I then created an instance of A after the window pops up in the VS generated win32 application template and voilà! I have the modal dialog. I tried the solution here but it still displayed the error dialog.

Any clue on how to suppress that dialog and crash silently

Community
  • 1
  • 1
Vincent Hubert
  • 1,386
  • 9
  • 23
  • 1
    A slightly better approach would be not to call a pure virtual function before construction completes or after destruction started... – David Rodríguez - dribeas Apr 17 '14 at 21:18
  • Just do not call virtual functions in a constructor (directly or indirectly), unless you know what will happen. –  Apr 17 '14 at 21:18
  • 1
    Your only real solution is to tackle the real problem. Don't bury your head in the sand. – David Heffernan Apr 17 '14 at 21:21
  • (Edited) I guess I was not clear enough... The problem is that we do not have the source to the faulty component. I just gave sample code to showcase how to reproduce the issue, in case someone wanted to reproduce it. – Vincent Hubert Apr 17 '14 at 21:24
  • 1
    Get the vendor to fix their code – David Heffernan Apr 17 '14 at 21:26
  • 2
    @DavidHeffernan don't you think if that were possible the questioner couldn't have come up with that on their own? And even if they fix this bug, what about the one they haven't discovered yet? – Mark Ransom Apr 17 '14 at 21:33
  • @mark not necessarily no – David Heffernan Apr 17 '14 at 21:37
  • Does this library use the same instance of the runtime as your code? – David Heffernan Apr 17 '14 at 21:37
  • Our code is a Winforms .Net application, their library is an OCX com component, which would be written in C++, given the error message. – Vincent Hubert Apr 17 '14 at 21:40
  • 1
    @VincentHubert: The code that is doing the pure virtual call is **broken**, and you need to get the owner of that component to fix it. If you have the sources fix it yourself, if you don't get the vendor to fix it. A different issue is if you are destroying the object and then attempting to use it (which would be a bug in your code, which again needs to be fixed) – David Rodríguez - dribeas Apr 17 '14 at 22:00
  • I am looking for painkillers, not for a cure. The cure is obvious, get the vendor to fix their code. But currently, we cannot reproduce the issue systematically, they cannot reproduce the issue at all. The fix will most likely be provided in their next release cycle, it will need to be QA'd on the vendor side, on ours, we will need to send someone on site to install the fix... Meanwhile, our client suffers and we, as their vendor, are responsible for their suffering. We want to ease that. – Vincent Hubert Apr 22 '14 at 12:57

2 Answers2

2

Perhaps rather than detecting the crash directly, you can detect that there is a dialog in front of your application and end the application yourself. As long as the message pump is operational (which it would be while displaying a message box) you can have a timer callback use GetActiveWindow and verify that the returned window handle is one of yours.

Mark Ransom
  • 299,747
  • 42
  • 398
  • 622
  • Interesting solution... Given the fact our application is written in .Net, and that it pops windows by itself, we would need to register the windows handle with the timer every time we pop a window. And I think the OCX component pops windows of its own. Hopefully I will get something simpler than that – Vincent Hubert Apr 17 '14 at 21:45
1

Use the _set_purecall_handler function in your main application. It affects all the dlls loaded (directly or indirectly) by your application. MSDN says it should be callable via P/Invoke; this question addresses some possible issues. (Basically, the problem is that you have to do this for a specific CRT version.)

Community
  • 1
  • 1
Eric Brown
  • 13,774
  • 7
  • 30
  • 71