Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

How to catch this error Access Violation

465 views
Skip to first unread message

joh...@gmail.com

unread,
Feb 23, 2007, 10:01:37โ€ฏPM2/23/07
to
I have a crash; I know that crash is in the following code

0012d300 12d75f49 OLEAUT32!VariantClear+0xb1
It is because the VariantClear tries to release a COM Object that is
not long valid.

Because I did not know how to prevent this error from happening,,
(Please see
http://groups.google.com/group/microsoft.public.dotnet.framework.clr/browse_thread/thread/4ea4df87b0f2e13c/87efbc010c5ab61a?hl=en#87efbc010c5ab61a
if you want to know why) The only option I have now is to catch the
error (Access Violation), but it looks like the system create a
endless loop on the following code

0012cf58 7c90e96c ntdll!KiFastSystemCallRet
0012cf5c 7c91e7d3 ntdll!NtUnmapViewOfSection+0xc
0012d04c 7c80abf7 ntdll!LdrUnloadDll+0x31a
0012d060 77513442 kernel32!FreeLibrary+0x3f
0012d06c 77513456 ole32!
CClassCache::CDllPathEntry::CFinishObject::Finish+0x2f
0012d080 775135fe ole32!CClassCache::CFinishComposite::Finish+0x1d


It ran the above code again and again, even I have SEH in
0012d654 12d788f1 AppContainer!CPropertyContainer::RemoveMapObject
+0x1c5, the error never returned to my SEH

Would anyone please show me how to catch this particular error?
Thanks in advance.

John

the stack trace is as following,

0:000> kL 200
ChildEBP RetAddr
0012cf58 7c90e96c ntdll!KiFastSystemCallRet
0012cf5c 7c91e7d3 ntdll!NtUnmapViewOfSection+0xc
0012d04c 7c80abf7 ntdll!LdrUnloadDll+0x31a
0012d060 77513442 kernel32!FreeLibrary+0x3f
0012d06c 77513456 ole32!
CClassCache::CDllPathEntry::CFinishObject::Finish+0x2f
0012d080 775135fe ole32!CClassCache::CFinishComposite::Finish+0x1d
0012d228 77513578 ole32!CClassCache::FreeUnused+0x19d
0012d238 775133a2 ole32!CoFreeUnusedLibrariesEx+0x36
0012d244 6605a01e ole32!CoFreeUnusedLibraries+0x9
0012d258 6605b4d1 MSVBVM60!CCreDestroyCtlStruct+0x387
0012d27c 6601c56a MSVBVM60!CCreDestroyCtl+0x195
0012d2c0 6601bc56 MSVBVM60!CCreFUnloadForm+0x1c9
0012d2cc 660c9ed5 MSVBVM60!CUnkDesk::Release+0x23
0012d2e4 6600e720 MSVBVM60!BASIC_CLASS::PRIVATE_UNKNOWN::Release+0x11c
0012d2ec 77124918 MSVBVM60!SCM_MsoStdCompMgr::Release+0xd
0012d300 12d75f49 OLEAUT32!VariantClear+0xb1
0012d35c 12d715d4 AppContainer!_variant_t::~_variant_t+0x29
0012d3c0 12d74b25 AppContainer!std::pair<_bstr_t
const ,_variant_t>::~pair<_bstr_t const ,_variant_t>+0x44
0012d418 12d749b2 AppContainer!std::pair<_bstr_t
const ,_variant_t>::`scalar deleting destructor'+0x25
0012d470 12d73d46 AppContainer!std::_Destroy+0x22
0012d4cc 12d72cb5 AppContainer!std::_Tree<_bstr_t,std::pair<_bstr_t
const ,_variant_t>,std::map<_bstr_t,_variant_t,std::less<_bstr_t>,std::allocator<_variant_t>
>::_Kfn,std::less<_bstr_t>,std::allocator<_variant_t> >::_Destval+0x26
0012d550 12d78e2d AppContainer!std::_Tree<_bstr_t,std::pair<_bstr_t
const ,_variant_t>,std::map<_bstr_t,_variant_t,std::less<_bstr_t>,std::allocator<_variant_t>
>::_Kfn,std::less<_bstr_t>,std::allocator<_variant_t> >::erase+0x825
0012d5b0 12d78af5 AppContainer!
std::map<_bstr_t,_variant_t,std::less<_bstr_t>,std::allocator<_variant_t>
>::erase+0x2d
0012d654 12d788f1 AppContainer!CPropertyContainer::RemoveMapObject
+0x1c5
0012d6b8 12d796b0 AppContainer!CPropertyContainer::~CPropertyContainer
+0x41
0012d71c 12d77335 AppContainer!
ATL::CComObject<CPropertyContainer>::~CComObject<CPropertyContainer>
+0x70
0012d774 12d79758 AppContainer!
ATL::CComObject<CPropertyContainer>::`scalar deleting destructor'+0x25
0012d7dc 79e8dbde AppContainer!
ATL::CComObject<CPropertyContainer>::Release+0x48
0012d830 79e8db4a mscorwks!ReleaseTransitionHelper+0x5f
0012d878 79e8dac5 mscorwks!SafeReleaseHelper+0x89
0012d8ac 79f27983 mscorwks!SafeRelease+0x2f
0012d8c4 79f2792e mscorwks!RCW::ReleaseAllInterfaces+0x49
0012d8f4 79f279dc mscorwks!RCW::ReleaseAllInterfacesCallBack+0xbd
0012d924 79f279b0 mscorwks!RCW::Cleanup+0x22
0012d92c 79f27997 mscorwks!RCWCleanupList::ReleaseRCWListRaw+0x14
0012d95c 79f277e5 mscorwks!RCWCleanupList::ReleaseRCWListInCorrectCtx
+0x97
0012d96c 77525fbe mscorwks!CtxEntry::EnterContextCallback+0x94
0012d988 77e7a19c ole32!CRemoteUnknown::DoCallback+0x7a
0012d9a4 77ef321a RPCRT4!Invoke+0x30
0012dda8 77ef3bf3 RPCRT4!NdrStubCall2+0x297
0012de00 77600c31 RPCRT4!CStdStubBuffer_Invoke+0xc6
0012de40 77600bdb ole32!SyncStubInvoke+0x33
0012de88 7750f237 ole32!StubInvoke+0xa7
0012df60 7750f15c ole32!CCtxComChnl::ContextInvoke+0xe3
0012df7c 7750fc79 ole32!MTAInvoke+0x1a
0012dfa8 77600e3b ole32!STAInvoke+0x4a
0012dfdc 776009bc ole32!AppInvoke+0x7e
0012e0b0 77600df2 ole32!ComInvokeWithLockAndIPID+0x2e0
0012e0dc 7750fcb3 ole32!ComInvoke+0x60
0012e0f0 7750fae9 ole32!ThreadDispatch+0x23
0012e108 77d48744 ole32!ThreadWndProc+0xfe
0012e134 77d48826 USER32!InternalCallWinProc+0x28
0012e19c 77d489dd USER32!UserCallWinProcCheckWow+0x150
0012e1fc 77d48a20 USER32!DispatchMessageWorker+0x306
0012e20c 77512c02 USER32!DispatchMessageW+0xf
0012e23c 77512761 ole32!CCliModalLoop::PeekRPCAndDDEMessage+0x4c
0012e250 77557227 ole32!CCliModalLoop::BlockFn+0x5e
0012e2c4 79f27b88 ole32!CoWaitForMultipleHandles+0xcf
0012e2e4 79f27acf mscorwks!NT5WaitRoutine+0x51
0012e350 79f27a33 mscorwks!MsgWaitHelper+0xa5
0012e370 79f17493 mscorwks!Thread::DoAppropriateAptStateWait+0x28
0012e3f4 79f1732f mscorwks!Thread::DoAppropriateWaitWorker+0x144
0012e444 79f27cf0 mscorwks!Thread::DoAppropriateWait+0x40
0012e494 79f27c76 mscorwks!Thread::JoinEx+0x86
0012e4a0 79f27c52 mscorwks!Thread::Join+0x13
0012e4f0 79f20743 mscorwks!
RCWCleanupList::CleanupWrappersInCurrentCtxThread+0x15a
0012e4f8 79f20665 mscorwks!RCW::Initialize+0x77
0012e52c 79f1dc99 mscorwks!RCW::CreateRCW+0x51
0012e59c 79f1c9a5 mscorwks!COMInterfaceMarshaler::CreateObjectRef+0x4d
0012e5fc 79f1c110 mscorwks!COMInterfaceMarshaler::FindOrCreateObjectRef
+0xb4
0012eabc 79f82a1c mscorwks!GetObjectRefFromComIP+0x1b4
0012eadc 79f82a01 mscorwks!UnmarshalObjectFromInterface+0x19
0012eaf8 79f1e19d mscorwks!
InterfaceMarshalerBase::ConvertSpaceNativeToCLR+0x30
0012eb00 79f1e0b2 mscorwks!
DefaultMarshalOverrides<InterfaceMarshalerBase>::MarshalNativeToCLROut
+0x11
0012ed3c 79f1f206 mscorwks!RunML+0x4f9
0012ee58 79f1ed6a mscorwks!COMToCLRWorkerBody+0x10f
0012eeb4 79f1ec81 mscorwks!COMToCLRWorkerDebuggerWrapper+0x37
0012f088 0173a271 mscorwks!COMToCLRWorker+0x164
WARNING: Frame IP not in any known module. Following frames may be
wrong.
0012f0b0 1425fac3 0x173a271
0012f1e0 142672fd AppController!CAppController::Display+0x184
0012f2d0 142504d2 AppController!CAppController::Create+0x683
0012f398 14236181 AppController!CAppController::CreateComponents+0x2da
0012f534 4599c7be AppController!CAppController::Open+0x607
0012f704 0108654d StateMgr!StateMgr::IState_Ope+0xded
0012f8c8 79f21268 TestMenu!Multiple::INotify_Notify+0xcc7
0012f9a8 045a0dd6 mscorwks!CLRToCOMWorker+0x196
0012f9e4 0ff37e88 0x45a0dd6
0012fa40 0ce5a340 0xff37e88
0012fa74 0ce59f28 0xce5a340
0012fac0 010ed2e2 0xce59f28
*** WARNING: Unable to verify checksum for C:\WINDOWS\assembly
\NativeImages_v2.0.50727_32\System.Windows.Forms
\5892bc4805482546977cc303fe56856e\System.Windows.Forms.ni.dll
0012fc28 7b0d02da 0x10ed2e2
0012fc48 7b0d02da System_Windows_Forms_ni+0x1002da
0012fc8c 7b072c44 System_Windows_Forms_ni+0x1002da
0012fcf8 7b07a73d System_Windows_Forms_ni+0xa2c44
0012fd74 77d48744 System_Windows_Forms_ni+0xaa73d
0012fda0 77d48826 USER32!InternalCallWinProc+0x28
0012fe08 77d489dd USER32!UserCallWinProcCheckWow+0x150
0012fe68 77d496d7 USER32!DispatchMessageWorker+0x306
0012fe78 6600a4a3 USER32!DispatchMessageA+0xf
0012feb8 6600a41a MSVBVM60!ThunderMsgLoop+0xfd
0012fecc 6600a3bc MSVBVM60!CMsoCMHandler::FPushMessageLoop+0x19
0012fefc 6600a2f8 MSVBVM60!SCM::FPushMessageLoop+0xb9
0012ff18 6600a2c3 MSVBVM60!SCM_MsoCompMgr::FPushMessageLoop+0x2b
0012ff3c 6600361c MSVBVM60!CMsoComponent::PushMsgLoop+0x26
0012ffb8 00404dba MSVBVM60!ThunRTMain+0x9b
0012fff0 00000000 AppMain!__vbaS+0xa

Heinz Ozwirk

unread,
Feb 24, 2007, 2:51:12โ€ฏAM2/24/07
to
<joh...@gmail.com> schrieb im Newsbeitrag
news:1172286097....@q2g2000cwa.googlegroups.com...

