Re: Mixed .Net process dies without a trace: Fatal Execution Engine Error (7A103E78) (800703e9)

Is there anything in the parameters in the B->C call (managed->unmanaged) t=
hat might be on the stack and get corrupted? If there was a GC and somethin=
g turned out to be not pinned (for example) I'm wondering if you could get =
stack corruption that might show up as stack overflow.

My COM is rusty, but I don't think a peek in the message queue is unusual. =
If there are callbacks in a STA then they'll go into the message queue and =
COM will look for them there with the same id as the original outgoing call=
. I don't know if it uses that mechanism for its own internal reasons. =


Phil Wilson =



-----Original Message-----
From: Discussion of advanced .NET topics. [mailto:[email protected]=
E.LSOFT.COM] On Behalf Of Peter vd Weerd
Sent: Tuesday, December 15, 2009 11:10 PM
To: [email protected]
Subject: Re: [ADVANCED-DOTNET] Mixed .Net process dies without a trace: Fat=
al Execution Engine Error (7A103E78) (800703e9)

No, thats the strange thing here. =

CBD sees 2 first chance access violations that are handled by the CLR, whic=
h seem to be normal, since I see that in other apps too. The last dump beei=
ng created was a '1st_chance_CONTRL_C_OR_Debug_Break'

However, Visual studio saw a StackOverflowException. But a look at the regi=
sters did made me suspicious if this was a real stackoverflow...

However, I violated rule #1: "Never change more than 1 thing at once" :-). =

I included some DebugOut's in my code, to trace the IUnknown-interaction, a=
nd now VS also sees a breakpoint.
The DebugBreak was issued by the CLR. But no debugger-output....

Luckely, the msg in the eventlog is stable: Fatal Execution Engine Error (7=
A103E78) (800703e9)

Later this day I'll try to reproduce the original error.

Thanks,
P


----- Original Message ----- =

From: "Steve Johnson" <[email protected]>
To: <[email protected]>
Sent: Wednesday, December 16, 2009 2:10 AM
Subject: Re: [ADVANCED-DOTNET] Mixed .Net process dies without a trace: Fat=
al Execution Engine Error (7A103E78) (800703e9)


> Did you dump on a 1st chance Stack Overflow?
> =

> --
> Steve Johnson
> =

> On Tue, Dec 15, 2009 at 6:29 PM, Peter vd Weerd <[email protected]> wrote=
:
> =

>> What I checked is that the stack doesn't grow.
>> The ESP is exactly the same during the 1st calls...
>>
>> /P
>>
>> ----- Original Message ----- From: "Mark Hurd" <[email protected]>
>>
>> To: <[email protected]>
>> Sent: Wednesday, December 16, 2009 12:23 AM
>> Subject: Re: [ADVANCED-DOTNET] Mixed .Net process dies without a trace:
>> Fatal Execution Engine Error (7A103E78) (800703e9)
>>
>>
>>
>> Given that, if you can put a break point inside C, see if there /is/
>> any difference between the first and second successful attempts. It
>> could be a problem that gets worse before failing completely.
>> (Unlikely, of course.)
>>
>> --
>> Regards,
>> Mark Hurd, B.Sc.(Ma.)(Hons.)
>>
>>
>> On Wed, Dec 16, 2009 at 9:39 AM, Peter vd Weerd <[email protected]> wrot=
e:
>>
>>> Wait, forgot to tell.
>>> The sequence A-->B-->C doesn't kill the process immediately. The first =
2
>>> times it works fine. But the 3rd time it dies...
>>>
>>> ----- Original Message ----- From: "Peter vd Weerd" <[email protected]>=

>>> To: <[email protected]>
>>> Sent: Wednesday, December 16, 2009 12:05 AM
>>> Subject: [ADVANCED-DOTNET] Mixed .Net process dies without a trace: Fat=
al
>>> Execution Engine Error (7A103E78) (800703e9)
>>>
>>>
>>> Hi experts,
>>>
>>> I have an COM-interop problem.
>>> The host is a C++ COM-component (A), which loads a .Net object (B) that=
 is
