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();

}

}

}

Answer 1

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

Answer 2

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.

Answer 3

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

Answer 4

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.

Answer 5

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.