>I have a crash; I know that crash is in the following code
>
> 0012d300 12d75f49 OLEAUT32!VariantClear+0xb1
> It is because the VariantClear tries to release a COM Object that is
> not long valid.
>
> Because I did not know how to prevent this error from happening,,
> (Please see
> http://groups.google.com/group/microsoft.public.dotnet.framework.clr/browse_thread/thread/4ea4df87b0f2e13c/87efbc010c5ab61a?hl=en#87efbc010c5ab61a
> if you want to know why) The only option I have now is to catch the
> error (Access Violation), but it looks like the system create a
> endless loop on the following code

When you make a copy of an interface pointer, you have to call AddRef on
that pointer, and you have to call Release on the same interface when it is
no longer used through that copy of the pointer, no matter what kind of
variable is used to store the pointer. If you follow those rules, and if you
release all interfaces before calling CoUninitialize, there should be no
such errors in the first place.

HTH
Heinz


Ivan Brugiolo [MSFT]

unread,
Feb 24, 2007, 3:27:37โ€ฏPM2/24/07
to
Could you post the output of the `r;~*kb` command ?
I'd like to see the registers (the `r` part) and the exact
instruction that causes the AV. On average, I would not expect
to see an AV to happen upon return from a system call,
unless you have unmapped ntdll.dll, that is never going to happen.

On top of the other suggestions of debugging your component ref-count,
module refcount, and Com-Initialization ref-count for each apartment,
I'd also suggest to enable PageHeap, so that you can leverege
it's ability to capture the stack backtrace of the thread who deleted the
block
of memory that is likely to be the cause of the AV.

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


<joh...@gmail.com> wrote in message
news:1172286097....@q2g2000cwa.googlegroups.com...

joh...@gmail.com

unread,
Feb 24, 2007, 10:31:04โ€ฏPM2/24/07
to
Thanks for your help ,
1) About reference counting, The COM Comoponent was created in .NET,
the is is passed to another COM Component in the .NET Code, so there
should not be any explicit reference count here. please see the
following post for detail
http://groups.google.com/group/microsoft.public.dotnet.framework.interop/browse_thread/thread/27e2734aa6cb0056/e3fa5c323c8e00db?hl=en#e3fa5c323c8e00db

2) Would you please tell me how to use PageHeap could help in this
case? since I already have the stack trace, and it is tricked by a
gabage colletion
3) Here is the result of r;~kb 100

0:000> r;~kb 100
eax=102fb404 ebx=125e6b83 ecx=66029f10 edx=0012cfdc esi=0024bd68
edi=0012cfa8
eip=7c90eb94 esp=0012cee4 ebp=0012cfd4 iopl=0 nv up ei pl zr
na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
ntdll!KiFastSystemCallRet:
7c90eb94 c3 ret
ChildEBP RetAddr Args to Child
0012cee0 7c90e96c 7c91e7d3 ffffffff 125e0000 ntdll!KiFastSystemCallRet
0012cee4 7c91e7d3 ffffffff 125e0000 0012d0d0 ntdll!NtUnmapViewOfSection
+0xc
0012cfd4 7c80abf7 125e0000 0012d100 0012d208 ntdll!LdrUnloadDll+0x31a
0012cfe8 77513442 125e0000 0012d228 77513456 kernel32!FreeLibrary+0x3f
0012cff4 77513456 0012d10c 776067e0 00000000 ole32!
CClassCache::CDllPathEntry::CFinishObject::Finish+0x2f
0012d008 775135fe 774e1ab0 00000000 00000000 ole32!
CClassCache::CFinishComposite::Finish+0x1d
0012d228 77513578 ffffffff 001460b0 102fb080 ole32!
CClassCache::FreeUnused+0x19d
0012d238 775133a2 ffffffff 00000000 6605a01e ole32!
CoFreeUnusedLibrariesEx+0x36
0012d244 6605a01e 08000000 102fafec 0012d27c ole32!
CoFreeUnusedLibraries+0x9
0012d258 6605b4d1 00ee546c 00000000 102f5084 MSVBVM60!
CCreDestroyCtlStruct+0x387
0012d27c 6601c56a 102eb660 00000000 00000000 MSVBVM60!CCreDestroyCtl
+0x195
0012d2c0 6601bc56 00021f64 00000000 660c9ed5 MSVBVM60!CCreFUnloadForm
+0x1c9
0012d2cc 660c9ed5 102f4e74 00000009 101d2150 MSVBVM60!CUnkDesk::Release
+0x23
0012d2e4 6600e720 14432af4 77124918 14432ad8 MSVBVM60!
BASIC_CLASS::PRIVATE_UNKNOWN::Release+0x11c
0012d2ec 77124918 14432ad8 0012d35c 0012d30c MSVBVM60!
SCM_MsoStdCompMgr::Release+0xd
0012d300 12d75f49 101d2150 0012d3b4 101d1ff8 OLEAUT32!VariantClear
+0xb1
0012d35c 12d715d4 0012d418 101d1ff8 00000000 AppContainer!
_variant_t::~_variant_t+0x29 [c:\program files\microsoft visual studio
\vc98\include\comutil.h @ 1736]
0012d3c0 12d74b25 0012d470 101d1ff8 00000000 AppContainer!


std::pair<_bstr_t const ,_variant_t>::~pair<_bstr_t const ,_variant_t>
+0x44

0012d418 12d749b2 00000000 0012d4cc 101d1ff8 AppContainer!


std::pair<_bstr_t const ,_variant_t>::`scalar deleting
destructor'+0x25

0012d470 12d73d46 101d2148 0012d544 101d1ff8 AppContainer!std::_Destroy
+0x22 [c:\program files\microsoft visual studio\vc98\include\xmemory @
38]
0012d4cc 12d72cb5 101d2148 0012d5b0 0012d5c0 AppContainer!


std::_Tree<_bstr_t,std::pair<_bstr_t
const ,_variant_t>,std::map<_bstr_t,_variant_t,std::less<_bstr_t>,std::allocator<_variant_t>

>::_Kfn,std::less<_bstr_t>,std::allocator<_variant_t> >::_Destval+0x26 [c:\program files\microsoft visual studio\vc98\include\xtree @ 585]
0012d550 12d78ebd 0012d60c 101d1ff8 0012d63c AppContainer!


std::_Tree<_bstr_t,std::pair<_bstr_t
const ,_variant_t>,std::map<_bstr_t,_variant_t,std::less<_bstr_t>,std::allocator<_variant_t>

>::_Kfn,std::less<_bstr_t>,std::allocator<_variant_t> >::erase+0x825 [c:\program files\microsoft visual studio\vc98\include\xtree @ 359]
0012d5b0 12d78b88 0012d60c 101d2138 0012d6ac AppContainer!


std::map<_bstr_t,_variant_t,std::less<_bstr_t>,std::allocator<_variant_t>

>::erase+0x2d [c:\program files\microsoft visual studio\vc98\include
\map @ 104]
0012d654 12d78901 0012d710 0017a980 00000000 AppContainer!
Mycontainer::RemoveMapObject+0x238 [c:\Source\AppContainer
\Mycontainer.h @ 120]
0012d6b8 12d79740 0012d774 0017a980 00000000 AppContainer!
Mycontainer::~Mycontainer+0x41 [c:\Source\AppContainer\Mycontainer.h @
137]
0012d71c 12d774f5 0012d7dc 0017a980 00000000 AppContainer!
ATL::CComObject<Mycontainer>::~CComObject<Mycontainer>+0x70 [c:
\program files\microsoft visual studio\vc98\atl\include\atlcom.h @
2411]
0012d774 12d79dd8 00000001 00000000 0017a980 AppContainer!
ATL::CComObject<Mycontainer>::`scalar deleting destructor'+0x25
0012d7dc 79e8dbde 101d4f80 824869f1 00000008 AppContainer!
ATL::CComObject<Mycontainer>::Release+0x48 [c:\program files\microsoft
visual studio\vc98\atl\include\atlcom.h @ 2419]
0012d830 79e8db4a 101d4f80 824869b9 00000008 mscorwks!
ReleaseTransitionHelper+0x5f
0012d878 79e8dac5 101d4f80 1437a628 8248696d mscorwks!SafeReleaseHelper
+0x89
0012d8ac 79f27983 101d4f80 1437a628 00000001 mscorwks!SafeRelease+0x2f
0012d8c4 79f2792e 82486935 00000001 1437a628 mscorwks!
RCW::ReleaseAllInterfaces+0x49
0012d8f4 79f279dc 1437a628 824868e5 00000001 mscorwks!
RCW::ReleaseAllInterfacesCallBack+0xbd
0012d924 79f279b0 01a1fb7c 79f27997 14440ee0 mscorwks!RCW::Cleanup
+0x22
0012d92c 79f27997 14440ee0 8248689d 0012d978 mscorwks!
RCWCleanupList::ReleaseRCWListRaw+0x14
0012d95c 79f277e5 001466d8 001466d8 0012d988 mscorwks!
RCWCleanupList::ReleaseRCWListInCorrectCtx+0x97
0012d96c 77525fbe 01a1fa18 0012d98c 0012d9b4 mscorwks!
CtxEntry::EnterContextCallback+0x94
0012d988 77e7a19c 0015b340 14405700 02020202 ole32!
CRemoteUnknown::DoCallback+0x7a
0012d9a4 77ef321a 77525f83 0012d9b8 00000002 RPCRT4!Invoke+0x30
0012dda8 77ef3bf3 0015eef8 0015d320 00233f14 RPCRT4!NdrStubCall2+0x297
0012de00 77600c31 0015eef8 00233f14 0015d320 RPCRT4!
CStdStubBuffer_Invoke+0xc6
0012de40 77600bdb 00233f14 00238024 00000000 ole32!SyncStubInvoke+0x33
0012de88 7750f237 00233f14 0015d238 0015eef8 ole32!StubInvoke+0xa7
0012df60 7750f15c 0015d320 00000000 0015eef8 ole32!
CCtxComChnl::ContextInvoke+0xe3
0012df7c 7750fc79 00233f14 00000001 0015eef8 ole32!MTAInvoke+0x1a
0012dfa8 77600e3b 00233f14 00000001 0015eef8 ole32!STAInvoke+0x4a
0012dfdc 776009bc 00233ec0 0015d320 0015eef8 ole32!AppInvoke+0x7e
0012e0b0 77600df2 00233ec0 0015d580 00000000 ole32!
ComInvokeWithLockAndIPID+0x2e0
0012e0dc 7750fcb3 00233ec0 00000400 001464d8 ole32!ComInvoke+0x60
0012e0f0 7750fae9 00233ec0 0012e170 7750fa56 ole32!ThreadDispatch+0x23
0012e108 77d48744 001d0632 001460b0 0000babe ole32!ThreadWndProc+0xfe
0012e134 77d48826 7750fa56 001d0632 00000400 USER32!InternalCallWinProc
+0x28
0012e19c 77d489dd 00000000 7750fa56 001d0632 USER32!
UserCallWinProcCheckWow+0x150
0012e1fc 77d48a20 0012e220 00000000 0012e23c USER32!
DispatchMessageWorker+0x306
0012e20c 77512c02 0012e220 00000102 0012e280 USER32!DispatchMessageW
+0xf
0012e23c 77512761 80010116 80010115 00000000 ole32!
CCliModalLoop::PeekRPCAndDDEMessage+0x4c
0012e250 77557227 0012e484 00000001 0012e27c ole32!
CCliModalLoop::BlockFn+0x5e
0012e2c4 79f27b88 00000002 00000001 00000001 ole32!
CoWaitForMultipleHandles+0xcf
0012e2e4 79f27acf 00000000 00000001 00000001 mscorwks!NT5WaitRoutine
+0x51
0012e350 79f27a33 00000001 0012e484 00000000 mscorwks!MsgWaitHelper
+0xa5
0012e370 79f17493 00000001 0012e484 00000000 mscorwks!
Thread::DoAppropriateAptStateWait+0x28
0012e3f4 79f1732f 00000001 0012e484 00000000 mscorwks!
Thread::DoAppropriateWaitWorker+0x144
0012e444 79f27cf0 00000001 0012e484 00000000 mscorwks!
Thread::DoAppropriateWait+0x40
0012e494 79f27c76 00000001 0017a980 79f27c52 mscorwks!Thread::JoinEx
+0x86
0012e4a0 79f27c52 00000001 00000001 82485531 mscorwks!Thread::Join
+0x13
0012e4f0 79f20743 00000001 79f20665 13932db4 mscorwks!
RCWCleanupList::CleanupWrappersInCurrentCtxThread+0x15a
0012e4f8 79f20665 13932db4 0012e58c 824854ed mscorwks!RCW::Initialize
+0x77
0012e52c 79f1dc99 13932db4 0012e58c 8248545d mscorwks!RCW::CreateRCW
+0x51
0012e59c 79f1c9a5 00000000 0012e5ec 8248543d mscorwks!
COMInterfaceMarshaler::CreateObjectRef+0x4d
0012e5fc 79f1c110 82485759 0012ed8c 0012ed64 mscorwks!
COMInterfaceMarshaler::FindOrCreateObjectRef+0xb4
0012eabc 79f82a1c 13932db4 00000000 00000000 mscorwks!
GetObjectRefFromComIP+0x1b4
0012eadc 79f82a01 00195528 13932db4 00000000 mscorwks!
UnmarshalObjectFromInterface+0x19
0012eaf8 79f1e19d 0012ed64 79f1e0b2 0012f0dc mscorwks!
InterfaceMarshalerBase::ConvertSpaceNativeToCLR+0x30
0012eb00 79f1e0b2 0012f0dc 0012ed5c 82485a09 mscorwks!
DefaultMarshalOverrides<InterfaceMarshalerBase>::MarshalNativeToCLROut
+0x11
0012ed3c 79f1f206 0145258c 0012f0dc 0012ed5c mscorwks!RunML+0x4f9
0012ee58 79f1ed6a 0017a980 0012f060 0012f0c8 mscorwks!
COMToCLRWorkerBody+0x10f
0012eeb4 79f1ec81 0017a980 0012f060 0012f0c8 mscorwks!
COMToCLRWorkerDebuggerWrapper+0x37
0012f088 0173a271 0017a980 0012f0c8 99f79cfd mscorwks!COMToCLRWorker


