Re: Access Violation Releasing CComPtr<IAzAuthorizationStore>

You're using COM objects from DllMain (global destructors are
invoked from the DLL entry point), and this can cause all kinds
of undefined behavior:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dllmain.asp

The right solution here would be to release all COM objects
before your DllMain is invoked. I'm not familiar with IIS worker
process model so I'm not sure if it provides a notification where
you can do this. If there is no way for you to clean up before
DllMain(PROCESS_DETACH) is invoked then you should
just leak the objects (for example by making them regular
pointers instead of CComPtr's).

If your code used to live in a COM+ dllhost then the reason you
didn't have this problem is probably because COM+ doesn't call
ExitProcess when dllhost process is shutdown. Instead it calls
TerminateProcess(GetCurrentProcess()) which doesn't invoke
DllMain notifications (so effectively you were leaking these
pointers anyway).

--
This posting is provided "AS IS" with no warranties, and confers no
rights.

"Linedata Mike" wrote:

I have a .NET remoting server that uses some unmanaged c++ under the hood,
and one portion of this is Authorization manager. I have a static
CComPtr<IAzAuthorizationStore> as a member variable to a class that is
never
instantiated. When I stop the remoting application the CComPtr tries to
release the IAzAuthorizationStore interface when it falls out of scope. I
get an access violation way down in msxml3. Can anyone give me some advice
on
how to work around this problem? Stack trace follows.

(I have a mini dump available is necessary)

First-chance exception at 0x72e56c1d (msxml3.dll) in w3wp.exe:
0xC0000005: Access violation reading location 0x00000020.

The following is a stack trace:
msxml3.dll!Base::_release() + 0x3134
msxml3.dll!HTMLWriter::Release() + 0xd
msxml3.dll!assign() + 0x42
msxml3.dll!_reference<WeakVector>::operator=() + 0x11
msxml3.dll!Document::finalize() + 0x51
msxml3.dll!NonGCBase::_delete() + 0x42
msxml3.dll!NonGCBase::_release() + 0x4c56
msxml3.dll!Document::_release() + 0x8
msxml3.dll!Document::Release() + 0x35
msxml3.dll!release() + 0xc5f
msxml3.dll!__comexport::~__comexport() + 0x13
msxml3.dll!DOMDocumentWrapper::`vector deleting destructor'() +
0xd
msxml3.dll!DOMNode::Release() + 0x2c2
msxml3.dll!DOMDocumentWrapper::Release() + 0x11
azroles.dll!XMLPersistClose() + 0x11
azroles.dll!AzPersistClose() + 0x45
azroles.dll!_AzpAzStoreFree@4() + 0x11
azroles.dll!_ObFreeGenericObject@4() + 0x58
azroles.dll!_ObDereferenceObject@4() + 0x2b
azroles.dll!_AzCloseHandle@8() + 0xf0
azroles.dll!CAzApplication::~CAzApplication() + 0x24
azroles.dll!ATL::CComObject<CAzAuthorizationStore>::`scalar
deleting destructor'() + 0xd
azroles.dll!ATL::CComObject<CAzAuthorizationStore>::Release() +
0x27

LVAuthorizationManagerD.dll!ATL::CComPtrBase<IAzAuthorizationStore>::~CComPtrBase<IAzAuthorizationStore>()
Line 128 + 0x12 C++

LVAuthorizationManagerD.dll!ATL::CComPtr<IAzAuthorizationStore>::~CComPtr<IAzAuthorizationStore>()
+ 0x16 C++
LVAuthorizationManagerD.dll!$E6() + 0xd C++
LVAuthorizationManagerD.dll!_CRT_INIT(void *
hDllHandle=0x0dea0000, unsigned long dwReason=0x00000000, void *
lpreserved=0x00000001) Line 234 C
LVAuthorizationManagerD.dll!_DllMainCRTStartup(void *
hDllHandle=0x0dea0000, unsigned long dwReason=0x00000000, void *
lpreserved=0x00000001) Line 288 + 0x11 C
ntdll.dll!_LdrpCallInitRoutine@16() + 0x14
ntdll.dll!_LdrShutdownProcess@0() + 0x121
kernel32.dll!__ExitProcess@4() + 0x3c
kernel32.dll!7d5046fa()
mscorsvr.dll!792377ec()
mscorsvr.dll!79235cb3()
mscorsvr.dll!792373f3()
mscoree.dll!7901145b()
msvcrt.dll!___crtExitProcess() + 0x29
msvcrt.dll!__cinit() + 0xd3
msvcrt.dll!_exit() + 0x11
msvcrt.dll!_exit() + 0x11
w3wp.exe!_wmainCRTStartup() + 0x140
kernel32.dll!_BaseProcessStart@4() + 0x28


--
Thanks for your time,
Mike



.

Relevant Pages

  • Re: delete in-place corresponding to placement new?
    ... > that comes to mind is to merely explicitly invoke the destructor. ... > capability is not available on a circa 1990 compiler. ... static void destroy(T *ptr) ...
    (comp.lang.cpp)
  • Re: WaitForSingleObject On Thread Handle In DLL_PROCESS_DETACH
    ... can't block on a new thread in DllMain or you'll deadlock, ... The DLL is a shell namespace extension. ... it to terminate. ... Because p is a global static object, the destructor of p will be ...
    (microsoft.public.win32.programmer.kernel)
  • Re: delete []
    ... when invoke delete, the destructor for each instance element of the ... , I malloc 10 bytes, and in the destructor of this class I will ... So the memory is balanced, ...
    (microsoft.public.dotnet.languages.vc)
  • derived method of abstract base class not getting invoked
    ... Code to invoke: ... saying there is no source code available. ... Since this is debug compiled code I assume the compiler is responsible ... I should add that I had the same problem with the base destructor, ...
    (microsoft.public.vc.language)
  • Re: More on garbage collection
    ... >>> If you have to invoke a destructor, ... > That doesn't work if the object references itself, ... > point a reference-counted garbage collector will not know it should ...
    (comp.arch)