>>> comvisible.
>>> A method in this .Net object is called and loads a different C++
>>> COM-component (C).
>>>
>>> So: A-->B-->C.
>>>
>>> All the C++ COM-components are threadsave and support the freethreaded
>>> marshaler.
>>> They are registered with threadingmode=3Dboth. The whole thing runs on =
a
>>> STA-thread.
>>>
>>> In some situations, the application dies without a trace, and a msg is =
in
>>> the eventlog:
>>> .NET Runtime version 2.0.50727.3082 - Fatal Execution Engine Error
>>> (7A103E78) (800703e9)
>>>
>>> 800703e9 means: stackoverflow.
>>>
>>> When I run it from Visual studio, I stops in the call from B to C, inde=
ad
>>> with a stackoverflow, but I can't see any unmanaged code (DLL's are not=

>>> written in MS C++).
>>>
>>> So I used ADPlus in crash-mode to generate some dumps, and investigate
>>> there.
>>> The last thing I can see there is a DebugBreak.
>>> The stacktrace is below.
>>> It looks like the CLR does some marshaling magic and peeks the msg queu=
e.
>>> I
>>> didn't expect that because of the FT marshaller.
>>> Furthermore, if I put a MessageBox in the .Net code, just before the ca=
ll
>>> to
>>> C, everything works fine. So my feeling is that it has something to do
>>> with
>>> marshaling and timing.
>>> But I can't get my finger on the right place.
>>>
>>> Any idea's? Any pointers where to look? Thanks a lot.
>>>
>>> Peter
>>>
>>>
>>> The stacktrace is:
>>> (By the way, igor is my 'A' component, the stack doesn't show any code =
of
>>> the 'C' component.
>>> And although the method in C wasn't executed, there has been a lot of
>>> QueryInterfaces, AddRefs, etc in that 'C' component.)
>>>
>>> 037bc278 7a096467 037bc71c 79f7762b 3ab9eb41 ntdll!DbgBreakPoint
>>> 037bc728 7a096796 800703e9 7a103e78 00000000
>>> mscorwks!EEPolicy::LogFatalError+0x2b5
>>> 037bc740 7a103e83 800703e9 7a103e78 00000000
>>> mscorwks!EEPolicy::HandleFatalError+0x4d
>>> 037bc768 7a0bd9a9 3ab9ebd1 071f8a98 037becd4
>>> mscorwks!Thread::RestoreGuardPage+0xb7
>>> 037bc7b8 79f4c30c 037becd4 3ab9eb95 071f8a98
>>> mscorwks!ReleaseTransitionHelper+0x103
>>> 037bc7fc 79f4c370 037becd4 071f8a78 3ab9e459
>>> mscorwks!SafeReleaseHelper+0x8c
>>> 037bc830 79faa892 037becd4 071f8a78 00000001 mscorwks!SafeRelease+0x2f
>>> 037bc848 79faa9ad 3ab9e411 00000001 071f8a78
>>> mscorwks!RCW::ReleaseAllInterfaces+0x48
>>> 037bc878 79faa9d9 071f8a78 3ab9e4c1 00000001
>>> mscorwks!RCW::ReleaseAllInterfacesCallBack+0xbd
>>> 037bc8a8 7a079480 16effb74 037bc8e4 7a0798e8 mscorwks!RCW::Cleanup+0x22=