+0x164
WARNING: Frame IP not in any known module. Following frames may be
wrong.

0012f0b0 1425fac3 0012f558 0012f65c 00000001 0x173a271
0012f1e0 142672fd 0edc9060 0012f2b4 0012f4cc AppController!
CAppController::DisplayComponentExists+0x184 [c:\Source\AppController
\CAppController.cls @ 7666]
0012f2d0 142504d2 0edc9060 00000000 0012f4cc AppController!
CAppController::CreateAllViewsDisplayComps+0x683 [c:\Source
\AppController\CAppController.cls @ 9202]
0012f398 14236181 0edc9060 0012f4cc 00000000 AppController!
CAppController::CreateRouteComponents+0x2da [c:\Source\AppController
\CAppController.cls @ 5136]
0012f534 4599c7be 0edc9060 00000001 00000000 AppController!
CAppController::IDataController_Open+0x607 [c:\Source\AppController
\CAppController.cls @ 864]
0012f704 0cd8654d 04936a28 0cd82ee4 1443f4c4 StateMgr!
CSessionMgr::ISession_OpenDataFile+0xded [c:\Source\SessionMgr
\SessionMgr.cls @ 4474]
0012f8c8 79f21268 0efcb230 00000001 0000200c TestMenu!
Multiple::INotify_Notify+0xcc7 [C:\Project\TestMenu\Multiple.cls @
126]
0012f9a8 04590e96 0017a980 0012f9fc 99f79cfd mscorwks!CLRToCOMWorker
+0x196
0012f9e4 0cec8b28 0012fa50 0211ee60 01d477ac 0x4590e96aascv
0012fa40 0ceaa340 0012fa50 01d4175c 01dfcd88 0xcec8b28
0012fa74 0cea9f28 0211ed74 01e0a768 0211ed74 0xceaa340
0012fac0 0cdfbbf2 0211ed74 020d80a0 0012fb10 0xcea9f28


*** WARNING: Unable to verify checksum for C:\WINDOWS\assembly
\NativeImages_v2.0.50727_32\System.Windows.Forms
\5892bc4805482546977cc303fe56856e\System.Windows.Forms.ni.dll

0012fc28 7b0d02da 0012fd1c 00000000 00000000 0xcdfbbf2
0012fc48 7b0d02da 001a1ad4 02079a68 00000042 System_Windows_Forms_ni
+0x1002da
0012fc8c 7b072c44 00000001 00100000 99f79cfd System_Windows_Forms_ni
+0x1002da
0012fcf8 7b07a73d 7b07a716 0012fd50 00000000 System_Windows_Forms_ni
+0xa2c44
0012fd74 77d48744 001a1ad4 00000202 00000000 System_Windows_Forms_ni
+0xaa73d
0012fda0 77d48826 01452d8a 001a1ad4 00000202 USER32!InternalCallWinProc
+0x28
0012fe08 77d489dd 00000000 01452d8a 001a1ad4 USER32!
UserCallWinProcCheckWow+0x150
0012fe68 77d496d7 0012fe90 00000001 0012feb8 USER32!
DispatchMessageWorker+0x306
0012fe78 6600a4a3 0012fe90 ffffffff 00e0379c USER32!DispatchMessageA
+0xf
0012feb8 6600a41a ffffffff 00e037c4 00e00000 MSVBVM60!ThunderMsgLoop
+0xfd
0012fecc 6600a3bc 00e0379c ffffffff 00e03894 MSVBVM60!
CMsoCMHandler::FPushMessageLoop+0x19
0012fefc 6600a2f8 00e03894 ffffffff 0000151c MSVBVM60!
SCM::FPushMessageLoop+0xb9
0012ff18 6600a2c3 00e037c0 00e03894 ffffffff MSVBVM60!
SCM_MsoCompMgr::FPushMessageLoop+0x2b
0012ff3c 6600361c ffffffff 80000001 00e6d230 MSVBVM60!
CMsoComponent::PushMsgLoop+0x26
0012ffb8 00404dba 004051e4 7c816fd7 80000001 MSVBVM60!ThunRTMain+0x9b
0012fff0 00000000 00404db0 00000000 78746341 AppMain!__vbaS+0xa
On Feb 24, 12:27 pm, "Ivan Brugiolo [MSFT]"


<ivanb...@online.microsoft.com> wrote:
> Could you post the output of the `r;~*kb` command ?
> I'd like to see the registers (the `r` part) and the exact
> instruction that causes the AV. On average, I would not expect
> to see an AV to happen upon return from a system call,
> unless you have unmapped ntdll.dll, that is never going to happen.
>
> On top of the other suggestions of debugging your component ref-count,
> module refcount, and Com-Initialization ref-count for each apartment,
> I'd also suggest to enable PageHeap, so that you can leverege
> it's ability to capture the stack backtrace of the thread who deleted the
> block
> of memory that is likely to be the cause of the AV.
>
> --
> --
> This posting is provided "AS IS" with no warranties, and confers no rights.
> Use of any included script samples are subject to the terms specified athttp://www.microsoft.com/info/cpyright.htm
>

> <john...@gmail.com> wrote in message


