Re: Tool for troubleshooting R6025 error in VC++

It would probably help for those of us who don't bother to memorize message numbers if you
actually said what this error is. But I looked it up. Note that if you accidentally
overwrite memory, you can clobber a vtable pointer, which will then give the effect of
quite possibly give this error.

Since the storage allocation done in release mode is different than that of debug mode, it
is possible that the memory clobber (first guess: a buffer overrun) is harmless in debug
mode, but damaging in release mode. Therefore, it is entirely possible that you cannot
replicate it in debug mode.

I'd suggest, just as a start, in the OnIdle handler, trying this:

if(_heapchk() != HEAP_OK)
DebugBreak();

(check the docs to see if I remembered the HEAP_ symbol name correctly...)

This is a first-cut attempt to look for heap damage. It may or may not reveal anything,
but if it does, it will pin down the problem to some particular action, which will help
track the source of the damage.

Under the conditions you are describing, I always assume that memory damage is the
culprit. Unfortunately, memory damage bugs are notoriously difficult to find.
joe

On 12 Jan 2006 22:07:59 -0800, "madhavi" <lmadhavi@xxxxxxxxx> wrote:

>Hi,
>
>Thanks for your reply..
>
>This crash occurs only in release mode. It does not occur If I set the
>bebug information(i.e Link->GenerateDebugInfo settings ) in release
>mode. Moreover this does not reproduce in release mode always..It comes
>up some times only..i.e I don't have the steps for repeating this
>error. Hence I don't think it is problem with virtual function call. If
>it was a problem with virtual function call, I should be able to
>reproduce this error always in both debug and release builds ..right?
>Is there any other reason for this error message? Do my Link options of
>Project settings have any impact on this error? My link options are:
>CTS32D.LIB RTS32D.LIB TAPI32.LIB VERSION.LIB WINMM.LIB VFW32.LIB..
>
>Please let me know if you have further inputs on this as I am not
>getting any clue for resolving this issue..
>
>Thanks..
>Madhavi..
>
>
>Oleg Starodumov wrote:
>> > I am woking on VC++ project. When I run the project in Release mode, I
>> > am getting R6025 Runtime error message. The project has hundreds of
>> > virtual functions not written by me and I have no clue as to find out
>> > from where this message box is coming? If I run in debug mode, I am not
>> > getting this error message box. If I try to debug in release mode, I am
>> > still not getting this error message.
>> > I refered this link on MSDN for resolution methods:
>> > http://support.microsoft.com/default.aspx?scid=kb;en-us;125749, but
>> > both the resolution methods work only in debug mode and hence I'm
>> > unable to use them to identify the root cause for this problem as I get
>> > this runtime error only in release mode.
>> >
>> > Can anyone please guide me as to how to trace out the cause for this
>> > problem? Can I use any tool available on the net for capturing this?
>> >
>>
>> The first method (with DebugBreak) should work when running without debugger.
>> Make sure that the application is built with debug information, and that Visual Studio
>> is registered as the just-in-time debugger (Tools | Options | Debugging | Just-in-time | Native
>> for VS2003) (this is also required for another approach described below).
>> When the hard-coded breakpoint is hit, the operating system will start Visual Studio
>> debugger and attach it to your application.
>>
>> A simpler way is to set your own handler for pure virtual calls and DebugBreak from it.
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_set_purecall_handler.asp
>> (AFAIR it is not supported in VC6)
>>
>> Another way is to attach the debugger to the application while it shows the error message.
>>
>> In any case, after you managed to attach debugger to the application, take a look at the call stack
>> to see who is calling the pure virtual function. For better results, consider turning off optimizations
>> in release build - it will give you better call stacks (if the problem is reproducible with
>> optimizations disabled).
>>
>> Regards,
>> Oleg
>> [VC++ MVP http://www.debuginfo.com/]
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Setting objects to Nothing uses less memory!
    ... > in debug mode. ... Are you actually running the unit tests under a debugger? ... but whether it's executing under a debugger or not. ... your code is debug code but running without a debugger attached, ...
    (microsoft.public.dotnet.framework.performance)
  • Re: F5 stopped attaching the debugger automatically
    ... nospam@xxxxxxxxxx (John Dalberg) wrote: ... Suddenly I lost the ability to automatically have the debugger attached ... restore the ability to run in debug mode as I always had been. ...
    (microsoft.public.vstudio.general)
  • Re: F5 stopped attaching the debugger automatically
    ... nospam@xxxxxxxxxx (John Dalberg) wrote: ... Suddenly I lost the ability to automatically have the debugger attached ... automatically when I run in debug mode. ...
    (microsoft.public.vstudio.general)
  • Re: MyProg.exe still appears as a process even after it terminates.
    ... > this is how the problem manifests itself, in Debug mode I have both this ... I have to manually stop the debugger, ... > hope I eliminated all memory leaks). ... It used to be a relatively straightforward SDI app. ...
    (microsoft.public.vc.mfc)
  • MyProg.exe still appears as a process even after it terminates.
    ... I have to manually stop the debugger, ... Additionally, and I am sure they are related, while in debug mode I used to ... hope I eliminated all memory leaks). ... It used to be a relatively straightforward SDI app. ...
    (microsoft.public.vc.language)
Loading