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

[F. Prefect]

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.Collecti ons.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...;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.

[Steven Cheng[MSFT]]

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]

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_initi alize and __crt_dll_termi nate at initialization time (but
not from within Dll-Entry point).

How should I do this in an ASP.NET environment. The methods
Application_Sta rt/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_initi alize and __crt_dll_termi nate 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...&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.)

[Steven Cheng[MSFT]]

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]

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.)

[Steven Cheng[MSFT]]

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_initi alize/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.)