>
> news:1172286097....@q2g2000cwa.googlegroups.com...
>
>
>
> >I have a crash; I know that crash is in the following code
>
> > 0012d300 12d75f49 OLEAUT32!VariantClear+0xb1
> > It is because the VariantClear tries to release a COM Object that is
> > not long valid.
>
> > Because I did not know how to prevent this error from happening,,
> > (Please see

> >http://groups.google.com/group/microsoft.public.dotnet.framework.clr/...

> > 0012fff0 00000000 AppMain!__vbaS+0xa- Hide quoted text -
>
> - Show quoted text -


joh...@gmail.com

unread,
Feb 24, 2007, 10:34:03โ€ฏPM2/24/07
to
Thanks for your help ,
About reference counting, The COM Comoponent was created in .NET,
Assigned to a property in another COM Component in the .NET Code, so

there should not be any explicit reference count here. please see the
following post for detail
http://groups.google.com/group/microsoft.public.dotnet.framework.interop/browse_thread/thread/27e2734aa6cb0056/e3fa5c323c8e00db?hl=en#e3fa5c323c8e00db

On Feb 23, 11:51 pm, "Heinz Ozwirk" <SPAMhozw...@arcor.de> wrote:
> <john...@gmail.com> schrieb im Newsbeitragnews:1172286097....@q2g2000cwa.googlegroups.com...


>
> >I have a crash; I know that crash is in the following code
>
> > 0012d300 12d75f49 OLEAUT32!VariantClear+0xb1
> > It is because the VariantClear tries to release a COM Object that is
> > not long valid.
>
> > Because I did not know how to prevent this error from happening,,
> > (Please see

> >http://groups.google.com/group/microsoft.public.dotnet.framework.clr/...

Ivan Brugiolo [MSFT]

unread,
Feb 24, 2007, 11:29:03โ€ฏPM2/24/07
to
Suspecting the reference counting makes sense, because your thread is dying
while
some form premature unload is happening.
For example, Which dll was supposed to be loaded at base address 125e0000 ?
Can you monitor the DLL-unloads with `sxe ud` ?

Still, the debugger outout does not tell me the real problem.
What is really happening ? Is the process dying ?
The stack below is not an AV. Can you do a `.lastevent` in the debugger ?
It should tell what was really going on.
Maybe the process died in a different thread, and,
what you have there is what is left of the process.
In this case, could you set a breakkpoint in
mscorwks!CorExitProcess and ntdll!NtTeminateProcess ?
Did you have any swallowed-through exceptions before all of this happened ?


<joh...@gmail.com> wrote in message
news:1172374264.7...@p10g2000cwp.googlegroups.com...

> > ,_variant_t>,std::map<_bstr_t,_variant_t,std::less<_bstr_t>,std::allocator<่Œvariant_t>


> >>::_Kfn,std::less<_bstr_t>,std::allocator<_variant_t> >::_Destval+0x26
> > 0012d550 12d78e2d AppContainer!std::_Tree<_bstr_t,std::pair<_bstr_t
> > const

> > ,_variant_t>,std::map<_bstr_t,_variant_t,std::less<_bstr_t>,std::allocator<่Œvariant_t>

joh...@gmail.com

unread,
Feb 25, 2007, 3:21:58โ€ฏAM2/25/07
to
Sorry I send the wrong stack trace, here is the AV Stack Trace and
also the Code causing the AV

I agrees that the reference count is the problem, but my point is that
there is not much I could do, because the COM component is created
in .NET 2.0, passed to another COM Component (Also created in .NET
2.0), SO the .NET is suppose to manage the reference count.

Here is the second COM Component which take the first COM Component
and stored it in a variant_t (later stored in a STL Map)
b
The error happend when in the destructor of the second Component, when
I tries to erase the entries in the stl map, that eventualy casuing
the VariantClear to be called, it them tries to free a COM Component
which is not long valid, causing AV

Here is my Code , here the map stored the COM Object Name and the COM
Object Instance.
typedef map<_bstr_t,_variant_t> PropertyMap;
typedef pair<_bstr_t,_variant_t> Pair;

//the map of names to properties
PropertyMap m_Props;
private:
_variant_t tmp;

vector<_bstr_t> vecNames;
void RemoveMapObject()
{
int currentCount=0;
int lsize=m_Props.size();

vector<_bstr_t>::iterator vecit;
PropertyMap::iterator mapit;
for (mapit = m_Props.begin();mapit!=m_Props.end();mapit++)
{
OutputDebugString(mapit->first);
vecNames.push_back(mapit->first);
}
__try
{

int j=0;

for ( vecit=vecNames.begin();vecit!=vecNames.end();vecit++)
{
mapit=m_Props.find(*vecit);
if (mapit!=m_Props.end())
{
m_Props.erase(mapit);
}
}
}
__except (EXCEPTION_EXECUTE_HANDLER)
{
}

}


0:028> bl
0 e 79f0c367 0001 (0001) 0:**** mscorwks!CorExitProcess
1 e 7c90e88e 0001 (0001) 0:**** ntdll!NtTerminateProcess
0:028> g
(1d0c.778): Unknown exception - code c000008f (first chance)
Message 0x101 queued at 483297875. Character ID found = 0xD/13.
(1d0c.778): Unknown exception - code c000008f (first chance)
Unload module c:\AppDir\SDExtender.dll at 18730000
eax=0012b0cc ebx=18733441 ecx=00000000 edx=0012c300 esi=151020b0
edi=0012ebfc
eip=7c90eb94 esp=0012eb38 ebp=0012ec28 iopl=0 nv up ei pl zr


na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
ntdll!KiFastSystemCallRet:
7c90eb94 c3 ret

0:000> g
Unload module c:\AppDir\SDLgCmd.dll at 33700000
eax=0012b0cc ebx=3370ac41 ecx=00000000 edx=0012c300 esi=15101ba8
edi=0012ebfc
eip=7c90eb94 esp=0012eb38 ebp=0012ec28 iopl=0 nv up ei pl zr


na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
ntdll!KiFastSystemCallRet:
7c90eb94 c3 ret

0:000> g
Unload module c:\AppDir\STCD.dll at 33a80000
eax=0012b0cc ebx=33a8cb85 ecx=00000000 edx=0012c300 esi=0024e400
edi=0012ebfc
eip=7c90eb94 esp=0012eb38 ebp=0012ec28 iopl=0 nv up ei pl zr


na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
ntdll!KiFastSystemCallRet:
7c90eb94 c3 ret

0:000> g
Unload module c:\AppDir\SDPCmd.dll at 338e0000
eax=0012b0cc ebx=338e93e3 ecx=00000000 edx=0012c300 esi=0024e300
edi=0012ebfc
eip=7c90eb94 esp=0012eb38 ebp=0012ec28 iopl=0 nv up ei pl zr


na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
ntdll!KiFastSystemCallRet:
7c90eb94 c3 ret

0:000> g
Unload module c:\AppDir\JNBS.dll at 1d620000
eax=01050000 ebx=1d762340 ecx=0012e758 edx=7c90eb94 esi=0024e238
edi=0012ebfc
eip=7c90eb94 esp=0012eb38 ebp=0012ec28 iopl=0 nv up ei pl zr


na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
ntdll!KiFastSystemCallRet:
7c90eb94 c3 ret

0:000> g
Unload module c:\AppDir\FIO.dll at 3e710000
eax=01050000 ebx=3e750b60 ecx=0012e758 edx=7c90eb94 esi=0024e188
edi=0012ebfc
eip=7c90eb94 esp=0012eb38 ebp=0012ec28 iopl=0 nv up ei pl zr


na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
ntdll!KiFastSystemCallRet:
7c90eb94 c3 ret

0:000> g
Unload module c:\AppDir\JData.dll at 28dc0000
eax=01050000 ebx=28dc9bf0 ecx=0012e758 edx=7c90eb94 esi=0024dfa8
edi=0012ebfc
eip=7c90eb94 esp=0012eb38 ebp=0012ec28 iopl=0 nv up ei pl zr


na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
ntdll!KiFastSystemCallRet:
7c90eb94 c3 ret

0:000> kb


ChildEBP RetAddr Args to Child

0012eb34 7c90e96c 7c91e7d3 ffffffff 28dc0000 ntdll!KiFastSystemCallRet
0012eb38 7c91e7d3 ffffffff 28dc0000 0012ecac ntdll!NtUnmapViewOfSection
+0xc
0012ec28 7c80abf7 28dc0000 0012ecc4 0012ee74 ntdll!LdrUnloadDll+0x31a
0012ec3c 77513442 28dc0000 0012ee94 77513456 kernel32!FreeLibrary+0x3f
0012ec48 77513456 0012ecd0 776067e0 00000000 ole32!
CClassCache::CDllPathEntry::CFinishObject::Finish+0x2f
0012ec5c 775135fe 774e1ab0 00000000 00000000 ole32!
CClassCache::CFinishComposite::Finish+0x1d
0012ee94 77513578 ffffffff 001460b0 102e7700 ole32!
CClassCache::FreeUnused+0x19d
0012eea4 775133a2 ffffffff 00000000 6605a01e ole32!
CoFreeUnusedLibrariesEx+0x36
0012eeb0 6605a01e 08000000 102e766c 0012eee8 ole32!
CoFreeUnusedLibraries+0x9
0012eec4 6605b4d1 00ee5314 00000000 102cee44 MSVBVM60!
CCreDestroyCtlStruct+0x387
0012eee8 6601c56a 102e73a0 00000000 00000000 MSVBVM60!CCreDestroyCtl
+0x195
0012ef2c 6601bc56 015912ac 00000000 660c9ed5 MSVBVM60!CCreFUnloadForm
+0x1c9
0012ef38 660c9ed5 102ce6ac 00000009 101f2a70 MSVBVM60!CUnkDesk::Release
+0x23
0012ef50 6600e720 0ee94204 77124918 0ee941e8 MSVBVM60!
BASIC_CLASS::PRIVATE_UNKNOWN::Release+0x11c
0012ef58 77124918 0ee941e8 0012efc8 0012ef78 MSVBVM60!
SCM_MsoStdCompMgr::Release+0xd
*** WARNING: Unable to verify checksum for c:\AppDir\AppContainer.dll
0012ef6c 12d75f49 101f2a70 0012f020 101f2a5c OLEAUT32!VariantClear
+0xb1
0012efc8 12d715d4 0012f084 101f2a5c 00000000 AppContainer!


_variant_t::~_variant_t+0x29 [c:\program files\microsoft visual studio
\vc98\include\comutil.h @ 1736]

0012f02c 12d74b25 0012f0dc 101f2a5c 00000000 AppContainer!


std::pair<_bstr_t const ,_variant_t>::~pair<_bstr_t const ,_variant_t>
+0x44

0012f084 12d749b2 00000000 0012f138 101f2a5c AppContainer!


std::pair<_bstr_t const ,_variant_t>::`scalar deleting
destructor'+0x25

0012f0dc 12d73d46 101f2a68 0012f1b0 101f2a5c AppContainer!std::_Destroy


+0x22 [c:\program files\microsoft visual studio\vc98\include\xmemory @
38]

0:000> g
Unload module c:\AppDir\Calc.dll at 153d0000
eax=01050000 ebx=1574aa80 ecx=0012e758 edx=7c90eb94 esi=0024de28
edi=0012ebfc
eip=7c90eb94 esp=0012eb38 ebp=0012ec28 iopl=0 nv up ei pl zr


na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
ntdll!KiFastSystemCallRet:
7c90eb94 c3 ret

0:000> kb


ChildEBP RetAddr Args to Child

0012eb34 7c90e96c 7c91e7d3 ffffffff 153d0000 ntdll!KiFastSystemCallRet
0012eb38 7c91e7d3 ffffffff 153d0000 0012ec94 ntdll!NtUnmapViewOfSection
+0xc
0012ec28 7c80abf7 153d0000 0012ecac 0012ee74 ntdll!LdrUnloadDll+0x31a
0012ec3c 77513442 153d0000 0012ee94 77513456 kernel32!FreeLibrary+0x3f
0012ec48 77513456 0012ecb8 776067e0 00000000 ole32!
CClassCache::CDllPathEntry::CFinishObject::Finish+0x2f
0012ec5c 775135fe 774e1ab0 00000000 00000000 ole32!
CClassCache::CFinishComposite::Finish+0x1d
0012ee94 77513578 ffffffff 001460b0 102e7700 ole32!
CClassCache::FreeUnused+0x19d
0012eea4 775133a2 ffffffff 00000000 6605a01e ole32!
CoFreeUnusedLibrariesEx+0x36
0012eeb0 6605a01e 08000000 102e766c 0012eee8 ole32!
CoFreeUnusedLibraries+0x9
0012eec4 6605b4d1 00ee5314 00000000 102cee44 MSVBVM60!
CCreDestroyCtlStruct+0x387
0012eee8 6601c56a 102e73a0 00000000 00000000 MSVBVM60!CCreDestroyCtl
+0x195
0012ef2c 6601bc56 015912ac 00000000 660c9ed5 MSVBVM60!CCreFUnloadForm
+0x1c9
0012ef38 660c9ed5 102ce6ac 00000009 101f2a70 MSVBVM60!CUnkDesk::Release
+0x23
0012ef50 6600e720 0ee94204 77124918 0ee941e8 MSVBVM60!
BASIC_CLASS::PRIVATE_UNKNOWN::Release+0x11c
0012ef58 77124918 0ee941e8 0012efc8 0012ef78 MSVBVM60!
SCM_MsoStdCompMgr::Release+0xd
0012ef6c 12d75f49 101f2a70 0012f020 101f2a5c OLEAUT32!VariantClear
+0xb1
0012efc8 12d715d4 0012f084 101f2a5c 00000000 AppContainer!


_variant_t::~_variant_t+0x29 [c:\program files\microsoft visual studio
\vc98\include\comutil.h @ 1736]

0012f02c 12d74b25 0012f0dc 101f2a5c 00000000 AppContainer!


std::pair<_bstr_t const ,_variant_t>::~pair<_bstr_t const ,_variant_t>
+0x44

0012f084 12d749b2 00000000 0012f138 101f2a5c AppContainer!


std::pair<_bstr_t const ,_variant_t>::`scalar deleting
destructor'+0x25

0012f0dc 12d73d46 101f2a68 0012f1b0 101f2a5c AppContainer!std::_Destroy


+0x22 [c:\program files\microsoft visual studio\vc98\include\xmemory @
38]

0:000> r
eax=01050000 ebx=1574aa80 ecx=0012e758 edx=7c90eb94 esi=0024de28
edi=0012ebfc
eip=7c90eb94 esp=0012eb38 ebp=0012ec28 iopl=0 nv up ei pl zr


na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
ntdll!KiFastSystemCallRet:
7c90eb94 c3 ret

0:000> g
Unload module c:\AppDir\AppContainer.dll at 12d70000
eax=12d99024 ebx=12d7df70 ecx=12d99024 edx=12d99024 esi=0024a8b0
edi=0012ebfc
eip=7c90eb94 esp=0012eb38 ebp=0012ec28 iopl=0 nv up ei pl zr


na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
ntdll!KiFastSystemCallRet:
7c90eb94 c3 ret

0:000> r;kb
eax=12d99024 ebx=12d7df70 ecx=12d99024 edx=12d99024 esi=0024a8b0
edi=0012ebfc
eip=7c90eb94 esp=0012eb38 ebp=0012ec28 iopl=0 nv up ei pl zr


na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
ntdll!KiFastSystemCallRet:
7c90eb94 c3 ret
ChildEBP RetAddr Args to Child

0012eb34 7c90e96c 7c91e7d3 ffffffff 12d70000 ntdll!KiFastSystemCallRet
0012eb38 7c91e7d3 ffffffff 12d70000 0012ec7c ntdll!NtUnmapViewOfSection
+0xc
0012ec28 7c80abf7 12d70000 0012ec94 0012ee74 ntdll!LdrUnloadDll+0x31a
0012ec3c 77513442 12d70000 0012ee94 77513456 kernel32!FreeLibrary+0x3f
0012ec48 77513456 0012eca0 776067e0 00000000 ole32!
CClassCache::CDllPathEntry::CFinishObject::Finish+0x2f
0012ec5c 775135fe 774e1ab0 00000000 00000000 ole32!
CClassCache::CFinishComposite::Finish+0x1d
0012ee94 77513578 ffffffff 001460b0 102e7700 ole32!
CClassCache::FreeUnused+0x19d
0012eea4 775133a2 ffffffff 00000000 6605a01e ole32!
CoFreeUnusedLibrariesEx+0x36
0012eeb0 6605a01e 08000000 102e766c 0012eee8 ole32!
CoFreeUnusedLibraries+0x9
0012eec4 6605b4d1 00ee5314 00000000 102cee44 MSVBVM60!
CCreDestroyCtlStruct+0x387
0012eee8 6601c56a 102e73a0 00000000 00000000 MSVBVM60!CCreDestroyCtl
+0x195
0012ef2c 6601bc56 015912ac 00000000 660c9ed5 MSVBVM60!CCreFUnloadForm
+0x1c9
0012ef38 660c9ed5 102ce6ac 00000009 101f2a70 MSVBVM60!CUnkDesk::Release
+0x23
0012ef50 6600e720 0ee94204 77124918 0ee941e8 MSVBVM60!
BASIC_CLASS::PRIVATE_UNKNOWN::Release+0x11c
0012ef58 77124918 0ee941e8 0012efc8 0012ef78 MSVBVM60!
SCM_MsoStdCompMgr::Release+0xd
0012ef6c 12d75f49 101f2a70 0012f020 101f2a5c OLEAUT32!VariantClear
+0xb1
0012efc8 12d715d4 0012f084 101f2a5c 00000000 AppContainer!


_variant_t::~_variant_t+0x29 [c:\program files\microsoft visual studio
\vc98\include\comutil.h @ 1736]

0012f02c 12d74b25 0012f0dc 101f2a5c 00000000 AppContainer!


std::pair<_bstr_t const ,_variant_t>::~pair<_bstr_t const ,_variant_t>
+0x44

0012f084 12d749b2 00000000 0012f138 101f2a5c AppContainer!


std::pair<_bstr_t const ,_variant_t>::`scalar deleting
destructor'+0x25

0012f0dc 12d73d46 101f2a68 0012f1b0 101f2a5c AppContainer!std::_Destroy


+0x22 [c:\program files\microsoft visual studio\vc98\include\xmemory @
38]

0:000> g
Unload module c:\AppDir\RDB.dll at 23870000
eax=00000000 ebx=23877179 ecx=0012eb38 edx=7c90eb94 esi=00249b70
edi=0012ebfc
eip=7c90eb94 esp=0012eb38 ebp=0012ec28 iopl=0 nv up ei pl zr


na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
ntdll!KiFastSystemCallRet:
7c90eb94 c3 ret

0:000> r;kb
eax=00000000 ebx=23877179 ecx=0012eb38 edx=7c90eb94 esi=00249b70
edi=0012ebfc
eip=7c90eb94 esp=0012eb38 ebp=0012ec28 iopl=0 nv up ei pl zr


na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
ntdll!KiFastSystemCallRet:
7c90eb94 c3 ret
ChildEBP RetAddr Args to Child

0012eb34 7c90e96c 7c91e7d3 ffffffff 23870000 ntdll!KiFastSystemCallRet
0012eb38 7c91e7d3 ffffffff 23870000 0012ee74 ntdll!NtUnmapViewOfSection
+0xc
0012ec28 7c80abf7 23870000 0012ec7c 0012ee74 ntdll!LdrUnloadDll+0x31a
0012ec3c 77513442 23870000 0012ee94 77513456 kernel32!FreeLibrary+0x3f
0012ec48 77513456 0012ec88 776067e0 00000000 ole32!
CClassCache::CDllPathEntry::CFinishObject::Finish+0x2f
0012ec5c 775135fe 774e1ab0 00000000 00000000 ole32!
CClassCache::CFinishComposite::Finish+0x1d
0012ee94 77513578 ffffffff 001460b0 102e7700 ole32!
CClassCache::FreeUnused+0x19d
0012eea4 775133a2 ffffffff 00000000 6605a01e ole32!
CoFreeUnusedLibrariesEx+0x36
0012eeb0 6605a01e 08000000 102e766c 0012eee8 ole32!
CoFreeUnusedLibraries+0x9
0012eec4 6605b4d1 00ee5314 00000000 102cee44 MSVBVM60!
CCreDestroyCtlStruct+0x387
0012eee8 6601c56a 102e73a0 00000000 00000000 MSVBVM60!CCreDestroyCtl
+0x195
0012ef2c 6601bc56 015912ac 00000000 660c9ed5 MSVBVM60!CCreFUnloadForm
+0x1c9
0012ef38 660c9ed5 102ce6ac 00000009 101f2a70 MSVBVM60!CUnkDesk::Release
+0x23
0012ef50 6600e720 0ee94204 77124918 0ee941e8 MSVBVM60!
BASIC_CLASS::PRIVATE_UNKNOWN::Release+0x11c
0012ef58 77124918 0ee941e8 0012efc8 0012ef78 MSVBVM60!
SCM_MsoStdCompMgr::Release+0xd
0012ef6c 12d75f49 101f2a70 0012f020 101f2a5c OLEAUT32!VariantClear
+0xb1


WARNING: Frame IP not in any known module. Following frames may be
wrong.

0012efc8 12d715d4 0012f084 101f2a5c 00000000
<Unloaded_AppContainer.dll>+0x5f49
0012f02c 12d74b25 0012f0dc 101f2a5c 00000000
<Unloaded_AppContainer.dll>+0x15d4
0012f084 12d749b2 00000000 0012f138 101f2a5c
<Unloaded_AppContainer.dll>+0x4b25
0012f0dc 12d73d46 101f2a68 0012f1b0 101f2a5c
<Unloaded_AppContainer.dll>+0x49b2
0:000> g
(1d0c.778): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=00000000 ecx=00000000 edx=000007f8 esi=101f2a70
edi=00000009
eip=771248d3 esp=0012ef64 ebp=0012ef6c iopl=0 nv up ei pl zr


na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000

efl=00010246
OLEAUT32!VariantClear+0xbb:
771248d3 66832600 and word ptr [esi],0 ds:
0023:101f2a70=????
0:000> r;kb
eax=00000000 ebx=00000000 ecx=00000000 edx=000007f8 esi=101f2a70
edi=00000009
eip=771248d3 esp=0012ef64 ebp=0012ef6c iopl=0 nv up ei pl zr


na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000

efl=00010246
OLEAUT32!VariantClear+0xbb:
771248d3 66832600 and word ptr [esi],0 ds:
0023:101f2a70=????


ChildEBP RetAddr Args to Child

0012ef6c 12d75f49 101f2a70 0012f020 101f2a5c OLEAUT32!VariantClear
+0xbb


WARNING: Frame IP not in any known module. Following frames may be
wrong.

0012efc8 12d715d4 0012f084 101f2a5c 00000000
<Unloaded_AppContainer.dll>+0x5f49
0012f02c 12d74b25 0012f0dc 101f2a5c 00000000
<Unloaded_AppContainer.dll>+0x15d4
0012f084 12d749b2 00000000 0012f138 101f2a5c
<Unloaded_AppContainer.dll>+0x4b25
0012f0dc 12d73d46 101f2a68 0012f1b0 101f2a5c
<Unloaded_AppContainer.dll>+0x49b2
0012f138 12d72cb5 101f2a68 0012f21c 0012f22c
<Unloaded_AppContainer.dll>+0x3d46
0012f1bc 12d78ebd 0012f278 101f2558 0012f2a8
<Unloaded_AppContainer.dll>+0x2cb5
0012f21c 12d78b88 0012f278 101f2a58 0012f318
<Unloaded_AppContainer.dll>+0x8ebd
0012f2c0 12d78901 0012f37c 0017a9f0 00000000
<Unloaded_AppContainer.dll>+0x8b88
0012f324 12d79740 0012f3e0 0017a9f0 00000000
<Unloaded_AppContainer.dll>+0x8901
0012f448 79e8dbde 101f24f0 920e3123 00000008
<Unloaded_AppContainer.dll>+0x9740
0012f3e0 12d79dd8 00000001 00000000 0017a9f0 mscorwks!
ReleaseTransitionHelper+0x5f
0012f448 79e8dbde 101f24f0 920e3123 00000008
<Unloaded_AppContainer.dll>+0x9dd8
0012f49c 79e8db4a 101f24f0 920e315b 00000008 mscorwks!
ReleaseTransitionHelper+0x5f
0012f4e4 79e8dac5 101f24f0 1438bc60 920e30a7 mscorwks!SafeReleaseHelper
+0x89
0012f518 79f27983 101f24f0 1438bc60 00000001 mscorwks!SafeRelease+0x2f
0012f530 79f2792e 920e30df 00000001 1438bc60 mscorwks!
RCW::ReleaseAllInterfaces+0x49
0012f560 79f279dc 1438bc60 920e302f 00000001 mscorwks!
RCW::ReleaseAllInterfacesCallBack+0xbd
0012f590 79f279b0 01a1fb7c 79f27997 1438c418 mscorwks!RCW::Cleanup
+0x22
0012f598 79f27997 1438c418 920e3077 0012f5e4 mscorwks!
RCWCleanupList::ReleaseRCWListRaw+0x14
0:000> g
(1d0c.778): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=00000000 ecx=12d93939 edx=7c9037d8 esi=00000000
edi=00000000
eip=12d93939 esp=0012eb94 ebp=0012ebb4 iopl=0 nv up ei pl zr


na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000

efl=00010246
<Unloaded_AppContainer.dll>+0x23939:
12d93939 ?? ???
0:000> r;kb
eax=00000000 ebx=00000000 ecx=12d93939 edx=7c9037d8 esi=00000000
edi=00000000
eip=12d93939 esp=0012eb94 ebp=0012ebb4 iopl=0 nv up ei pl zr


na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000

efl=00010246
<Unloaded_AppContainer.dll>+0x23939:
12d93939 ?? ???


ChildEBP RetAddr Args to Child

WARNING: Frame IP not in any known module. Following frames may be
wrong.

0012eb90 7c9037bf 0012ec7c 0012f020 0012ec98
<Unloaded_AppContainer.dll>+0x23939
0012ebb4 7c90378b 0012ec7c 0012f020 0012ec98 ntdll!
ExecuteHandler2+0x26
0012ec64 7c90eafa 00000000 0012ec98 0012ec7c ntdll!ExecuteHandler+0x24
0012ec64 771248d3 00000000 0012ec98 0012ec7c ntdll!
KiUserExceptionDispatcher+0xe
0012ef6c 12d75f49 101f2a70 0012f020 101f2a5c OLEAUT32!VariantClear
+0xbb
0012efc8 12d715d4 0012f084 101f2a5c 00000000
<Unloaded_AppContainer.dll>+0x5f49
0012f02c 12d74b25 0012f0dc 101f2a5c 00000000
<Unloaded_AppContainer.dll>+0x15d4
0012f084 12d749b2 00000000 0012f138 101f2a5c
<Unloaded_AppContainer.dll>+0x4b25
0012f0dc 12d73d46 101f2a68 0012f1b0 101f2a5c
<Unloaded_AppContainer.dll>+0x49b2
0012f138 12d72cb5 101f2a68 0012f21c 0012f22c
<Unloaded_AppContainer.dll>+0x3d46
0012f1bc 12d78ebd 0012f278 101f2558 0012f2a8
<Unloaded_AppContainer.dll>+0x2cb5
0012f21c 12d78b88 0012f278 101f2a58 0012f318
<Unloaded_AppContainer.dll>+0x8ebd
0012f2c0 12d78901 0012f37c 0017a9f0 00000000
<Unloaded_AppContainer.dll>+0x8b88
0012f324 12d79740 0012f3e0 0017a9f0 00000000
<Unloaded_AppContainer.dll>+0x8901
0012f448 79e8dbde 101f24f0 920e3123 00000008
<Unloaded_AppContainer.dll>+0x9740
0012f3e0 12d79dd8 00000001 00000000 0017a9f0 mscorwks!
ReleaseTransitionHelper+0x5f
0012f448 79e8dbde 101f24f0 920e3123 00000008
<Unloaded_AppContainer.dll>+0x9dd8
0012f49c 79e8db4a 101f24f0 920e315b 00000008 mscorwks!
ReleaseTransitionHelper+0x5f
0012f4e4 79e8dac5 101f24f0 1438bc60 920e30a7 mscorwks!SafeReleaseHelper
+0x89
0012f518 79f27983 101f24f0 1438bc60 00000001 mscorwks!SafeRelease+0x2f
0:000> .reload/unl AppContainer.dll
*** WARNING: Unable to verify checksum for AppContainer.dll
0:000> kb


ChildEBP RetAddr Args to Child

0012eb90 7c9037bf 0012ec7c 0012f020 0012ec98 AppContainer!
CreateErrorInfo+0xbb
0012ebb4 7c90378b 0012ec7c 0012f020 0012ec98 ntdll!
ExecuteHandler2+0x26
0012ec64 7c90eafa 00000000 0012ec98 0012ec7c ntdll!ExecuteHandler+0x24
0012ec64 771248d3 00000000 0012ec98 0012ec7c ntdll!
KiUserExceptionDispatcher+0xe
0012ef6c 12d75f49 101f2a70 0012f020 101f2a5c OLEAUT32!VariantClear
+0xbb
0012efc8 12d715d4 0012f084 101f2a5c 00000000 AppContainer!


_variant_t::~_variant_t+0x29 [c:\program files\microsoft visual studio
\vc98\include\comutil.h @ 1736]

0012f02c 12d74b25 0012f0dc 101f2a5c 00000000 AppContainer!


std::pair<_bstr_t const ,_variant_t>::~pair<_bstr_t const ,_variant_t>
+0x44

0012f084 12d749b2 00000000 0012f138 101f2a5c AppContainer!


std::pair<_bstr_t const ,_variant_t>::`scalar deleting
destructor'+0x25

0012f0dc 12d73d46 101f2a68 0012f1b0 101f2a5c AppContainer!std::_Destroy


+0x22 [c:\program files\microsoft visual studio\vc98\include\xmemory @
38]

0012f138 12d72cb5 101f2a68 0012f21c 0012f22c AppContainer!


std::_Tree<_bstr_t,std::pair<_bstr_t
const ,_variant_t>,std::map<_bstr_t,_variant_t,std::less<_bstr_t>,std::allocator<_variant_t>
>::_Kfn,std::less<_bstr_t>,std::allocator<_variant_t> >::_Destval+0x26
[c:\program files\microsoft visual studio\vc98\include\xtree @ 585]

0012f1bc 12d78ebd 0012f278 101f2558 0012f2a8 AppContainer!


std::_Tree<_bstr_t,std::pair<_bstr_t
const ,_variant_t>,std::map<_bstr_t,_variant_t,std::less<_bstr_t>,std::allocator<_variant_t>
>::_Kfn,std::less<_bstr_t>,std::allocator<_variant_t> >::erase+0x825
[c:\program files\microsoft visual studio\vc98\include\xtree @ 359]

0012f21c 12d78b88 0012f278 101f2a58 0012f318 AppContainer!


std::map<_bstr_t,_variant_t,std::less<_bstr_t>,std::allocator<_variant_t>
>::erase+0x2d [c:\program files\microsoft visual studio\vc98\include
\map @ 104]

0012f2c0 12d78901 0012f37c 0017a9f0 00000000 AppContainer!
CPropertyContainer::RemoveMapObject+0x238 [c:\source\AppContainer
\cpropertycontainer.h @ 120]
0012f324 12d79740 0012f3e0 0017a9f0 00000000 AppContainer!
CPropertyContainer::~CPropertyContainer+0x41 [c:\source\AppContainer
\cpropertycontainer.h @ 137]
0012f388 12d774f5 0012f448 0017a9f0 00000000 AppContainer!


ATL::CComObject<CPropertyContainer>::~CComObject<CPropertyContainer>

+0x70 [c:\program files\microsoft visual studio\vc98\atl\include
\atlcom.h @ 2411]

0012f3e0 12d79dd8 00000001 00000000 0017a9f0 AppContainer!


ATL::CComObject<CPropertyContainer>::`scalar deleting destructor'+0x25

0012f448 79e8dbde 101f24f0 920e3123 00000008 AppContainer!
ATL::CComObject<CPropertyContainer>::Release+0x48 [c:\program files


\microsoft visual studio\vc98\atl\include\atlcom.h @ 2419]

0012f49c 79e8db4a 101f24f0 920e315b 00000008 mscorwks!
ReleaseTransitionHelper+0x5f
0012f4e4 79e8dac5 101f24f0 1438bc60 920e30a7 mscorwks!SafeReleaseHelper
+0x89
0012f518 79f27983 101f24f0 1438bc60 00000001 mscorwks!SafeRelease+0x2f
0:000> .lastevent
Last event: 1d0c.778: Access violation - code c0000005 (first chance)
debugger time: Sat Feb 24 23:45:17.390 2007 (GMT-8)

On Feb 24, 8:29 pm, "Ivan Brugiolo [MSFT]"


<ivanb...@online.microsoft.com> wrote:
> Suspecting the reference counting makes sense, because your thread is dying
> while
> some form premature unload is happening.
> For example, Which dll was supposed to be loaded at base address 125e0000 ?
> Can you monitor the DLL-unloads with `sxe ud` ?
>
> Still, the debugger outout does not tell me the real problem.
> What is really happening ? Is the process dying ?
> The stack below is not an AV. Can you do a `.lastevent` in the debugger ?
> It should tell what was really going on.
> Maybe the process died in a different thread, and,
> what you have there is what is left of the process.
> In this case, could you set a breakkpoint in
> mscorwks!CorExitProcess and ntdll!NtTeminateProcess ?
> Did you have any swallowed-through exceptions before all of this happened ?
>

> <john...@gmail.com> wrote in message
>


> news:1172374264.7...@p10g2000cwp.googlegroups.com...
> Thanks for your help ,
> 1) About reference counting, The COM Comoponent was created in .NET,
> the is is passed to another COM Component in the .NET Code, so there
> should not be any explicit reference count here. please see the

> following post for detailhttp://groups.google.com/group/microsoft.public.dotnet.framework.inte...

> CAppController::CreateRouteComponents+0x2da [c:\Source\AppController ...
>
> read more ยป


Pavel Lebedinsky [MSFT]

unread,
Feb 25, 2007, 6:21:16โ€ฏAM2/25/07
to
johnxhc wrote:

> __try
> {
> // some STL code...
> }
> __except (EXCEPTION_EXECUTE_HANDLER)
> {
> }

You should remove this try/except. If you get a SEH exception from
regular C++ code it means something is badly corrupted, so instead
of silently swallowing the exception you should let it crash the process
so that the problem can be detected and debugged. Handling
unexpected SEH exceptions will just make the program crash or
hang later in an unrelated piece of code, without any possibility to find
out what went wrong.

> 0:028> g
> (1d0c.778): Unknown exception - code c000008f (first chance)

This looks like a VB exception. If you don't expect any exceptions
in this scenario you might want to do 'sxe c000008f' to see what
causes them.

> ntdll!KiFastSystemCallRet:
> 7c90eb94 c3 ret
> ChildEBP RetAddr Args to Child
> 0012eb34 7c90e96c 7c91e7d3 ffffffff 12d70000 ntdll!KiFastSystemCallRet
> 0012eb38 7c91e7d3 ffffffff 12d70000 0012ec7c ntdll!NtUnmapViewOfSection

> 12ec28 7c80abf7 12d70000 0012ec94 0012ee74 ntdll!LdrUnloadDll+0x31a
>012ec3c 77513442 12d70000 0012ee94 77513456 kernel32!FreeLibrary+0x3f

Looks like you enabled breaks on module unloads with sxe ud. If you
simply want to see module unload traces you can do sxn ud instead -
this will still print the names of the DLLs being unloaded but will not
cause a breakpoint on each unload. Or you could automatically print
a stack trace and continue execution using this command:

0:000> sxe -c "k;.echo;g" ud

> ChildEBP RetAddr Args to Child
> 0012eb34 7c90e96c 7c91e7d3 ffffffff 23870000 ntdll!KiFastSystemCallRet
> 0012eb38 7c91e7d3 ffffffff 23870000 0012ee74 ntdll!NtUnmapViewOfSection

> 0012ec28 7c80abf7 23870000 0012ec7c 0012ee74 ntdll!LdrUnloadDll+0x31a
> 0012ec3c 77513442 23870000 0012ee94 77513456 kernel32!FreeLibrary+0x3f

<some stack frames deleted>

> 0012efc8 12d715d4 0012f084 101f2a5c 00000000
> <Unloaded_AppContainer.dll>+0x5f49

At this point you're already in trouble. AppContainer.dll has already been
unloaded, but its code (or to be more precise, return addresses pointing
to where its code used to be) are still on the stack. Even if no other
problems occur, this thread will crash when it unwinds from what it's
doing now and tries to return to 0x12d715d4.

This is a DLL refcounting problem. If this thread was created by
AppContainer.dll, this DLL should have called LoadLibrary on
itself before calling CreateThread, to give the thread its own
refcount (the thread would release it on exit by calling
FreeLibraryAndExitThread).

If this thread was created by somebody else, there should have
been some other mechanism in your code to keep the DLL
loaded until the thread terminates. Look at the call stack at the
point where AppContainer.dll was unloaded (you can do
'sxe ud AppContainer.dll' to catch it) and try to figure out
whose responsibility it is to keep the DLL loaded at this point.

Your actual crash could also caused by similar refcounting
issues. Enabling full pageheap as Ivan mentioned can make
it a lot easier to figure out what the referenced address used
to hold, and who freed it.

joh...@gmail.com

unread,
Feb 25, 2007, 12:17:27โ€ฏPM2/25/07
to
1) I set a breakpoint at SEH, but it never reach the __except block,
so it does not matter I remove this block or not...
2) Unknown exception - code c000008f (first chance) , you are righ,if
I use DEBUG VIEW, that is translated into something like Floatpoint
inexactly error
3) The stack trace is the main thread, but the component is created
in .NET, I assume it is on a seperate thread ?
4) I am kind of new in windbg, would you please tell how I should
proceed the debuging once I enable Full Page Heap?
On Feb 25, 3:21 am, "Pavel Lebedinsky [MSFT]"

Pavel Lebedinsky [MSFT]

unread,
Feb 25, 2007, 8:48:16โ€ฏPM2/25/07
to
johnxhc wrote:

> 1) I set a breakpoint at SEH, but it never reach the __except block,
> so it does not matter I remove this block or not...

For this particular problem it does not matter, but it's still bad practice.

> 3) The stack trace is the main thread, but the component is created
> in .NET, I assume it is on a seperate thread ?

I don't know much about .NET to COM interop. I guess it would
depend on object threading models (STA or MTA), how COM
is initialized, etc.

Note that using a COM object from .NET does not automatically
take care of recounting or other resource management issues in
COM (such as memory management). The object still has to
follow all COM rules.

> 4) I am kind of new in windbg, would you please tell how I should
> proceed the debuging once I enable Full Page Heap?

Just run the app under debugger. Problems exposed by pageheap
typically manifest themselves as access violations. When you get
such access violation, use !heap -p -a command on the referenced
address to get more information about it.

Ivan Brugiolo [MSFT]

unread,
Feb 26, 2007, 1:20:57โ€ฏPM2/26/07
to
Besides other recomendations that Pavel gave, I'd like to point out a couple
of things:

-1-
This this crash

0:000> g
(1d0c.778): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=00000000 ecx=00000000 edx=000007f8 esi=101f2a70
edi=00000009
eip=771248d3 esp=0012ef64 ebp=0012ef6c iopl=0 nv up ei pl zr
na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00010246
OLEAUT32!VariantClear+0xbb:
771248d3 66832600 and word ptr [esi],0 ds:
0023:101f2a70=????

The question you have to answer is:
What happened to the memory backing the `101f2a70` address.
The method to answer that would be:
enable Full PageHeap on the applicaiton
c:\debuggers>gflags -p /enable <applicaiton_name.exe> /full
Upon error in the debugger
0:001> !address 101f2a70
0:001> !heap -p -a
0:001> !address 101f2a70

-2- for this early unload,
ask yourself:
Why would COM unload my module ?
This can only happen if DllGetClassObject() returned TRUE.
DllGetClassOject should return TRUE only if there are no more
outstanding instances of objects managed by the DLL.
For example, does the existance of AppContainer!Mycontainer
counts towards the module-count ?

There are subltle ways this can happen.

Let me make a simple example:

class MyConstainer {
private:
ULONG m_cRef;
std::map<_bstr_t,_variant_t> m_map;
public:
// usual AddRef/Relaese?QI stuff

~MyContainer();
}

~MyContainer(){
g_ModuleCount--; // too early
for (iterator it = m_map.begin(); iterator != m_map.end; ++iterator) {
m_map.erase(iterator);
}
}

Now, by the time the last object is removed from the map,
the g_ModuleCount has dropped to zero, but, there is still code
in AppContainer to be executed, namingly, the code that encompasses
the destructor and the Release method.


0:000> g
Unload module c:\AppDir\AppContainer.dll at 12d70000

ntdll!KiFastSystemCallRet:
7c90eb94 c3 ret
ChildEBP RetAddr Args to Child
0012eb34 7c90e96c 7c91e7d3 ffffffff 12d70000 ntdll!KiFastSystemCallRet
0012eb38 7c91e7d3 ffffffff 12d70000 0012ec7c ntdll!NtUnmapViewOfSection+0xc
0012ec28 7c80abf7 12d70000 0012ec94 0012ee74 ntdll!LdrUnloadDll+0x31a
0012ec3c 77513442 12d70000 0012ee94 77513456 kernel32!FreeLibrary+0x3f
0012ec48 77513456 0012eca0 776067e0 00000000

ole32!CClassCache::CDllPathEntry::CFinishObject::Finish+0x2f


0012ec5c 775135fe 774e1ab0 00000000 00000000

ole32!CClassCache::CFinishComposite::Finish+0x1d


0012ee94 77513578 ffffffff 001460b0 102e7700

ole32!CClassCache::FreeUnused+0x19d


0012eea4 775133a2 ffffffff 00000000 6605a01e
ole32!CoFreeUnusedLibrariesEx+0x36
0012eeb0 6605a01e 08000000 102e766c 0012eee8 ole32!CoFreeUnusedLibraries+0x9
0012eec4 6605b4d1 00ee5314 00000000 102cee44
MSVBVM60!CCreDestroyCtlStruct+0x387
0012eee8 6601c56a 102e73a0 00000000 00000000 MSVBVM60!CCreDestroyCtl+0x195
0012ef2c 6601bc56 015912ac 00000000 660c9ed5 MSVBVM60!CCreFUnloadForm+0x1c9
0012ef38 660c9ed5 102ce6ac 00000009 101f2a70 MSVBVM60!CUnkDesk::Release+0x23
0012ef50 6600e720 0ee94204 77124918 0ee941e8

MSVBVM60!BASIC_CLASS::PRIVATE_UNKNOWN::Release+0x11c


0012ef58 77124918 0ee941e8 0012efc8 0012ef78

MSVBVM60!SCM_MsoStdCompMgr::Release+0xd


0012ef6c 12d75f49 101f2a70 0012f020 101f2a5c OLEAUT32!VariantClear+0xb1

0012efc8 12d715d4 0012f084 101f2a5c 00000000

AppContainer!_variant_t::~_variant_t+0x29 [c:\program files\microsoft visual

studio\vc98\include\comutil.h @ 1736]

0012f02c 12d74b25 0012f0dc 101f2a5c 00000000 AppContainer!std::pair<_bstr_t

const ,_variant_t>::~pair<_bstr_t const ,_variant_t>+0x44

0012f084 12d749b2 00000000 0012f138 101f2a5c AppContainer!std::pair<_bstr_t
const ,_variant_t>::`scalar deletingdestructor'+0x25


0012f0dc 12d73d46 101f2a68 0012f1b0 101f2a5c AppContainer!std::_Destroy+0x22
[c:\program files\microsoft visual studio\vc98\include\xmemory @38]

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


<joh...@gmail.com> wrote in message
news:1172391718.2...@q2g2000cwa.googlegroups.com...

joh...@gmail.com

unread,
Feb 26, 2007, 6:18:50โ€ฏPM2/26/07
to
Ivan,
1) As you can see from the stack trace, the 101f2a70 is pointing to
OLEAUT32!VariantClear, which is correct, the AV occurred when OLEAUT32!
VariantClear is try to clear a COM object which is already released,
So I am suspect the .NET interrop is doing something funky on the COM
object.

2) The COM Object is created with ATL framework, so in the source
code, I do not directly manipulate the g_ModuleCount, I assume you
mean DllCanUnloadNow when you talking about the DllCanUnloadNow , I
actually set the breakpoint at that method, it turns out that the
_Module.GetLockCount() returns 0 when it is called before that AV, so
back to the .NET Interrop again. Because the previous call before the
Release() is mscorwks!ReleaseTransitionHelper+0x5f


