System Arithmetic Exception: Delphi calling C# DLL via C++/CLI wrapper

2
votes

I have a C# DLL that uses the XslCompiledTransform class for xml manipulations. I stole a C++/CLI wrapper for the C# DLL.

When using Delphi 5 to implement the C++/CLI wrapper, I receive a System Arithmetic error. Here is the Delphi 5 declaration:

procedure XsltMethod(XmlPath, XsltPath: PWideChar); cdecl; external 'ahma.dll';

The body of the C# public method creates a new XslCompiledTransform object and the exception pops up right when the newly created object runs its load method. For example:

XslCompiledTransform xslt = new XslCompiledTransform();
xslt.Load(XsltFile);

As mentioned earlier, the exception thrown from the .NET DLL is a System Arithmetic Exception. This only happens when called from a Delphi executable.

I guess I should mention calling the object's load method again works fine. So catching the exception and running the method for a second "pass" acts like a popup blocker. But for exceptions, of course.

2
c#delphiinteropc++-clipointer-arithmetic
Can't fault the post for not being detailed enough, that's for sure. It might actually help to codense things a bit, and put everything except short snippets in files to which you like. Might get more people to read it that way. – Noldorin
Ha! Yea I'm a noob. Thanks for being patient with me :) – Drone 605

2 Answers

2
votes

Random thoughts:

  • I think you should start by debugging your assembly from Visual Studio. Insert a messagebox or other wait statement in the Delphi code, then attach to process from Visual Studio. Tracing the C# might provide a couple of hints on what is going wrong. If you can't get it working, at least add logging of the incoming parameters.
  • In delphi, you don't need to escape backslashes.
  • Are you sure the E0434F4D is not some innocent first-chance exception? If you do not debug (or continue from the JIT debugger exception stop, which I'm not entirely sure is possible with Delphi 5), is the behaviour indeed faulty?
  • Could we please refer to "native Win32 assembly" as "DLL", like we used to call them for the past 20 years? :-)
2
votes

Maybe you suffer from differences in the Floating-Point Control Register as stated here. Also see this QC report. You could try calling Set8087CW($133F); in your Delphi program. Be cautious of floating point problems in your Delphi code after that.