ESRI Map control freezes or crushes

[MaorHayun]

Hi,

I have a MapControl version 10 that sometimes on load layers or just refreshing the map,it stuck on finalizer thread probably tring to release an instance of an STA COM component, and it is stuck waiting for the STA thread to become available. second scenario is my application just crushed an i get unhandled exception of access violation.

I see that the main STA thread is probably stuck and prevents from other threads to execute right.
Have any of you encountered this type of problem?

look at the dump analysis below. (I did not put access violation exception), It looks like all the other thread waiting to the STA.
Thanks Uri.

Thread 16 - System ID 3476
Entry point   0x00000000
Create time   4/2/2012 1:45:18 PM
Time spent in user mode   0 Days 00:00:00.00
Time spent in kernel mode   0 Days 00:00:00.00

Function   Source
ntdll!NtWaitForSingleObject+15   
KERNELBASE!WaitForSingleObjectEx+98   
kernel32!WaitForSingleObjectExImplementation+75   
kernel32!WaitForSingleObject+12   
BasemapLayer+5100e   
BasemapLayer+4fa4b   
msvcr90!_callthreadstartex+1b   f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c @ 348 + 6
msvcr90!_threadstartex+69   f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c @ 326 + 5
kernel32!BaseThreadInitThunk+e   
ntdll!__RtlUserThreadStart+70   
ntdll!_RtlUserThreadStart+1b


Thread 2 - System ID 5188
Entry point   0x00000000
Create time   4/2/2012 1:45:11 PM
Time spent in user mode   0 Days 00:00:01.326
Time spent in kernel mode   0 Days 00:00:00.109

This thread is making a COM call to thread 9 within the same process
Full Call Stack

Function   Source
ntdll!NtWaitForSingleObject+15   
KERNELBASE!WaitForSingleObjectEx+98   
kernel32!WaitForSingleObjectExImplementation+75   
kernel32!WaitForSingleObject+12   
ole32!GetToSTA+ad    ole32!CRpcChannelBuffer::SwitchAptAndDispatchCall+140   
ole32!CRpcChannelBuffer::SendReceive2+ef   
ole32!CAptRpcChnl::SendReceive+af   
ole32!CCtxComChnl::SendReceive+1c5   
ole32!NdrExtpProxySendReceive+49   
rpcrt4!NdrpProxySendReceive+e   
rpcrt4!NdrClientCall2+1a6   
ole32!ObjectStublessClient+a2   
ole32!ObjectStubless+f   
ole32!RemoteReleaseRifRefHelper+a5   
ole32!RemoteReleaseRifRef+b0   
ole32!CStdMarshal::DisconnectCliIPIDs+2ec   
ole32!CStdMarshal::Disconnect+1ba   
ole32!CStdIdentity::~CStdIdentity+8c   
ole32!CStdIdentity::`vector deleting destructor'+d   
ole32!CStdIdentity::CInternalUnk::Release+6e   
ole32!IUnknown_Release_Proxy+11   
clr!ReleaseTransitionHelper+e   
clr!SafeReleaseHelper+87   
clr!SafeRelease+2f   
clr!RCW::ReleaseAllInterfaces+4b   
clr!RCW::ReleaseAllInterfacesCallBack+c4   
clr!RCW::Cleanup+22   
clr!RCWCleanupList::ReleaseRCWListRaw+18   
clr!RCWCleanupList::ReleaseRCWListInCorrectCtx+10a   
clr!RCWCleanupList::CleanupAllWrappers+83   
clr!SyncBlockCache::CleanupSyncBlocks+de   
clr!Thread::DoExtraWorkForFinalizer+3b   
clr!WKS::GCHeap::FinalizerThreadWorker+9d   
clr!Thread::DoExtraWorkForFinalizer+114   
clr!Thread::ShouldChangeAbortToUnload+101   
clr!Thread::ShouldChangeAbortToUnload+399   
clr!ManagedThreadBase_NoADTransition+35   
clr!ManagedThreadBase::FinalizerBase+f   
clr!WKS::GCHeap::FinalizerThreadStart+10c   
clr!Thread::intermediateThreadProc+4b   
kernel32!BaseThreadInitThunk+e   
ntdll!__RtlUserThreadStart+70   
ntdll!_RtlUserThreadStart+1b