The same application has been used without any problem before we
converted part of the application (the one create the two COM
component) to managed code. So the .NET is a primary suspect here...

We are pretty much stuck...

Thanks.

John

SafeReleaseHelper +0x89


0012f518 79f27983 101f24f0 1438bc60 00000001 mscorwks!SafeRelease
+0x2f


0:000> .reload/unl AppContainer.dll

On Feb 26, 10:20 am, "Ivan Brugiolo [MSFT]"

Ivan Brugiolo [MSFT]

unread,
Feb 26, 2007, 9:05:50โ€ฏPM2/26/07
to
You're right, I ment DllCanUnloadNow.
If DllCanUnloadNow returns 0, it means it returned S_OK,
it means that the COM infrastructure is free to unload the module.

For a moment, think outside of the concept of `the code I write`,
but, instead, the rules by which the system runs.
If the module count is positive, and your DLL ges unload by
CoFreeUnusedLibraries, then, there's a bug in the system.
Can you track the value of the module count
(you can set a breakpoint on address to do that)
across your repro ?

BTW, the ATL code does have the problem outlined

template <class Base>
class CComObject : public Base
{
public:
typedef Base _BaseClass;
CComObject(void* = NULL)
{
_Module.Lock();
}
// Set refcount to 1 to protect destruction
~CComObject()
{
m_dwRef = 1L;
FinalRelease();
_Module.Unlock(); <<<<-------------- this is executed before
<<<< the destructor
ATL::CComObject<CPropertyContainer>
}

Can you try to do all the cleanup un FinalRelease ?

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

Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


<joh...@gmail.com> wrote in message
news:1172531930....@p10g2000cwp.googlegroups.com...

joh...@gmail.com

unread,
Feb 27, 2007, 7:17:38โ€ฏPM2/27/07
to
Here is what I did, I change my code as following

STDAPI DllCanUnloadNow(void)
{
wchar_t szMag[2000];
long x=_Module.GetLockCount() ;
wsprintf(szMag,L"_Module.GetLockCount() is %ld ",x);
OutputDebugString(szMag);
return (_Module.GetLockCount()==0) ? S_OK : S_FALSE;
}

The output is Module.GetLockCount() is 0 before the AV

There are two fixes
1) As you suggested, move the clean up code to the FinalRelease fixed
the Av
2) If I change the DllCanUnloadNow to always retrun S_FALS also fix
the AV

