C# XslCompiledTransform crash when called from VCL C++

[Jeroen ter Hofstede]

Environment:
- .Net Framework v2.0.50727
- Borland C++ Builder 5

We are extending our C++ application with functionality in a C# dll.
The C++ app creates an object from the (registered) dll and calls a
method in it. This method creates and uses an XslCompiledTransform
object. Unfortunately, when calling Load() on this object, the
application crashes with an access violation in the .Net runtime. This
problem does not occur when we call the same method from a VB
application, nor does it occur when performing the same steps from
within a (C++ Builder) console application. Until now, we've only
managed to reproduce the problem from within a windowed (VCL)
application.

Does someone have any clue about what might cause this problem, and
moreover, what can be done about it?
TIA,
Jeroen

The smallest example that exhibits the problem contains:

* The C# file issue.cs (compile with csc /target:library issue.cs, and
then register it with regasm /codebase issue.dll)
---
using System.Runtime.InteropServices;
using System.Xml.Xsl;

[Guid("694C1820-04B6-4988-928F-FD858B95C880")]
public interface IIssue
{
void issue ();
}

[Guid("9E5E5FB2-219D-4ee7-AB27-E4DBED8E123E"),
ClassInterface(ClassInterfaceType.None)]
public class Issue : IIssue
{
public void issue ()
{
XslCompiledTransform transformer = new XslCompiledTransform ();
transformer.Load (@"c:\transform.xsl");
}
}
---

* The xsl file c:\transform.xsl:
---
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
</xsl:template>
</xsl:stylesheet>
---

and
* The C++ Builder program (project2.cpp in project2)
---
# include <olectnrs.hpp>
USERES("Project2.res");

WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
OleInitialize (0);
Variant obj = CreateOleObject ("Issue");
obj.OleFunction ("issue");
return 0;
// Cut away the from creation and message
//loop - not needed for example
}
---

[Jeroen ter Hofstede]

Jeroen ter Hofstede schreef:

[snip]

> object. Unfortunately, when calling Load() on this object, the
> application crashes with an access violation in the .Net runtime. This

[snip]

After some experimentation and debugging:
- The access violation seems to be caused by a stack overflow. I
suspect that this is a symptom of the problem, not the cause.
Increasing the stack from 1 to 4 MB does not help.
- The problem also occurs when calling over the COM interface directly,
bypassing OLE/IDispatch.

[Jeroen ter Hofstede]

Jeroen ter Hofstede schreef:

> Jeroen ter Hofstede schreef:
>
> [snip]
> > object. Unfortunately, when calling Load() on this object, the
> > application crashes with an access violation in the .Net runtime. This
> [snip]
>
>
> After some experimentation and debugging:
> - The access violation seems to be caused by a stack overflow. I
> suspect that this is a symptom of the problem, not the cause.
> Increasing the stack from 1 to 4 MB does not help.

I can confirm that now. The stack overflow is caused by an attempt to
recursively handle a 'invalid floating point operation' fault in
mscorjit.dll.

[Jeroen ter Hofstede]

Jeroen ter Hofstede schreef:

A final update (and then I'll stop muttering to myself): the problem
reproduces with the newest Borland C++ (Studio?). I can now reliable
reproduce it also with a console application. The same program compiled
with Visual C++ (2005) does not exhibit the problem.

[Jeroen ter Hofstede]

A final update - Microsoft support has been able to find the problem.
Somewhere in the CLR the code fiddles with the control word of the
floating point unit. This is able to cause an exception, but Microsoft
compilers by default mask out this exception in the programs they
generate. Borland's compilers however leave this exception unmasked,
leading to the problem.

The solution is simple; to mask the exceptions, add

# include <float.h>
.....
_control87(MCW_EM, MCW_EM);

to the beginning of your program, and all works well again.