>>> 037bc8b4 7a0798e8 071f9100 3ab9e48d 037bc900
>>> mscorwks!RCWCleanupList::ReleaseRCWListRaw+0x16
>>> 037bc8e4 7a043f25 000a0800 000a0800 037bc910
>>> mscorwks!RCWCleanupList::ReleaseRCWListInCorrectCtx+0xdf
>>> 037bc8f4 77525834 16effa10 037bc914 037bc93c
>>> mscorwks!CtxEntry::EnterContextCallback+0x89
>>> 037bc910 77e799f4 0bd8ed80 0bd8e930 02020202
>>> ole32!CRemoteUnknown::DoCallback+0x7a
>>> 037bc92c 77ef421a 775257f9 037bc940 00000002 rpcrt4!Invoke+0x30
>>> 037bcd30 77ef4bf3 0bd845f8 0bd8f170 000d53b8 rpcrt4!NdrStubCall2+0x297
>>> 037bcd88 77600c15 0bd845f8 000d53b8 0bd8f170
>>> rpcrt4!CStdStubBuffer_Invoke+0xc6
>>> 037bcdc8 77600bbf 000d53b8 0bdb5ff4 00000000 ole32!SyncStubInvoke+0x33
>>> 037bce10 7752ad31 000d53b8 071e9428 0bd845f8 ole32!StubInvoke+0xa7
>>> 037bcee8 7752ac56 0bd8f170 00000000 0bd845f8
>>> ole32!CCtxComChnl::ContextInvoke+0xe3
>>> 037bcf04 7752b771 000d53b8 00000001 0bd845f8 ole32!MTAInvoke+0x1a
>>> 037bcf30 77600e1f 000d53b8 00000001 0bd845f8 ole32!STAInvoke+0x4a
>>> 037bcf64 77602df3 000d5360 0bd8f170 0bd845f8 ole32!AppInvoke+0x7e
>>> 037bd038 77600dd6 000d5360 0007b818 00000000
>>> ole32!ComInvokeWithLockAndIPID+0x2c2
>>> 037bd064 7752b7ab 000d5360 00000400 000cc000 ole32!ComInvoke+0x60
>>> 037bd078 7752b5e1 000d5360 037bd0f8 7752b54e ole32!ThreadDispatch+0x23
>>> 037bd090 7e418734 00080944 00056128 0000babe ole32!ThreadWndProc+0xfe
>>> 037bd0bc 7e418816 7752b54e 00080944 00000400
>>> user32!InternalCallWinProc+0x28
>>> 037bd124 7e4189cd 00000000 7752b54e 00080944
>>> user32!UserCallWinProcCheckWow+0x150
>>> 037bd184 7e418a10 037bd1a8 00000000 037bd1c4
>>> user32!DispatchMessageWorker+0x306
>>> 037bd194 7752f2d0 037bd1a8 00000102 037bd208 user32!DispatchMessageW+0x=
f
>>> 037bd1c4 7752f10d 80010115 80010115 00000000
>>> ole32!CCliModalLoop::PeekRPCAndDDEMessage+0x4c
>>> 037bd1d8 77557237 037bd40c 00000001 037bd204
>>> ole32!CCliModalLoop::BlockFn+0x5e
>>> 037bd24c 79f9e14d 00000002 00000001 00000001
>>> ole32!CoWaitForMultipleHandles+0xcf
>>> 037bd26c 79f9e0b4 00000000 00000001 00000001 mscorwks!NT5WaitRoutine+0x=
51
>>> 037bd2d8 79f9e018 00000001 037bd40c 00000000 mscorwks!MsgWaitHelper+0xa=
5
>>> 037bd2f8 79f4c664 00000001 037bd40c 00000000
>>> mscorwks!Thread::DoAppropriateAptStateWait+0x28
>>> 037bd37c 79f4c6f9 00000001 037bd40c 00000000
>>> mscorwks!Thread::DoAppropriateWaitWorker+0x13c
>>> 037bd3cc 79f90c76 00000001 037bd40c 00000000
>>> mscorwks!Thread::DoAppropriateWait+0x40
>>> 037bd41c 79ef018c 00000001 0bd56d70 037bd47c mscorwks!Thread::JoinEx+0x=
86
>>> 037bd42c 7a079b7c 00000001 00000001 3ab9f815 mscorwks!Thread::Join+0x14=

