R6025 Pure virtual function call

It's certainly not the first case since it does not happen in all PCs.

However I am guessing that one of the  DLL is causing this issue. I tried sending the customer DEBUG and RELEASE version and
the DEBUG worked without any errors. I looked ath the list of DLLS loaded by the DEBUG and RELEASE and found that the difference is in DEBUG
MSVCRTD.DLL, MFC42D.DLL, MFC042D.DLL and MFCD42D.DLL was loaded
and in RELEASE
MSVCRT.DLL and MFC42.DLL.

I looked at the version number for MSVCRT.DLL and MFC42.DLL and they seem to match with what I have in my PC. In my PC the program works without any errors.


Any further thoughts on this issue?

Yep, it sure looks like you got caught in DLL hell here.

The DLLs also load many DLLs, and so it could be a call in MFC that just doesn't work.  MSVCRT depends on Kernel32.dll, and MFC42.dll depends on GDI32.DLL and User32.dll.  All these are updated by service packs, but that shouldn't (and shouldn't is such a relative word when talking about windows) affect MFC.

Keep in mind, debug may work just because the variables are all pre-initialized, not just because of the DLLs being used.  If you have an idea what section of code is causing the problem, make sure all pointers that get tested for equivalence to NULL are really set to NULL in the constructor.

This error occurs when your application indirectly calls a pure virtual member function in a context where a call to the function is not valid. In most cases, the compiler detects this and reports the error when building the application. But depending on how your code is written, sometimes the problem is detected only at run-time. Calling a pure virtual function is a programming error, so you need to find the call to the pure virtual function and rewrite the code so it is not called.

One way to find a call to a pure virtual function is to replace the pure virtual function with an implementation that calls the Windows API function DebugBreak(). When using the debugger, DebugBreak() will cause a hard-coded breakpoint. When the code stops running at this breakpoint, you can view the callstack to see where the function was called.

While I agree that it is a programming error, I don't think this is as simple as finding the virtual function being called.  The error gets thrown whenever a function pointer is NULL, which, 99% of the time is a pure virtual function call.  But in this case vsaravana says no virtual functions are in the code.

Since MFC has no pure virtual functions, that means one of three things are happening.  Either a message macro is defined with a NULL message handler (which would be obvious and almost certainly cause a compiler error), a bad typecast is being made because of an error condition (an API that should return a function pointer is instead returning a NULL and no error checking was done to catch that, or a request for a particular COM interface returned an IUnknown) or the API is being asked to call a NULL function (providing a NULL callback to a function that must have a valid callback, like EnumDisplayMonitors).

Since it is only happening on one machine, it is most likely a different or missing dll that is causing the second problem.  The real solution is to find the place where the error is being missed, but it would be easier to find that if you know what call is causing the problem in the first place.  Especially in a large project.

Like I said before the issue appears only in Windows 2000 Citrix server. So I doubt un-intialized variables to
be an issue. Moreover I checked on the section of code where this is happening and it's straight forward.
I don't see any code to be concerned about.

Since you say it is straightforward, I assume the code is not part of the programming accessing the Citrix server.

Is the code using the toolbar or other common controls?  If so, check the version of IE.  MFC is very dependant on certain kinds of toolbar and rich-edit behaviors and older versions of the common control dll can cause ordinary calls in MFC to fail in very odd ways.

There is no code acessing the citrix server. Just as an FYI, we have an citrix server in-house and don't see this issue happening.

The error occurs when the user closes the application. The runtime error appears with only a cancel button and the user need not do anything and the message box goes away after staying for 2-4seconds.
At the stage when application comes down, destructor is called in mainframe/view/document classes. There are no specific call made for the toolbar but the toolbar object is destroyed.


Saravana

Since destructors are virtual and the Mainframe destructor calls the destructors for all its member variables, this is probably a good place to look.  If the user can, have them try starting and shutting down the program without opening the document.  If that still causes the problem, most likely it is the toolbar.

If a document always opens by default you may not be able to test this, but you can still check the version of IE on the machine.