none
<legacyCorruptedStateExceptionsPolicy enabled="true"/> not working in a COM+ context

    Question

  • Hi all,

    I want to employ <legacyCorruptedStateExceptionsPolicy enabled="true"/> (I know I shouldn't, please bear with me) for a COM+ application. To that end, I set-up the application root directory for COM+ and put application.config and application.manifest as explained e.g. here: http://vasters.com/clemensv/CommentView,guid,0615b3cc-0fbf-4cf5-9d49-ae95b50f7e8d.aspx

    In my "test harness" I provoke an access violation by dereferencing a bogus pointer in some C+/CLI code, which I try to catch in the managed part thereof. That didn't work.

    From same code, I took a look at the AppDomain::CurrentDomain->SetupInformation->ConfigurationFile and it is correct (c:\mycomplusapproot\Application.Config)

    Application code is a mix of VB.NET, C#, C++/CLI and C++ (orbiously, the crash is coming from the native part somewhere).

    Anyone has an idea as to what I could be missing?

    TIA,

    Goran.

    Thursday, January 09, 2014 9:01 AM

All replies

  • Hi Goran,

    I'm not familiar with what you're working on. But I check the MSDN document: <legacyCorruptedStateExceptionsPolicy> Element, and found that this configuration only works with application developed with managed code. Another way is to implement HandleProcessCorruptedStateExceptionsAttribute attribute in managed code.

    But yours is a COM+ application containing both managed and un-managed code. Probably that's the cause of this problem.


    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.


    Monday, January 13, 2014 5:45 AM
    Moderator
  • Hi,

    yes, I have a COM server in COM+ that is written in VB.NET. It uses some C++/CLI and that calls into native libraries.

    I managed to make things work by using dllhost.exe.config, but that is too coarse-grained - it will apply to all appdomain hosted by any dlllhost. (Obviously, this is a stop-gap until we get a correction for the crash).

    I would like to apply my attribute to a selected COM+ application(s), that didn't work, so i thought I'd ask if I missed something obvious.

    Goran.

    Tuesday, January 14, 2014 9:15 AM