What I do not understand is how could the OS unload a dll module while
it is in the process of executing its destructor code??? As you could
see from the following trace, looks like something in MSVBVM60!
CCreDestroyCtl unloaded the AppContainer.dll. but why and how?

Here is the Trace in the in the Rlease()
STDMETHOD_(ULONG, Release)()
{
ULONG l = InternalRelease();
if (l == 0)
delete this;
return l;
}

At the point of
delete this;

I have the following Trace:

ChildEBP RetAddr
0012f448 79e8dbde AppContainer!ATL::CComObject<
CPropertyContaine>::Release+0x2c [c:\program files\microsoft visual


studio\vc98\atl\include\atlcom.h @ 2419]

0012f49c 79e8db4a mscorwks!ReleaseTransitionHelper+0x5f
0012f4e4 79e8dac5 mscorwks!SafeReleaseHelper+0x89
0012f518 79f27983 mscorwks!SafeRelease+0x2f
0012f530 79f2792e mscorwks!RCW::ReleaseAllInterfaces+0x49
0012f560 79f279dc mscorwks!RCW::ReleaseAllInterfacesCallBack+0xbd
0012f590 79f279b0 mscorwks!RCW::Cleanup+0x22
0012f598 79f27997 mscorwks!RCWCleanupList::ReleaseRCWListRaw+0x14
0012f5c8 79f277e5 mscorwks!RCWCleanupList::ReleaseRCWListInCorrectCtx
+0x97
0012f5d8 77525fbe mscorwks!CtxEntry::EnterContextCallback+0x94
0012f5f4 77e7a19c ole32!CRemoteUnknown::DoCallback+0x7a
0012f610 77ef321a RPCRT4!Invoke+0x30
0012fa14 77ef3bf3 RPCRT4!NdrStubCall2+0x297
0012fa6c 77600c31 RPCRT4!CStdStubBuffer_Invoke+0xc6
0012faac 77600bdb ole32!SyncStubInvoke+0x33
0012faf4 7750f237 ole32!StubInvoke+0xa7
0012fbcc 7750f15c ole32!CCtxComChnl::ContextInvoke+0xe3
0012fbe8 7750fc79 ole32!MTAInvoke+0x1a
0012fc14 77600e3b ole32!STAInvoke+0x4a
0012fc48 776009bc ole32!AppInvoke+0x7e
0012fd1c 77600df2 ole32!ComInvokeWithLockAndIPID+0x2e0
0012fd48 7750fcb3 ole32!ComInvoke+0x60
0012fd5c 7750fae9 ole32!ThreadDispatch+0x23
0012fd74 77d48744 ole32!ThreadWndProc+0xfe


