none
Pure Virtual Function Error R6025 when running app without attached debugger RRS feed

  • Frage

  • Hello,

    i'm dealing with a weird issue since some hours already and running out if clues. I hope someone around here can help me out with that. Im using Visual Studio 2010 Ultimate SP1 with a C++ solution.

    The project is a Win32 app linking to DirectX (and some other libs, both static and dynamic). This app is running just fine on my development system. Now i tried it on other computers and there i received pure virtual function call runtime error R6025 within MSVCR100.dll. After some tryouts on some development VMs the issue is narrowing down to this: When i run the release executable with an attached debugger (F5) it works. When i run the very same release build without an attached debugger (CTRL+F5) then the error pops up. Debug build seem to not be affected at all.

    The error itself looks like this (sorry its german):

    Problemereignisname:    APPCRASH
    Anwendungsname:    app.exe
    Anwendungsversion:    0.0.0.0
    Anwendungszeitstempel:    4f132569
    Fehlermodulname:    MSVCR100.dll
    Fehlermodulversion:    10.0.30319.1
    Fehlermodulzeitstempel:    4ba1dbbe
    Ausnahmecode:    40000015
    Ausnahmeoffset:    0008d635
    Betriebsystemversion:    6.1.7600.2.0.0.256.1
    Gebietsschema-ID:    1031
    Zusatzinformation 1:    d837
    Zusatzinformation 2:    d837837651492bd6b59a8a750c75cf12
    Zusatzinformation 3:    4e70
    Zusatzinformation 4:    4e7073d1c13923ca88eaab31b089c020

     


    So this appears on release configurations only. On those machines where the error appears it also does so when launching the app from outside of Visual Studio. The error appears on dev and non-dev systems, on WinXp and Win7 (x86 and x64). Only on one system (my main dev win7 x64) it does work in every combination. I don't know why though.

    My first guess was a difference in the debug versions of the linked libs as it works for debug builds. Then again if that would be the case it should also not work when started with plain F5 on release config. I also just copied the debug config and changed the minimum set of properties to switch from debug to release - same result.

    On every development system it does work within Visual Studio when started with attached debugger using F5. As it does so i don't have any clue anymore what could be the reason as the project properties shouldn't be the issue here as it would cause the error showing up always. And in the end the build is the same as i immediately ran CTRL+F5 after F5.

     

    Does anyone have an idea what may be the problem here ? Any help would be highly appreciated.

     

    Thanks and best regards,
    Oliver

    Sonntag, 15. Januar 2012 22:31

Antworten

  • Hello Oliver!

    You are posting in a German forum.

    1. It seams that the memory layout is a little bit different when the debugger is loaded, so the error doesn't appear.
    2. Let the application crash. Attach the Debugger, look at the call stack?
    3. What happens if you launch the program and attach the debugger at runtime?
    4. You can do tis also with remote debugging.
    5. Try to create and analyze a crash dump.

    You must have code, that executes virtual function calls in a constructor in some cases... Try to review code where you can expect that this may happen.


    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de
    • Als Antwort markiert oliver_zx Montag, 16. Januar 2012 14:45
    Montag, 16. Januar 2012 07:25
    Moderator
  • Hi Martin,

    ja stimmt - der trace kam von einer Test VM. Da waren zu dem Zeitpunkt die Symbole nicht vorhanden. Aber ich hab den Fehler nun endlich gefunden. Es war das eine sprichwörtliche Bit...ein Bitset wurden nicht richtig initialisiert. Das führte dazu das beim Initialisieren eines Objektes in dessen Basisklasse die pure virtual Methode ausgeführt wurde die erst im Anschluss wirklich existiert.

    Trotzdem interessant, dass die Initialisierung hier so unterschiedlich sein kann. Auf meinem System arbeite ich seit bestimmt einem halben Jahr mit diesem bug und nie kam ein Fehler hoch. Auf anderen Rechnern kommt dieser ja, wie beschrieben, auch nur im Release Modus.

     

    Naja wie auch immer. Ich bin froh, dass die Suche nun endlich ein Ende hat.  Danke Dir Martin für die Anregungen.

     

    Viele Grüße,
    Oliver

    • Als Antwort markiert oliver_zx Montag, 16. Januar 2012 14:45
    Montag, 16. Januar 2012 14:44

Alle Antworten

  • Hello Oliver!

    You are posting in a German forum.

    1. It seams that the memory layout is a little bit different when the debugger is loaded, so the error doesn't appear.
    2. Let the application crash. Attach the Debugger, look at the call stack?
    3. What happens if you launch the program and attach the debugger at runtime?
    4. You can do tis also with remote debugging.
    5. Try to create and analyze a crash dump.

    You must have code, that executes virtual function calls in a constructor in some cases... Try to review code where you can expect that this may happen.


    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de
    • Als Antwort markiert oliver_zx Montag, 16. Januar 2012 14:45
    Montag, 16. Januar 2012 07:25
    Moderator
  • Hallo Martin,

    Danke für deine Antwort.

    Ich habe heute Morgen noch ein wenig weiter gesucht. Es scheint etwas mit meiner Hierarchie von multiple sowie virtual inheritance zu tun zu haben.

    Allerdings versteh ich im Moment noch nicht warum. Es gibt auch noch dieses Verhalten: Ich habe zwei Klassen  A und B. Bei der Instanziierung auf dem Heap kommt es ebenfalls zu dem Fehler, wenn ich versuche beide direkt nacheinander zu Instanziieren. Wenn ich nur eine der beiden Instanziiere funktioniert es. Das und der Umstand, dass es auf meinem Dev System alles funktioniert verwundert mich.

    Zu Deinen Punkten:

    2. Stacktrace:

    msvcr100.dll!_crt_debugger_hook(int _Reserved=1)  Line 65	C
    msvcr100.dll!_call_reportfault(int nDbgHookCode=3, unsigned long dwExceptionCode=1073741845, unsigned long dwExceptionFlags=1)  Line 167 + 0x6 bytes	C++
    msvcr100.dll!abort()  Line 83 + 0xe bytes	C
    app.exe!0133f0d6() 	
     [Frames below may be incorrect and/or missing, no symbols loaded for SparkDemo.exe]	
     app.exe!0133f368() 	
     app.exe!0130ca1d() 	
     app.exe!01342fb0() 	
     app.exe!01345d78() 	


    3. Das Ergebnis ist das gleiche. Der Fehler tritt auch dann noch auf.

     

    Viele Grüße,
    Oliver

    Montag, 16. Januar 2012 13:37
  • Warum hast Du keine Debug-Symbole erzeugt?

    Dann kannst Du "richtig" Debuggen auch im Release Projekt!


    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de
    Montag, 16. Januar 2012 13:53
    Moderator
  • Hi Martin,

    ja stimmt - der trace kam von einer Test VM. Da waren zu dem Zeitpunkt die Symbole nicht vorhanden. Aber ich hab den Fehler nun endlich gefunden. Es war das eine sprichwörtliche Bit...ein Bitset wurden nicht richtig initialisiert. Das führte dazu das beim Initialisieren eines Objektes in dessen Basisklasse die pure virtual Methode ausgeführt wurde die erst im Anschluss wirklich existiert.

    Trotzdem interessant, dass die Initialisierung hier so unterschiedlich sein kann. Auf meinem System arbeite ich seit bestimmt einem halben Jahr mit diesem bug und nie kam ein Fehler hoch. Auf anderen Rechnern kommt dieser ja, wie beschrieben, auch nur im Release Modus.

     

    Naja wie auch immer. Ich bin froh, dass die Suche nun endlich ein Ende hat.  Danke Dir Martin für die Anregungen.

     

    Viele Grüße,
    Oliver

    • Als Antwort markiert oliver_zx Montag, 16. Januar 2012 14:45
    Montag, 16. Januar 2012 14:44