none
HandleProcessCorruptedStateExceptions doesn't seem to work

    Question

  • Hello, I'm trying to isolate my application from third party components that may, (unfortunately), cause access violations. So I'm running these components in a console app. If an access voilation occurs I just want to log this and silently exit. I.e. avoid the windows 'Application has stopped working' dialog. I'm using the HandleProcessCorruptedStateExceptions attribute but I still get this dialog. The code is below. Any ideas why this doesn't work? (A working sample of how to accomplish this would be even better). The application below simply causes an access voilation. I've given the manifest 'highest available' execution rights but nothing seems to have my exception handlers fire and avoid the System error dialog. Thanks in advance

    namespace

     

    ConsoleApplication1

    {

     

    class

    Program

    {

    [

    HandleProcessCorruptedStateExceptions

    ]

    [

    SecurityCritical

    ]

     

    static void Main(string

    [] args)

    {

     

    AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler

    (CurrentDomain_UnhandledException);

     

    AppDomain.CurrentDomain.FirstChanceException += new EventHandler<FirstChanceExceptionEventArgs

    >(CurrentDomain_FirstChanceException);

     

     

    try

    {

    CrashIt();

    }

     

    catch (Exception

    ex)

    {

     

    Console.WriteLine("Exception"

    );

    }

    }

    [

    HandleProcessCorruptedStateExceptions

    ]

    [

    SecurityCritical

    ]

     

    static void CurrentDomain_FirstChanceException(object sender, FirstChanceExceptionEventArgs

    e)

    {

     

    Console.WriteLine("Exception"

    );

     

    Console

    .ReadLine();

    }

    [

    HandleProcessCorruptedStateExceptions

    ]

    [

    SecurityCritical

    ]

     

    static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs

    e)

    {

     

    Console.WriteLine("Exception"

    );

     

    Console

    .ReadLine();

    }

     

    unsafe static void

    CrashIt()

    {

     

    var obj = new byte

    [1];

     

    var pin = GCHandle.Alloc(obj, GCHandleType

    .Pinned);

     

    byte* p = (byte

    *)pin.AddrOfPinnedObject();

     

    for (int

    ix = 0; ix < 256; ++ix) *p-- = 0;

     

    GC

    .Collect();

    }

    }

    }

    Wednesday, March 23, 2011 4:14 PM

Answers

  • Hi Henry,

    Such error indicates either a CLR defect or a heap corruption, the process will be terminated immediately, it doesn’t make any sense to catch this exception;

    In this case, it is a heap corruption, and we should do a live debugging or capture a dump for further investigation.

    You can use WinDbg + SOS to debug such issue. Use ADPlus to capture a dump file. MDA is a useful tool to detect such error.

     

    ADPlus is shipped with Debugging Tools For Windows which available at here, you can try this command to capture a dump file:

     

    adplus -crash -o d:\dumps -pn MyApplication


    Paul Zhou [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by Paul Zhou Monday, April 04, 2011 2:05 AM
    Friday, April 01, 2011 3:03 AM
  • Hi Oleksander,

     

    Yes, I know OP wants to avoid crashing the process with an error dialog popup.

    But such kind of exception is an exception induced a fatal destroy to GC heap so that CLR cannot work well (or speak: CLR itself is broken). So CLR cannot catch an exception when CLR itself is broken.

    So I suggested debugging this issue to find root cause to avoid the exception instead of finding a way to catch the exception.


    Paul Zhou [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Sunday, April 03, 2011 6:40 AM

All replies

  • subscribe to  AppDomain.CurrentDomain.UnhandledException in main function and then close the Process silently. 

     

    Process.GetCurrentProcess().Kill(); - for example

     

    In addition, return some int ID to calling code.

     

    Sorry, didn't see that in your code as it splitted thrugh the lines :)



    Don't forget to mark the correct answer
    Thursday, March 24, 2011 11:04 AM
  • Hi Henry,

    Such error indicates either a CLR defect or a heap corruption, the process will be terminated immediately, it doesn’t make any sense to catch this exception;

    In this case, it is a heap corruption, and we should do a live debugging or capture a dump for further investigation.

    You can use WinDbg + SOS to debug such issue. Use ADPlus to capture a dump file. MDA is a useful tool to detect such error.

     

    ADPlus is shipped with Debugging Tools For Windows which available at here, you can try this command to capture a dump file:

     

    adplus -crash -o d:\dumps -pn MyApplication


    Paul Zhou [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by Paul Zhou Monday, April 04, 2011 2:05 AM
    Friday, April 01, 2011 3:03 AM
  • Hi Paul, but topic starter does not want to save the dump, he uses 3-rd part lib and wants to be sure that if exe that he is using in a separate process does not bother user if it crashes.
    Don't forget to mark the correct answer Blog
    Friday, April 01, 2011 9:35 PM
  • Hi Oleksander,

     

    Yes, I know OP wants to avoid crashing the process with an error dialog popup.

    But such kind of exception is an exception induced a fatal destroy to GC heap so that CLR cannot work well (or speak: CLR itself is broken). So CLR cannot catch an exception when CLR itself is broken.

    So I suggested debugging this issue to find root cause to avoid the exception instead of finding a way to catch the exception.


    Paul Zhou [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Sunday, April 03, 2011 6:40 AM
  • Thanks Paul,

    You're correct, the example I used to crash the app isn't good. What I should have supplied is something unrelated to a CLR crash. When I used:

     

    public unsafe void AccessViolation()

    {

     

    byte b = *(byte

    *)(8762765876);

    }

    My exception handler caught the access violation. My application uses some legacy COM components that occassionally causes "C000005" style access violations and it these I need to catch.

    Thursday, April 14, 2011 3:15 PM