I have a multi-threaded application using both managed (C#/.NET) and
unmanaged code (C++). The unmanaged code calls into the manage code
(via COM Interop) to perform a variety of tasks. Every two or three
days the application would unexpectedly crash; I added a GC.Collect()
call to the end of every method in the module in question and now the
problem happens 4 -5 time a day. Some debug information from WinDbg is
below. I'm currently looking at the code to ensure thread-safety,
but other than that I don't have a clear direction to take.

Any help, insight, or other resources are appreciated.

Thanks,
Mark

Wed May 10 13:17:24.046 2006 (GMT-5): (2cc.818): Access violation -
code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=4507e1c4 ebx=00000006 ecx=f7d53fa9 edx=361ee308 esi=00000000
edi=15b1f3fc
eip=79212122 esp=361ee744 ebp=361ee74c iopl=0 nv up ei pl nz na
pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00010202
mscorwks!GCHeap::Promote+0x8:
79212122 8b30 mov esi,[eax]
ds:0023:4507e1c4=????????


mscorwks!GCHeap::Promote+0x8
mscorwks!ComMethodFrame::PromoteCalleeStack+0xb9
mscorwks!ComMethodFrame::GcScanRoots+0x11
mscorwks!GCStackCrawlCallBack+0x45
mscorwks!Thread::StackWalkFramesEx+0x316
mscorwks!Thread::StackWalkFrames+0x8b
mscorwks!CNameSpace::GcScanRoots+0x7b
mscorwks!gc_heap::mark_phase+0xd7
mscorwks!gc_heap::gc1+0x96
mscorwks!gc_heap::garbage_collect+0x1bf
mscorwks!GCHeap::GarbageCollectGeneration+0x11b
mscorwks!GCHeap::GarbageCollect+0x4a
mscorwks!GCInterface::CollectGeneration+0xf
WARNING: Frame IP not in any known module. Following frames may be
wrong.
0x15e032b6
Mscorwks!ComCallMLStubCache::CompileMLStub+0x674
0x5b9a1fd
BTJ!InspectionStation:ickupCompleted(class BSEvent * prBSEvent)

Hi,
It is a not good idea to call GC.Collect because the GC in .NET
Framework is self-tuned. This is might affect the way in which GC
works.

And Access Violation exceptions are Null reference exception in managed
world (the first chance). From what you have posted it looks like first
chance. You would probably want to dump memory in second chance to get
the exact cause.

Also check for exception (!dae) and !analyze -v should give the info.
Incase if you have a second chance of AV exception then KB & !u eip
could possibly give you some insights.

Do you call your unmanaged code with IntPtr referencing memory allocated in
the managed heap?

If it's the case, you have to pin the memory by calling
GCHandle.Alloc(object, GCHandleType.Pinned). Pinning the memory disallows
the garbage collector to move these blocks.

Lionel Schiepers.


"Mark" <mhdostal (AT) gmail (DOT) com> wrote