none
Order of unhandled exception filters in mixed managed/unmanaged environment RRS feed

  • Question

  • Hi.

    We have a mixed managed/unmanaged app that registers both native unhandled exception handler via SetUnhandledExceptionFilter() and managed unhandled exception event via AppDomain.CurrentDomain.UnhandledException.

    I was astonished to find out that the order in which these two are called depends on whether I am in the main thread or not. In the main thread native handler is called first, followed by the CLR handler (which is very weird). In all other threads the order is reversed.

    I built a number of sample apps (see http://www.ikriv.com/dev/dotnet/Mixed.Exceptions.zip) and this behavior is consistent across all scenarios. See http://www.ikriv.com/blog/?p=1440 for a long explanation of all scenarios.

    This does not look like a random bug - the behavior is too consistent. The decision which handlers to call seems to be inside CLRUEFManager class in mscoree.dll, but its source code is not available. I don't think this behavior is documented anywhere. If someone in the know could shed light on why it works the way it works, I would be very grateful.


    • Edited by ikriv Monday, August 25, 2014 7:36 PM
    Monday, August 25, 2014 7:35 PM

All replies

  • Hello ikriv,

    After some research online, I found some articles which describes the mechanism of CLR and Win32 unhandled exception filters interoperate. Although they seems haven't directly tell us the reason of your issue, I think they may help us in the right direction.

    First please check this blog: The good and the bad of exception filters and see

    "Why does the CLR use a two-pass exception handling model?

    The CLR implements a two-pass exception handling system in order to better interoperate with unmanaged exception handling systems, like Win32 Structured Exception Handling (SEH) or C++ Exception Handling.We must run finally (and fault) clauses on the second pass so they run in order with unmanaged equivalents. Likewise, we must not execute filters later (say, on the second pass) because one of those unmanaged systems may have remembered that it was supposed to be responsible for handling the exception. If we were to run a filter late on the second pass and decide that a managed clause really should catch the exception after previously having not declared that on the first pass, then we would violate our contract with those unmanaged mechanisms with unpredictable results. "

    Then here: CLR and Unhandled Exception Filters

    "From looking at the SSCLI implementation and running a couple of tests I was able to conclude the following:

      • The CLR relies on the SEH unhandled exception filter mechanism to catch unhandled exceptions.
      • The CLR’s exception filter does the following:
      • Invokes the previous exception filter in the chain;
      • Invokes the delegates registered to AppDomain.UnhandledException in the AppDomain;
      • Migrates the thread to the default AppDomain and again invokes delegates registered to AppDomain.UnhandledException.

    So if you install your own unhandled exception filter, there are two options:

    • The CLR has installed its exception filter before you have installed your exception filter.  In this case, the CLR will invoke your exception filter before performing its own exception processing (because it’s a good citizen of Win32);
    • The CLR has installed its exception filter after you have installed your exception filter.  In this case, you should invoke the CLR’s exception filter before performing your processing (because you are a good citizen of Win32)."

    To make our application reliably I would recommend you follow the second blog to handle the exceptions.

    By the way, here is the place where I get to know the second blog, which seems also can be a reference link:http://stackoverflow.com/questions/8704/final-managed-exception-handler-in-a-mixed-native-managed-executable

    Best regards,



    Barry
    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, August 26, 2014 2:43 AM
  • Barry, thank you for the links.

    • The CLR relies on the SEH unhandled exception filter mechanism to catch unhandled exceptions.
    • The CLR’s exception filter does the following:
    • Invokes the previous exception filter in the chain;
    • Invokes the delegates registered to AppDomain.UnhandledException in the AppDomain;

    It's a problem, right there - this description fits only the main thread. On worker threads the CLR first invokes AppDomain.UnhandledException and then invokes previous filter in the chain.

    Tuesday, August 26, 2014 3:33 AM
  • Hello ikriv,

    For this issue, I am try to involve someone experienced to help look into it, as soon as we get any result, we would tell you.

    Thanks for your understanding.

    Fred.


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Wednesday, August 27, 2014 6:37 AM
    Moderator