0012fda0 77d48826 USER32!InternalCallWinProc+0x28
0012fe08 77d489dd USER32!UserCallWinProcCheckWow+0x150
0012fe68 77d496d7 USER32!DispatchMessageWorker+0x306
0012fe78 6600a4a3 USER32!DispatchMessageA+0xf
0012feb8 6600a41a MSVBVM60!ThunderMsgLoop+0xfd
0012fecc 6600a3bc MSVBVM60!CMsoCMHandler::FPushMessageLoop+0x19
0012fefc 6600a2f8 MSVBVM60!SCM::FPushMessageLoop+0xb9
0012ff18 6600a2c3 MSVBVM60!SCM_MsoCompMgr::FPushMessageLoop+0x2b
0012ff3c 6600361c MSVBVM60!CMsoComponent::PushMsgLoop+0x26
0012ffb8 00404dba MSVBVM60!ThunRTMain+0x9b
0012fff0 00000000 AppMain!__vbaS+0xa


Here is the Trace before the module is unloaded:

ChildEBP RetAddr Args to Child

0012ea2c 7c90e96c 7c91e7d3 ffffffff 68640000 ntdll!KiFastSystemCallRet
0012ea30 7c91e7d3 ffffffff 68640000 0012eba4 ntdll!NtUnmapViewOfSection
+0xc
0012eb20 7c80abf7 68640000 0012ebbc 0012ee74 ntdll!LdrUnloadDll+0x31a
0012eb34 77513442 68640000 0012ee94 77513456 kernel32!FreeLibrary+0x3f
0012eb40 77513456 0012ebc8 776067e0 00000000 ole32!
CClassCache::CDllPathEntry::CFinishObject::Finish+0x2f
0012eb54 775135fe 774e1ab0 00000000 00000000 ole32!
CClassCache::CFinishComposite::Finish+0x1d
0012ee94 77513578 ffffffff 00146080 0fca6b18 ole32!


CClassCache::FreeUnused+0x19d
0012eea4 775133a2 ffffffff 00000000 6605a01e ole32!
CoFreeUnusedLibrariesEx+0x36

