Exe allg. - Welche Funktion wird immer vorm Absturz aufgerufen?



  • Gibt es eine Stelle in einer MFC-Anwendung, die vor einem Absturz immer noch aufgerufen wird? Ich will da was reinschreiben, was unbedingt noch gemacht werden muss.



  • 🤡 SCHMUNZEL 🤡

    ein absturz ist meist ein zugriff auf einen falschen speicherbereich und TERMINIERT das programm nicht gerade sanft
    wenn es sowas (ich habe mich auch schonmal geirrt) geben sollte will ichs sofort wissen 😃

    was soll denn da rein?
    vielleicht gibts ne andere loesung...

    Gruss
    Guenni



  • [Ironie] OnTerminate() -> WM_WENNSMALWIEDERDANEBENGEHT [/Ironie] 😃

    Wenns was gibt -> *auchwissenwill*

    Glaube ich aber ehrlich gesagt nicht so ganz....

    *winke*
    Hellsgore



  • Nicht MFC, sondern API: SetUnhandledExceptionFilter.

    LONG WINAPI MyFilter(EXCEPTION_POINTERS*)
    {
        MessageBox(NULL, TEXT("Kuckuck"), NULL, MB_OK);
        return(EXCEPTION_CONTINUE_SEARCH);
    }
    
    void Boese(void)
    {
        *(int*)NULL = 0x1234;
    }
    
    int WINAPI _tWinMain(HINSTANCE, HINSTANCE, LPTSTR, int)
    {
        SetUnhandledExceptionFilter(MyFilter);
        Boese();
        return(0);
    }
    

    Das funktioniert aber nur ohne Debugger. Du solltest Dir aber trotzdem überlegen, die Exception dort zu fangen, wo sie auftritt.



  • Hier noch ein interessanter Link dazu:

    http://www.codeproject.com/debug/XCrashReportPt1.asp

    *Introduction
    One of the biggest challenges for a developer is to debug a program that has been put into production or shipped to a customer. On the developer's workstation, the program works fine. But on the customer's system, there are random crashes. There is often no direct access to the customer's system, because of distance. Writing to the event log or other log file may be helpful, but can only point in a direction, not give a precise location.

    This was the state I was in when I read Bruce Dawson's paper on Release Mode Debugging. Dawson's paper discusses several techniques that I had never encountered before, including how to capture the instruction pointer (ip) of a crash, and how to plug the ip into VC++ and go directly to the source line of the crash. (I am talking about VC++ 6.0 here, not .Net).

    These new techniques led me toward the holy grail of developers: being able to see a stack trace of each function that led up to the crash. At several points along the way, I thought to myself, "Well, this is pretty complete, there's nothing more to add." But then I would see there was another approach, another API I had overlooked, and I kept on.*

    ... mehr auf der Seite


Anmelden zum Antworten