none
InvalidProgramException when exiting application RRS feed

  • General discussion

  • I have an application that is written in VS2008 with .Net Framework 3.5 service pack 1 installed.  When I exit this application, I get an InvalidProgramException unhandled error.  The exit of the app is done when the user clicks the "Exit" menu item and consists of two lines of code:

    private

     

    void exitToolStripMenuItem_Click(object sender, EventArgs e)
    {
        this.Close();
        Application.Exit();
    }

    The error is thrown sometime after Application.Exit() is executed.  I can compile the app correctly, everything seems to be fine, I have run PEVerify against the assembly and everything comes back fine.  This only happens when exiting the application and generates an ugly "Windows has shut this application down" error when the user exits the app.  I have tried everything to figure out why this is happening.  I can attach to the running process in the debugger, and see the error and it says that the Common Language runtime encountered an unhandled InvalidProgramException when exiting.  What is odd is that if I run the app in the debugger, and exit it that way, I don't get the error, only when running it outside the debugger (as a normal user would).  I have tried compiling it in Debug, Release, etc. and it doesn't make a difference.

    I have searched many blog posts that say that this is invalid IL that is being generated by the compiler so I am hoping that this is the right place to post this problem. 

    Any suggestions would be greatly appreciated.

    Allen

    Thursday, October 15, 2009 10:07 PM

All replies

  • What exactly is on the call stack of this exception (if you can get it via debugger attach right before exit)? Any chance it is comming from some finalizer?
    If that doesn't help, I'd try to minimize the app by removing parts of it and see when it starts to work.

    Bad IL is mostly the reason for InvalidProgramException, but I can easily imagine that also other stuff could cause this ... Especially if your app passes peverify and you do not emit code on the fly.

    -Karel

    Thursday, October 15, 2009 10:59 PM
    Moderator
  • Thank you very much for your reply.  I can attach to the application while it is running and then click the Exit button.  When the error is thrown, it doesn't give me an option to see the Call Stack or anything, it just pops up.  I can catch it by creating a domain level error handler.  If I don't have that enabled, it doesn't throw the error in a specific place, it just pops up.  I'm not emitting any code in my app.  It has me stumped.  I can't tell if it is in a finalizer, but I am guessing that it is if it is happening during application exit.  Is there anything to look for if that is the case?

    Allen

    Thursday, October 15, 2009 11:48 PM
  • Ouch, this is not a pleasant one.  Exit time is always a difficult stage in a process' life time.  That's when things get torn down, memory released, resources disposed.  Mishaps during program execution can go undetected for a long time, but they tend to byte during the exit stage.  The classic failure mode is having unmanaged code corrupting the heap, scribbling a byte in the wrong place at the wrong time.  Which is about the only explanation for the exception you are getting, it indicates that an assembly is containing corrupt data.  You already checked that it doesn't, only an unexpected change afterwards makes sense.

    This is going to be hard to diagnose.  The best approach is to suspect any kind of unmanaged code your program might be using (COM servers, database drivers, that sort of thing) and unit-test the heck out of it and look for updates and ask for help from the vendor.  Good luck.

    Hans Passant.
    Friday, October 16, 2009 12:16 AM
    Moderator
  • If you are able to attach (native) debugger to your app, then click Exit and reproduce the problem, then you can as well set your debugger to stop on all second-chance and first-chance (native) exceptions. Check them out from the last one (that should be the InvalidProgramException). If that doesn't help, follow Hans's advice ...

    -Karel

    Friday, October 16, 2009 12:21 AM
    Moderator
  • Ugh! :)  Thanks for your help, though. 
    Friday, October 16, 2009 12:25 AM
  • Thank you for your assistance.  I will keep plugging away at it until we figure something out.
    Friday, October 16, 2009 12:25 AM
  • BTW: If you can share your application publicly (ideally with sources, or at least part of your application which is failing), I would like to try to create a case study on it 'How-to-debug-this-type-of-failures'. Sure, if it is something you cannot share, I'm out of luck ...

    -Karel
    Friday, October 16, 2009 12:28 AM
    Moderator
  • Hello Allen

    As Karel said, call stack can usually reveal a lot of useful information for diagnosing crashes. To see the call-stack, please follow these steps:

    1. Download and install windbg from http://www.microsoft.com/whdc/devtools/debugging/installx86.Mspx
    2. Configure windows symbols and your application symbols.
    http://www.microsoft.com/whdc/DevTools/Debugging/debugstart.mspx
    3. Attach windbg to your running application.
    4. Exit your application, which should triggers an unhandled event and breaks windbg.
    5. In windbg, run the command "kvn" to see the raw native call stack. You can also consider running the !analyze -v command to print all verbose information about the crash.
    6. load sos by running the command ".loadby sos mscorwks"
    7. dump the managed call stack: !clrstack

    Please post the results from windbg here.

    Thanks
    Jialiang Ge
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Friday, October 16, 2009 7:44 AM
    Moderator
  • Hello Allen

    How are you. Do you get any progress in this issue? Could you please update us about your findings?

    Thanks
    Jialiang Ge
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Friday, October 23, 2009 6:28 AM
    Moderator
  • We are changing the issue type to “General Discussion” because you have not followed up with the necessary information. If you have more time to look at the issue and provide more information, please feel free to change the issue type back to "Question” by opening the Options list at the top of the post window, and changing the type. If the issue is resolved, we will appreciate it if you can share the solution so that the answer can be found and used by other community members having similar questions.
    Regards,
    Jialiang Ge
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, November 2, 2009 10:44 AM
    Moderator