0012eeb0 6605a01e 08000000 0fca6a84 0012eee8 ole32!
CoFreeUnusedLibraries+0x9
0012eec4 6605b4d1 00ee5314 00000000 0fc8e094 MSVBVM60!
CCreDestroyCtlStruct+0x387
0012eee8 6601c56a 0fca67b8 00000000 00000000 MSVBVM60!CCreDestroyCtl
+0x195
0012ef2c 6601bc56 000b154a 00000000 660c9ed5 MSVBVM60!CCreFUnloadForm
+0x1c9
0012ef38 660c9ed5 0fc8d8e4 00000009 101f2570 MSVBVM60!CUnkDesk::Release
+0x23
0012ef50 6600e720 137e1024 77124918 137e1008 MSVBVM60!
BASIC_CLASS::PRIVATE_UNKNOWN::Release+0x11c
0012ef58 77124918 137e1008 0012efc8 0012ef78 MSVBVM60!
SCM_MsoStdCompMgr::Release+0xd
0012ef6c 12d75f49 101f2570 0012f020 101f2418 OLEAUT32!VariantClear
+0xb1
0012efc8 12d715d4 0012f084 101f2418 00000000 AppContainer!


_variant_t::~_variant_t+0x29 [c:\program files\microsoft visual studio
\vc98\include\comutil.h @ 1736]

0012f02c 12d74b25 0012f0dc 101f2418 00000000 AppContainer!


std::pair<_bstr_t const ,_variant_t>::~pair<_bstr_t const ,_variant_t>
+0x44

0012f084 12d749b2 00000000 0012f138 101f2418 AppContainer!


std::pair<_bstr_t const ,_variant_t>::`scalar deleting
destructor'+0x25

0012f0dc 12d73d46 101f2568 0012f1b0 101f2418 AppContainer!std::_Destroy


+0x22 [c:\program files\microsoft visual studio\vc98\include\xmemory @
38]

0012f138 12d72cb5 101f2568 0012f21c 0012f22c AppContainer!


std::_Tree<_bstr_t,std::pair<_bstr_t
const ,_variant_t>,std::map<_bstr_t,_variant_t,std::less<_bstr_t>,std::allocator<_variant_t>
>::_Kfn,std::less<_bstr_t>,std::allocator<_variant_t> >::_Destval+0x26
[c:\program files\microsoft visual studio\vc98\include\xtree @ 585]

0012f1bc 12d78f2d 0012f278 101f2418 0012f2a8 AppContainer!


std::_Tree<_bstr_t,std::pair<_bstr_t
const ,_variant_t>,std::map<_bstr_t,_variant_t,std::less<_bstr_t>,std::allocator<_variant_t>
>::_Kfn,std::less<_bstr_t>,std::allocator<_variant_t> >::erase+0x825
[c:\program files\microsoft visual studio\vc98\include\xtree @ 359]

0012f21c 12d78bf4 0012f278 101f2558 0012f318 AppContainer!


std::map<_bstr_t,_variant_t,std::less<_bstr_t>,std::allocator<_variant_t>
>::erase+0x2d [c:\program files\microsoft visual studio\vc98\include
\map @ 104]

0012f2c0 12d78971 0012f37c 0017a958 00000000 AppContainer!
CPropertyContainer::RemoveMapObject+0x224 [c:\mks\fw13dev\source
\AppContainer\cpropertycontainer.h @ 146]
0012f324 12d79d9d 0012f3e0 0017a958 00000000 AppContainer!
CPropertyContainer::~CPropertyContainer+0x41 [c:\mks\fw13dev\source
\AppContainer\cpropertycontainer.h @ 162]
0012f388 12d77565 0012f448 0017a958 00000000 AppContainer!


ATL::CComObject<CPropertyContainer>::~CComObject<CPropertyContainer>

+0x6d [c:\program files\microsoft visual studio\vc98\atl\include
\atlcom.h @ 2411]
0012f3e0 12d79e78 00000001 00000000 0017a958 AppContainer!


ATL::CComObject<CPropertyContainer>::`scalar deleting destructor'+0x25

0012f448 79e8dbde 101f2270 7ad569e4 00000008 AppContainer!


ATL::CComObject<CPropertyContainer>::Release+0x48 [c:\program files
\microsoft visual studio\vc98\atl\include\atlcom.h @ 2419]

0012f49c 79e8db4a 101f2270 7ad5699c 00000008 mscorwks!
ReleaseTransitionHelper+0x5f
0012f4e4 79e8dac5 101f2270 0dd8e560 7ad56860 mscorwks!SafeReleaseHelper
+0x89
0012f518 79f27983 101f2270 0dd8e560 00000001 mscorwks!SafeRelease+0x2f
0012f530 79f2792e 7ad56818 00000001 0dd8e560 mscorwks!
RCW::ReleaseAllInterfaces+0x49
0012f560 79f279dc 0dd8e560 7ad568e8 00000001 mscorwks!
RCW::ReleaseAllInterfacesCallBack+0xbd
0012f590 79f279b0 01a1fb7c 79f27997 139126a0 mscorwks!RCW::Cleanup
+0x22
0012f598 79f27997 139126a0 7ad568b0 0012f5e4 mscorwks!
RCWCleanupList::ReleaseRCWListRaw+0x14
0012f5c8 79f277e5 001466a8 001466a8 0012f5f4 mscorwks!
RCWCleanupList::ReleaseRCWListInCorrectCtx+0x97
0012f5d8 77525fbe 01a1fa18 0012f5f8 0012f620 mscorwks!
CtxEntry::EnterContextCallback+0x94
0012f5f4 77e7a19c 0015b2f8 001d5848 02020202 ole32!
CRemoteUnknown::DoCallback+0x7a
0012f610 77ef321a 77525f83 0012f624 00000002 RPCRT4!Invoke+0x30
0012fa14 77ef3bf3 0015ef78 0015d3a0 001d28bc RPCRT4!NdrStubCall2+0x297
0012fa6c 77600c31 0015ef78 001d28bc 0015d3a0 RPCRT4!
CStdStubBuffer_Invoke+0xc6
0012faac 77600bdb 001d28bc 001d52e4 00000000 ole32!SyncStubInvoke+0x33
0012faf4 7750f237 001d28bc 0015d2b8 0015ef78 ole32!StubInvoke+0xa7
0012fbcc 7750f15c 0015d3a0 00000000 0015ef78 ole32!
CCtxComChnl::ContextInvoke+0xe3
0012fbe8 7750fc79 001d28bc 00000001 0015ef78 ole32!MTAInvoke+0x1a
0012fc14 77600e3b 001d28bc 00000001 0015ef78 ole32!STAInvoke+0x4a
0012fc48 776009bc 001d2868 0015d3a0 0015ef78 ole32!AppInvoke+0x7e
0012fd1c 77600df2 001d2868 0015d600 00000000 ole32!
ComInvokeWithLockAndIPID+0x2e0
0012fd48 7750fcb3 001d2868 00000400 001464a8 ole32!ComInvoke+0x60
0012fd5c 7750fae9 001d2868 0012fddc 7750fa56 ole32!ThreadDispatch+0x23
0012fd74 77d48744 003f024a 00146080 0000babe ole32!ThreadWndProc+0xfe
0012fda0 77d48826 7750fa56 003f024a 00000400 USER32!InternalCallWinProc
+0x28
0012fe08 77d489dd 00000000 7750fa56 003f024a USER32!


UserCallWinProcCheckWow+0x150
0012fe68 77d496d7 0012fe90 00000001 0012feb8 USER32!
DispatchMessageWorker+0x306
0012fe78 6600a4a3 0012fe90 ffffffff 00e0379c USER32!DispatchMessageA
+0xf
0012feb8 6600a41a ffffffff 00e037c4 00e00000 MSVBVM60!ThunderMsgLoop
+0xfd
0012fecc 6600a3bc 00e0379c ffffffff 00e03894 MSVBVM60!
CMsoCMHandler::FPushMessageLoop+0x19

0012fefc 6600a2f8 00e03894 ffffffff 00000f50 MSVBVM60!


SCM::FPushMessageLoop+0xb9
0012ff18 6600a2c3 00e037c0 00e03894 ffffffff MSVBVM60!
SCM_MsoCompMgr::FPushMessageLoop+0x2b

0012ff3c 6600361c ffffffff 00e3d0b8 00000018 MSVBVM60!
CMsoComponent::PushMsgLoop+0x26
0012ffb8 00404dba 004051e4 7c816fd7 00e3d0b8 MSVBVM60!ThunRTMain+0x9b


0012fff0 00000000 00404db0 00000000 78746341 AppMain!__vbaS+0xa

On Feb 26, 6:05 pm, "Ivan Brugiolo [MSFT]"

Ivan Brugiolo [MSFT]

unread,
Feb 27, 2007, 9:11:58โ€ฏPM2/27/07
to
I'm glad that moving the code in FinalRelease fixed the problem.
Your scenario is exactly the scenario why that FinalRelease method
was exposed to the user of the ATL library.

I don't know much about VB, but, I can immagine
that VB is creating an interceptor for every interface pointer
it has knowledge of, and, the VB code is trying to call
CoFreeUnusedLibraries() after it has released the
intercepted interface poitner, in order to flush the
COM cache of in-proc components.

The OS does exactly what it's supposed to do.
When CoFreeUnusedLibraries is called,
any DLL whose DllCanUnloadNow returns S_OK
is elegibile to be unloaded.
That's why you should decrement the module refcont
at the very-very-very last moment.
OLE32 knows that your destructor can still be executing,
and, it employes a delayed-unloading scheme.
Only CoFreeUnusedLibrariesEx(dwUnloadDelay = 0)
causes the immediate unload, and, this is not the default
behavior, and, it's done to compensate for the problem
you have been victim.

As a final consideration, I have seen your problem
quite a few times, and, it's normally exposed by a multithreaded
application with many apartments that comes and goes,
since the Apartment cleanup code normally calls CoFreeUnusedLibraries.

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

Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


<joh...@gmail.com> wrote in message
news:1172621858.7...@j27g2000cwj.googlegroups.com...

joh...@gmail.com

unread,
Feb 27, 2007, 10:54:44โ€ฏPM2/27/07
to
Thanks a lot for all your help. you are correct, I put a breakpoint at
CoFreeUnusedLibraries and sure enough, the VB runtime is calling it.
one final question, do you know where is a good resource or books on
windbg? the online help is useful but it is very brief and not very
detail..

On Feb 27, 6:11 pm, "Ivan Brugiolo [MSFT]"

> Use of any included script samples are subject to the terms specified athttp://www.microsoft.com/info/cpyright.htm
>
> <john...@gmail.com> wrote in message
>

> ...
>
> read more ยป- Hide quoted text -

mgsram

unread,
Feb 28, 2007, 9:24:53โ€ฏAM2/28/07
to
John,
I looked at the original post. Per my understanding you are using .NET
as a mediator. You create ATLObject1 and store it in ATLObject2. In
such a scenario, I think the correct thing to do is add an explicit
AddRef of ATLObject1 in ATLObject2. Using .NET as a mediator does not
gaurantee that reference counting will be done by CCW/RCW for usage.
If you are facing problems with finalizers then its a different thing

Ben Voigt

unread,
Mar 1, 2007, 6:32:37โ€ฏPM3/1/07
to
> Here is the Trace in the in the Rlease()
> STDMETHOD_(ULONG, Release)()
> {
> ULONG l = InternalRelease();
> if (l == 0)
> delete this;
> return l;
> }

If you addref the module on behalf of this function, does that help? One
reasonable alternative could be:

set global flag causing DllCanUnloadNow to return false (using
InterlockedIncrement)


InternalRelease();
if (l == 0)
delete this;

if (Module.GetLockCount() == 0)
{
LoadLibrary self
CreateThread cleanup handler
}
InterlockedDecrement global flag set in first step
return l

Now, even if the client calls CoUnloadUnusedLibraries, there's no race,
because the module has locked itself with LoadLibrary

The cleanup handler just calls FreeLibraryAndExitThread which is designed to
eliminate this race.


0 new messages