>>> 037bd47c 79faa55f 00000001 037bd4cc 79faa5c8
>>> mscorwks!RCWCleanupList::CleanupWrappersInCurrentCtxThread+0x15a
>>> 037bd488 79faa5c8 0721495c 037bd52c 3ab9f8a5 mscorwks!RCW::Initialize+0=
x78
>>> 037bd4cc 79faa25f 0721495c 037bd52c 3ab9f955 mscorwks!RCW::CreateRCW+0x=
84
>>> 037bd53c 79faa36d 00000000 037bd578 3ab9f9e1
>>> mscorwks!COMInterfaceMarshaler::CreateObjectRef+0x45
>>> 037bd588 79f9d0f8 3ab9f62d 037bdce4 037bdce4
>>> mscorwks!COMInterfaceMarshaler::FindOrCreateObjectRef+0xac
>>> 037bda44 79f9d294 072148e8 058e6918 00000001
>>> mscorwks!GetObjectRefFromComIP+0x1ec
>>> 037bda64 79f9d2fb 000c3940 072148e8 058e5bb0
>>> mscorwks!UnmarshalObjectFromInterface+0x19
>>> 037bda80 79fb5089 037bdce4 037bdcc8 79fb5079
>>> mscorwks!InterfaceMarshalerBase::ConvertSpaceNativeToCLR+0x30
>>> 037bda8c 79fb5079 037bdf70 037bdf60 3ab9f0a1
>>>
>>> mscorwks!DefaultMarshalOverrides<InterfaceMarshalerBase>::ReturnCLRFrom=
NativeRetval+0xb
>>> 037bdcc8 79f139af 058da2d3 037bdf5c 037bdf74 mscorwks!RunML+0x9ac
>>> 037bdfa8 058da28e 0bd56d70 037bdffc 3987259a mscorwks!CLRToCOMWorker+0x=
25f
>>> WARNING: Frame IP not in any known module. Following frames may be wron=
g.
>>> 037bdfe4 05a8313f 1200e4d0 1200ec7c 11f0d990 0x58da28e
>>> 037be11c 79f68c32 057a26cc 0bd56d70 00000000 0x5a8313f
>>> 037be20c 79f68deb 0bd56d70 037be404 037be47c
>>> mscorwks!COMToCLRWorkerBody+0x115
>>> 037be268 79f68f54 0bd56d70 037be404 037be47c
>>> mscorwks!COMToCLRWorkerDebuggerWrapper+0x37
>>> 037be43c 058da706 0bd56d70 037be47c 3987259a mscorwks!COMToCLRWorker+0x=
157
>>> *** WARNING: Unable to verify checksum for igor022.dll
>>> *** ERROR: Symbol file could not be found. Defaulted to export symbols =
for
>>> igor022.dll -
>>> 037be464 0a50defc 0ae26b88 037beecc 0add0020 0x58da706
>>> 037be49c 0a50e58c 0add0020 037beecc 037beecc igor022!taoDeleteFiles+0x4=
7ac
>>> 037be4b4 0a510c1c 0ad99a74 037beecc 00000001 igor022!taoDeleteFiles+0x4=
e3c
>>> 037be504 0a4fcece 0ad319b0 037beecc 0ad319b0 igor022!taoDeleteFiles+0x7=
4cc
>>> 037bf35c 0a4fca96 0ad306a8 00000000 00000002 igor022!PtrToInt+0xbbd2e
>>> 037bf4a8 0a4fc68f 0ad306a8 0a5f2148 00000003 igor022!PtrToInt+0xbb8f6
>>> 037bf500 0a5302f3 0ad306a8 0bad5ef0 00000003 igor022!PtrToInt+0xbb4ef
>>>
>>
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> View archives and manage your subscription(s) at
>> http://peach.ease.lsoft.com/archives
>>
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> View archives and manage your subscription(s) at
>> http://peach.ease.lsoft.com/archives
>>
> =

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> View archives and manage your subscription(s) at http://peach.ease.lsoft.=
com/archives

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
View archives and manage your subscription(s) at http://peach.ease.lsoft.co=
m/archives



*** Confidentiality Notice: This e-mail, including any associated or attach=
ed files, is intended solely for the individual or entity to which it is ad=
dressed. This e-mail is confidential and may well also be legally privilege=
d. If you have received it in error, you are on notice of its status. Pleas=
e notify the sender immediately by reply e-mail and then delete this messag=
e from your system. Please do not copy it or use it for any purposes, or di=
sclose its contents to any other person. This email comes from a division o=
f the Invensys Group, owned by Invensys plc, which is a company registered =
in England and Wales with its registered office at Portland House, Bressend=
en Place, London, SW1E 5BF (Registered number 166023). For a list of Europe=
an legal entities within the Invensys Group, please go to http://www.invens=
ys.com/legal/default.asp?top_nav_id=3D77&nav_id=3D80&prev_id=3D77. You may =
contact Invensys plc on +44 (0)20 7821 3848 or e-mail inet.hqhelpdesk@inven=
sys.com. This e-mail and any attachments thereto may be subject to the term=
s of any agreements between Invensys (and/or its subsidiaries and affiliate=
s) and the recipient (and/or its subsidiaries and affiliates).

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives