We are developing .NET components that are used through COM from a COM client written in VisualAge Smalltalk V7.0.

We experience a system crash (access violation; error code C0000005) when the Smalltalk client calls a .NET method that internally calls the .NET method XPathExpression.Compile(string xpath, System.Xml.IxmlNamespaceResolver resolver) (e.g. through calls to the .NET methods XmlDocument.SelectSingleNode(string xPath) or XmlDocument.SelectNodes(string xPath) ).

Further investigation with WinDBG and the "Son of Strike" debug extension showed, that the access violation exception is preceeded by many “Undefined exceptions C0000090�(EXCEPTION_FLT_INVALID_OPERATION?). The first of these C000090 exceptions happens in the function EEHeapAllocInProcessHeap() in mscorwks.dll.
The .NET method XPathExpression.Compile() seems to trigger some “just-in-time�compilation inside the .NET CLR, and this compilation tries to allocate dynamic memory which calls EEHeapAllocInProcessHeap(). This memory allocation fails with the mentioned C0000090 exception. This exception seems to be handled, but the exception handler throws another C0000090 exception, which leads to an infinite loop and finally to a stack overflow and the access violation.

The problem only happens with a VisualAge Smalltalk COM client, but not if we use exactly the same .NET COM server with a C++ orVB COM client. Another strange thing is, that if some other other method, that is called before the call to XPathExpression.Compile(), throws a .NET exception (even throwing a System.Exception on purpose) , then the crash doesn't happen either.

Although the problem seems to be somehow related to the hosting Smalltalk process, we wonder whether a similar problem was already observed in a different context.
Under what circumstances will EEHeapAllocInProcessHeap() throw an exception 0xC0000090?
Is it a known problem that the exception handler for this exception may cause an endless loop?

We are using Windows XP with SP2, the .NET COM component uses .NET Framework 2.0.

Any help is appreciated!

Thanks in advance,
Ute

