ASP.NET and managed C++: Access violation when AppDomain is unloaded.

Discussion in 'ASP .Net' started by F. Prefect, Oct 6, 2004.

  1. F. Prefect

    F. Prefect Guest

    Hello,

    (sorry for reposting this.)

    We are having the following scenario:

    A ASP.NET Application (C#) is using a managed C++ assembly, which is a
    thin wrapper around an old C++ lib.
    (We are using .NET framework 1.1)

    In the managed C++ assembly there are some managed (gc) and some
    unmanaged (nogc) classes. There is one unmanaged class (a singleton),
    which has a reference (gcroot/GCHandle) to a System.Collections.Hashtable.

    So the callgraph is something like this: .NET --> C++ --> .NET

    Everything works fine, until ASP.NET decides to unload and reload the
    AppDomain. (e.g. touching the web.config/machine.config).
    If now a call is made to the component, it crashes at the point, where
    the referenced Hashtable (GCHandle) is used.

    I saw a few articles about this problem, including a bug report in msdn
    (http://support.microsoft.com/default.aspx?scid=kb;EN-US;309694).
    The bug report applies to .NET framework 1.0, so I'm wondering, if this
    bug still exists in 1.1?

    Is this a known bug in 1.1 too? Will the next version of the framework
    fix this?
    Are there any other workarounds beside the solutions in 309694.

    Thanks in advance,

    Hans-Jürgen.
     
    F. Prefect, Oct 6, 2004
    #1
    1. Advertising

  2. Hi Hans,

    As for the problem you mentioned, do you means that currently if we call
    that MC++ component after the asp.net appdomain unload and reload, the
    application will crash?

    As for the kb article you mentioned, I'll consult some further experts to
    confirm this and I think we can do some further tests currrently:

    Try creating another simple MC++ assemlby( reference a unamaged dll, but
    don't be too complex) and use it in the asp.net web application and do the
    same test to see whether the problem reoccur. That'll help confirm whehter
    the problem is only specified to the particular Mc++ component.

    I'll update you about the kb article's info as soon as possible, and if you
    have any other findings , please also feel free to post here. Thanks.

    Regards,

    Steven Cheng
    Microsoft Online Support

    Get Secure! www.microsoft.com/security
    (This posting is provided "AS IS", with no warranties, and confers no
    rights.)
     
    Steven Cheng[MSFT], Oct 6, 2004
    #2
    1. Advertising

  3. F. Prefect

    F. Prefect Guest

    Hello,
    I can reproduce the error in a simple example.

    I think the problem is, that the singleton (static variable) in the
    managed c++ assembly is not notified of the AppDomain unloading.
    So it creates a reference (gcroot) to a managed object in the first
    AppDomain and after unloading the AppDomain the reference is invalid.
    (->crash).

    By the way, there is another question concerning managed c++ Dlls.
    The documentation recommends not to implement a Dll-Entry point.
    Having static instances of unmanaged classes requires to call
    the CRT-initialization. The recommended way is to call
    __crt_dll_initialize and __crt_dll_terminate at initialization time (but
    not from within Dll-Entry point).

    How should I do this in an ASP.NET environment. The methods
    Application_Start/Application_End (global.asax) are called more then
    once. Every time I touch web.config/machine.config these methods are
    called. But the managec c++ dll is loaded just once.
    Is it allowed to call __crt_dll_initialize and __crt_dll_terminate more
    than once?

    What is the recommended point in ASP.NET application to initialize
    managed c++ Dlls?

    The article I read:
    http://support.microsoft.com/default.aspx?scid=kb;[LN];814472&product=vcNET

    Thanks in advance,
    Hans-Jürgen.


    Steven Cheng[MSFT] wrote:
    > Hi Hans,
    >
    > As for the problem you mentioned, do you means that currently if we call
    > that MC++ component after the asp.net appdomain unload and reload, the
    > application will crash?
    >
    > As for the kb article you mentioned, I'll consult some further experts to
    > confirm this and I think we can do some further tests currrently:
    >
    > Try creating another simple MC++ assemlby( reference a unamaged dll, but
    > don't be too complex) and use it in the asp.net web application and do the
    > same test to see whether the problem reoccur. That'll help confirm whehter
    > the problem is only specified to the particular Mc++ component.
    >
    > I'll update you about the kb article's info as soon as possible, and if you
    > have any other findings , please also feel free to post here. Thanks.
    >
    > Regards,
    >
    > Steven Cheng
    > Microsoft Online Support
    >
    > Get Secure! www.microsoft.com/security
    > (This posting is provided "AS IS", with no warranties, and confers no
    > rights.)
    >
     
    F. Prefect, Oct 8, 2004
    #3
  4. Hi Hans,

    Thanks for the followup. Yes, I think your thought on the app crash is
    reasonable. If so, is it ok that we provide some protected code to catch
    such exception and reinitialize the static reference when it is called
    after the application reloaded.

    Also, as for the further question you mentioned, I'll do some furthe
    research and will update you as soon as I got any information. Thanks.

    Regards,

    Steven Cheng
    Microsoft Online Support

    Get Secure! www.microsoft.com/security
    (This posting is provided "AS IS", with no warranties, and confers no
    rights.)
     
    Steven Cheng[MSFT], Oct 8, 2004
    #4
  5. F. Prefect

    F. Prefect Guest

    Hello Steven,

    What do you mean by "provide some protected code" ?
    Do you mean in the next Version of the runtime or some code in my
    managed c++ assembly.

    Thanks for your help,
    Hans-Jürgen

    Steven Cheng[MSFT] wrote:

    > Hi Hans,
    >
    > Thanks for the followup. Yes, I think your thought on the app crash is
    > reasonable. If so, is it ok that we provide some protected code to catch
    > such exception and reinitialize the static reference when it is called
    > after the application reloaded.
    >
    > Also, as for the further question you mentioned, I'll do some furthe
    > research and will update you as soon as I got any information. Thanks.
    >
    > Regards,
    >
    > Steven Cheng
    > Microsoft Online Support
    >
    > Get Secure! www.microsoft.com/security
    > (This posting is provided "AS IS", with no warranties, and confers no
    > rights.)
    >
     
    F. Prefect, Oct 8, 2004
    #5
  6. Hi Hans,

    Thanks for the followup. The protected code I mentioned means some thing in
    our own code ( in that mc++ assmelby).
    Also, I've got some suggestions from some other experts, here are their
    original description regarding on your two question:

    ==========================
    For the first issue, this should be fixed in 2003. The issue was with the
    inability to retain the appdomain for virtual function calls across a
    transition boundary. In 2003, VC++ and the CLR implemented support to
    retain the originating appdomain across the transition boundary. You will
    need to rebuild everything C++ that you built with /clr with the 2003
    compiler and then use the 2003 CLR to get the fix.

    For the second issue, it is safe to call __crt_dll_initialize/terminate
    multiple times. You definitely do not want to call either of these
    functions while you thread has obtained the loader lock. One such occasion
    is during a call to a DllMain (or something that DllMain calls such as
    global object constructors).
    ============================

    Thanks.

    Regards,

    Steven Cheng
    Microsoft Online Support

    Get Secure! www.microsoft.com/security
    (This posting is provided "AS IS", with no warranties, and confers no
    rights.)
     
    Steven Cheng[MSFT], Oct 10, 2004
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. cameron
    Replies:
    2
    Views:
    7,250
    Steven Cheng[MSFT]
    Feb 24, 2004
  2. Charles Herring
    Replies:
    1
    Views:
    1,915
    bruce barker
    Sep 13, 2004
  3. news
    Replies:
    0
    Views:
    443
  4. Dave Burns
    Replies:
    2
    Views:
    662
    Dave Burns
    Jan 12, 2007
  5. Dave Burns
    Replies:
    0
    Views:
    405
    Dave Burns
    Jan 12, 2007
Loading...

Share This Page