Beginning of the WinDbg stack dump of the first exception:
(ebc.32c): Unknown exception - code c0000090 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00216b28 ebx=00000000 ecx=79e74540 edx=00000078 esi=00000001 edi=0012da28
eip=79e78305 esp=0012d9a8 ebp=0012d9d8 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206
mscorwks!EEHeapAllocInProcessHeap+0x1d:
79e78305 d905e8a5e779 fld dword ptr [mscorwks!_real (79e7a5e8)] ds:0023:79e7a5e8=3e800000
0:000> !dumpstack
OS Thread Id: 0x32c (0)
Current frame: mscorwks!EEHeapAllocInProcessHeap+0x1d
ChildEBP RetAddr Caller,Callee
0012d9a4 79e78414 mscorwks!operator new+0x2b, calling mscorwks!EEHeapAllocInProcessHeap
0012d9d8 79e98223 mscorwks!ZapperModule::allocateArray+0x9, calling mscorwks!operator new[]
0012d9e0 79e9a27e mscorwks!CEEInfo::allocateArray+0xe3
0012da54 790624b2 mscorjit!Compiler::eeSetLIcount+0x27
0012da64 7906cb3c mscorjit!Compiler::genIPmappingGen+0x65, calling mscorjit!Compiler::eeSetLIcount
0012da80 7906d085 mscorjit!Compiler::genGenerateCode+0xd5, calling mscorjit!Compiler::genIPmappingGen
0012db44 7906dfce mscorjit!Compiler::compCompile+0x160, calling mscorjit!Compiler::genGenerateCode
0012db68 7906ebee mscorjit!Compiler::compCompile+0x2d8, calling mscorjit!Compiler::compCompile
0012dbc0 7906e8db mscorjit!jitNativeCode+0xb8, calling mscorjit!Compiler::compCompile
0012dbfc 79e7da05 mscorwks!TypeSecurityDescriptor::ComputeCriticalTransparentInfo+0x36, calling mscorwks!ModuleSecurityDescriptor::VerifyDataComputed
0012dc10 79e7d9b5 mscorwks!TypeSecurityDescriptor::ComputeTypeDeclarativeSecurityInfo+0xab, calling mscorwks!_EH_epilog3
0012dc54 7906e831 mscorjit!CILJit::compileMethod+0x3d, calling mscorjit!jitNativeCode
0012dc8c 79e9776f mscorwks!invokeCompileMethodHelper+0x72
0012dcf8 79e976e5 mscorwks!invokeCompileMethod+0x31, calling mscorwks!invokeCompileMethodHelper
0012dd3c 79e9767a mscorwks!CallCompileMethodWithSEHWrapper+0x84, calling mscorwks!invokeCompileMethod
0012dd94 79e97516 mscorwks!UnsafeJitFunction+0x212, calling mscorwks!CallCompileMethodWithSEHWrapper
0012df44 7c910732 ntdll!RtlpAllocateFromHeapLookaside+0x42, calling ntdll!_SEH_epilog
0012df48 7c9106ab ntdll!RtlAllocateHeap+0x1c2, calling ntdll!RtlpAllocateFromHeapLookaside
0012df4c 7c9106eb ntdll!RtlAllocateHeap+0xeac, calling ntdll!_SEH_epilog
0012df5c 7c9105c8 ntdll!RtlpFreeToHeapLookaside+0x22, calling ntdll!RtlpInterlockedPushEntrySList
0012df68 7c910551 ntdll!RtlFreeHeap+0x1e9, calling ntdll!RtlpFreeToHeapLookaside
0012df6c 7c911b09 ntdll!RtlLogStackBackTrace+0x110, calling ntdll!_SEH_epilog
0012df88 7c91056d ntdll!RtlFreeHeap+0x647, calling ntdll!_SEH_epilog
0012dff0 7c9106eb ntdll!RtlAllocateHeap+0xeac, calling ntdll!_SEH_epilog
0012dff4 7c9119e6 ntdll!RtlpAllocateDebugInfo+0x49, calling ntdll!RtlAllocateHeap
0012dff8 7c911a24 ntdll!RtlpAllocateDebugInfo+0x7a, calling ntdll!RtlLeaveCriticalSection
0012e000 7c9119fa ntdll!RtlpAllocateDebugInfo+0x66, calling ntdll!_SEH_epilog
0012e034 7c911ad6 ntdll!RtlInitializeCriticalSectionAndSpinCount+0x11f, calling ntdll!RtlLeaveCriticalSection
0012e048 7c91056d ntdll!RtlFreeHeap+0x647, calling ntdll!_SEH_epilog
0012e06c 7c911b3c ntdll!RtlInitializeCriticalSection+0xf, calling ntdll!RtlInitializeCriticalSectionAndSpinCount
0012e07c 7c809faf kernel32!InitializeCriticalSection+0xe, calling ntdll!RtlInitializeCriticalSection
0012e088 79e7a501 mscorwks!CrstBase::InitWorker+0x92, calling kernel32!InitializeCriticalSection
0012e08c 79e7a521 mscorwks!CrstBase::InitWorker+0xb2, calling mscorwks!_EH_epilog3
0012e0a8 7c9106eb ntdll!RtlAllocateHeap+0xeac, calling ntdll!_SEH_epilog
0012e0b8 79e7a521 mscorwks!CrstBase::InitWorker+0xb2, calling mscorwks!_EH_epilog3
0012e0bc 79e7a53a mscorwks!Crst::Crst+0x16, calling mscorwks!CrstBase::InitWorker
0012e0c0 79e7a54d mscorwks!Crst::Crst+0x3e, calling mscorwks!_EH_epilog3
0012e0c8 79e744a2 mscorwks!UnsafeEELeaveCriticalSection+0xa, calling ntdll!RtlLeaveCriticalSection
0012e0cc 79e744b5 mscorwks!UnsafeEELeaveCriticalSection+0x1d, calling (JitHelp: CORINFO_HELP_GET_THREAD)
0012e0d0 79e7473a mscorwks!CrstBase::Leave+0x77, calling mscorwks!UnsafeEELeaveCriticalSection
0012e0d4 79e74753 mscorwks!CrstBase::Leave+0x96, calling mscorwks!_EH_epilog3
0012e0e8 79e7a54d mscorwks!Crst::Crst+0x3e, calling mscorwks!_EH_epilog3
0012e0ec 79e74811 mscorwks!CrstBase::Enter+0xe2, calling ntdll!RtlTryEnterCriticalSection
0012e0f0 79e7a773 mscorwks!Thread::EnablePreemptiveGC+0xf, calling mscorwks!Thread::CatchAtSafePoint
0012e0f4 79e74811 mscorwks!CrstBase::Enter+0xe2, calling ntdll!RtlTryEnterCriticalSection
0012e0f8 79e74845 mscorwks!CrstBase::Enter+0x1eb, calling mscorwks!_EH_epilog3
0012e124 79e7adb7 mscorwks!DeadlockAwareLock::EndEnterLock+0x11, calling (JitHelp: CORINFO_HELP_GET_THREAD)
0012e12c 79e7adc3 mscorwks!DeadlockAwareLock::ReleaseBlockingLock+0x6, calling (JitHelp: CORINFO_HELP_GET_THREAD)
0012e130 79e7b9f8 mscorwks!ListLockEntry::FinishDeadlockAwareEnter+0x41, calling mscorwks!_EH_epilog3
0012e14c 79e9731c mscorwks!MethodDesc::MakeJitWorker+0x1c2, calling mscorwks!UnsafeJitFunction
0012e1b0 79e971ba mscorwks!PEFile::CheckIL+0x40, calling mscorwks!PEDecoder::CheckRva
0012e1f0 79e7d58c mscorwks!MethodDesc::DoPrestub+0x44d, calling mscorwks!MethodDesc::MakeJitWorker
0012e248 79e7bb73 mscorwks!PreStubWorker+0xed, calling mscorwks!MethodDesc::DoPrestub
0012e298 039e1efe 039e1efe, calling mscorwks!PreStubWorker
0012e2b0 08979faa (MethodDesc 0x89a16c8 +0x1a MS.Internal.Xml.XPath.XPathParser.ParseXPathExpresion(System.String)), calling 089a2211
0012e2d0 08979faa (MethodDesc 0x89a16c8 +0x1a MS.Internal.Xml.XPath.XPathParser.ParseXPathExpresion(System.String)), calling 089a2211
0012e2dc 08979566 (MethodDesc 0x89a0f98 +0x2e System.Xml.XPath.XPathExpression.Compile(System.String, System.Xml.IXmlNamespaceResolver)), calling (MethodDesc 0x89a16c8 +0 MS.Internal.Xml.XPath.XPathParser.ParseXPathExpresion(System.String))
0012e2f4 08979515 (MethodDesc 0x898f4f8 +0xd System.Xml.XPath.XPathNavigator.Select(System.String)), calling (MethodDesc 0x89a0f98 +0 System.Xml.XPath.XPathExpression.Compile(System.String, System.Xml.IXmlNamespaceResolver))
0012e2fc 089791d6 (MethodDesc 0x4380e88 +0x1e System.Xml.XmlNode.SelectSingleNode(System.String))
...

0:000> kb 40
ChildEBP RetAddr Args to Child
0012d9a4 79e78414 00000000 00000078 ccb2927d mscorwks!EEHeapAllocInProcessHeap+0x1d
0012d9d8 79e98223 00000078 79e9a27e 0017f818 mscorwks!operator new+0x2b
0012d9e0 79e9a27e 0017f818 00000078 ccb291f1 mscorwks!ZapperModule::allocateArray+0x9
0012da54 790624b2 0012ddf8 00000078 00000000 mscorwks!CEEInfo::allocateArray+0xe3
0012da64 7906cb3c 04120010 00000000 0012deec mscorjit!Compiler::eeSetLIcount+0x27
0012da80 7906d085 00000000 04120010 0012de00 mscorjit!Compiler::genIPmappingGen+0x65
0012db44 7906dfce 0012dc88 0012deec 0012dc7c mscorjit!Compiler::genGenerateCode+0xd5
0012db68 7906ebee 0012dc88 0012deec 0012dc7c mscorjit!Compiler::compCompile+0x160
0012dbc0 7906e8db 03a63400 0012ddd4 0012de60 mscorjit!Compiler::compCompile+0x2d8
0012dc54 7906e831 0012ddd4 0012de60 0012dc88 mscorjit!jitNativeCode+0xb8
0012dc8c 79e9776f 790af170 0012ddd4 0012de60 mscorjit!CILJit::compileMethod+0x3d
0012dcf8 79e976e5 03bbf248 0012ddd4 0012de60 mscorwks!invokeCompileMethodHelper+0x72
0012dd3c 79e9767a 03bbf248 0012ddd4 0012de60 mscorwks!invokeCompileMethod+0x31
0012dd94 79e97516 03bbf248 0012ddd4 00000000 mscorwks!CallCompileMethodWithSEHWrapper+0x84
0012e14c 79e9731c 089a2048 03be0da8 00107410 mscorwks!UnsafeJitFunction+0x212
0012e1f0 79e7d58c 03be0da8 00000000 ccb2a9ed mscorwks!MethodDesc::MakeJitWorker+0x1c2
0012e248 79e7bb73 00000000 ccb2a93d 0012e5a0 mscorwks!MethodDesc::DoPrestub+0x44d
0012e298 039e1efe 0012e2c8 c8ef7a6c 065cdf44 mscorwks!PreStubWorker+0xed
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012e320 79e88f63 7c910945 7c91094e 0012e3b0 0x39e1efe
0012e324 7c910945 7c91094e 0012e3b0 79e88ee4 mscorwks!CallDescrWorker+0x33
79e88f63 840f04f9 0010d2fb 0f08f983 10d2fd84 ntdll!RtlAcquirePebLock+0x28
79e88f63 00000000 0010d2fb 0f08f983 10d2fd84 0x840f04f9

Under what conditions will the function EEHeapAllocInProcessHeap() in mscorwks.dll (file version 2.0.50727.42 for .NET Framework 2.0) throw an exception C0000090?

We are experiencing this exception when the .NET method XPathExpression.Compile() is called from a COM client written in VisualAge Smalltalk. XPathExpression.Compile()internally seems to do some JIT compilation that finally invokes EEHeapAllocInProcessHeap().

The problem seems to have something to do with the way VisualAge initializes the process, and is thus probably Smalltalk specific. But to find out what this is, it would be extremely helpful if I knew what error conditions cause EEHeapAllocInProcessHeap() to throw an exception of this type.

Any hint is appreciated! Thanks in advance!

Thanks for reporting this issue!

Would it be possible for you to send us a full dump or instructions on how to repro this failure? You can create a full dump in windbg using ".dump /ma <filename>". Repro instructions are even better if you think we can repro it on our side.

Thanks for replying to my post!

Unfortunately reproducing the crash on your side will be be difficult or even impossible, since we experience the crash only with a COM client written in "Instantiations VA Smalltalk" (formerly "IBM VisualAge Smalltalk") Version 7.0 and I do not expect you to have access to this development enviroment. In addition I have to admit that the Instantiations product support, who we also contacted about the problem, is not able to reproduce the crash either. But I was able to reproduce it on any computer I have access to (about 7 different machines).

Can you please tell me how (where) I can send you my crash dump file?

The crash occurs in XmlDocument.SelectSingleNode(), when the Smalltalk COM client calls a .NET method through COM that contains e.g. the following sequence of methods:

XmlDocument _xmlDoc = new XmlDocument();
XmlNode rootElement = _xmlDoc.CreateElement("Root");
_xmlDoc.AppendChild(rootElement);
XmlElement xmlElement = _xmlDoc.CreateElement("Test");
rootElement.AppendChild(xmlElement);
_xmlDoc.SelectSingleNode("/Root/Test");

There is no dependency on how the XmlDocument and its nodes are created (might also be done by reading an XML file) and whether the node selected by SelectSingleNode() exists or not. The code might also be distributed over multiple .NET/COM methods.

Another thing worth mentioning:Ifan arbitrary .NET exception (either caught in .NET or only returned as a COM error HRESULT to the client) is thrown sometime before SelectSingleNode() is called, the crash in SelectSingleNode() will not occur!

For info on reproducing this might be helpful:

The same error is experienced if the client application is written in Borland C++ 2006 and the COM server written in Visual Studio 2005 calls SelectNodes or SelectNode ona XmlDocoument.

Really need to get this workingso if any one has a clue on how to workaround this problem it would make me really happy.

Interesting to hear that this crash also occurs with COM clients in other languages! Maybe this shedssome new light on the problem and makes it easier to reproduce...

We foundthe followingworkaround to avoid the crash: Ifan arbitrary .NET exceptionis thrown in the COM server sometime before SelectSingleNode() or SelectNodes() is called, the crash will not occur! Even the following simple code willdo it:

try
{
// Throw an exception..
throw new Exception();
}
catch
{
// .. and just catch it
}

The exception doesn't need to be thrown in the same COM method as the call to SelectSingleNode() or SelectNodes, just sometimes before in the same session.

This worked for us and will also hopefully solve your problem, Magnus. Nevertheless I still hope that the REAL cause of the crash is found someday...

Thanks for your reply.

This was really interesting to see. I tried your code in my test projects and it worked! But it makes me feel somewhat unsecure and a couple of questions arise.

Does any one have an explanation to why this works? What else migth go wrong? By implementing this workaround, has we only moved the problem to somewhere else in the application?...

We have very similar problem with a different cause. We arealso developing .Net components that are used by VB andDelphi clients through COM. With the framework 1.1 everything was fine. After we moved to VS05, Delphi clients started crashing right away.VB clients still worked normal.WinDbg showed us the same picture as yours - hundreds of 0xC0000090 exceptions (first chance) followed by a stack overflow and a access violation. As we dig deeper we found out that a expression like

double val = double.NaN;

was causing the problem.

If we change it to

double val = double.PositiveInfinity;

it would work fine again.

Is there a difference nowhow the c# compliler is using silent/signaling NaN's?

We are also using XP with SP2, VS2005; VB 6 and Delphi 5.0 are used on the client side.

Zoran

I have the same issue but without any COM coding: just native calling Clr.
And luckily your workaround works.
Thanks a lot!

Sönke

For anyone still following this thread:

This bug is still present in the 3.5 framework and the same workaround still works

For anyone still following this thread:

This bug is still present in the 3.5 framework and the same workaround still works

I too can vouch that this bug still exists.

My route is: A third party reporting app --> my OLEDB COM server DLL (C++/ATL) --> my .NET DLL.

Ute. Thank you for suggesting the workaround. Your trick worked for me as well.

Regards,
Peter

A diagnosis made in another thread is that this is caused by the native app not properly initializing the floating point control word. This causes a floating point exception, most typically due to NaN, in the managed code. The FPU must be initialized to mask all exceptions. Ute's workaround works because an exception resets the FPU control word.

---

Hans Passant.

@nobugz: A link to that thread would be helpful?

This bug still exists in .Net 3.5 SP1.

The FPU must be initialized to mask all exceptions.

That's the default initialization, _controlfp() to fix. It is not a .NET bug.

---

Hans Passant.