forrtl: severe (172): Program Exception - exception code = 0x4352 (17234)

[Bradley_P_]

We have an application that produces the above run-time error.  Here is the full exception output:

forrtl: severe (172): Program Exception - exception code = 0x4352 (17234)

Image              PC                Routine            Line        Source            

KERNELBASE.dll     000007FEFCE3A06D  Unknown               Unknown  Unknown

clr.dll            000007FEF8735E67  Unknown               Unknown  Unknown

clr.dll            000007FEF85389DF  Unknown               Unknown  Unknown

mscoreei.dll       000007FEF8B688CA  Unknown               Unknown  Unknown

mscoreei.dll       000007FEF8B76731  Unknown               Unknown  Unknown

mscoreei.dll       000007FEF8B550EE  Unknown               Unknown  Unknown

Abc.exe            000000013F3FEC97  Unknown               Unknown  Unknown

Abc.exe            000000013F450732  Unknown               Unknown  Unknown

Abc.exe            000000013F450C8C  Unknown               Unknown  Unknown

kernel32.dll       0000000076DE59CD  Unknown               Unknown  Unknown

ntdll.dll          000000007701A2E1  Unknown               Unknown  Unknown

According to http://geco.mines.edu/guide/Run-Time_Error_Messages.html, this is an operating system error, but that really doesn’t help us diagnose the problem.  The worst part of it is that the error 1) only happens on some machines and not others, and 2) only happens occasionally without any pattern I’ve been able to discern.​  I have never been able to reproduce it in a controlled environment.

My Fortran is, to say the least, rusty.  However, I have vague memories that back when I used Fortran more regularly, there was a tool that would allow me to enter the address of the error (i.e. the number in the “PC” column above) and it would take me to the location in the code corresponding to that address.  Does such a tool/utility exist?  I don’t see anything in Visual Studio that does this.

If we can’t get anything from the error message above, the only next step I can think of is a lot of logging/debug statements in the application.​  I am very reluctant to do that for a variety of reasons.

Any help would be much appreciated!

Thanks!

Brad.

[jimdempseyatthecove]

Another issue yet to be addressed is mscorei.dll is part of the Microsoft .NET Framwork. Nothing inherently wrong with this, however components (for example .DLL) are assumed to (default to) "Managed Code". Fortran is unmanaged code. Therefore, one must be careful to explicitly attribute the calling conventions, especially if the library is C++ or C#. (this also may require having a shell function to handle the transition between unmanaged and managed code sections.

Jim Dempsey

[Eugene_E_Intel]

jimdempseyatthecove wrote:

Another issue yet to be addressed is mscorei.dll is part of the Microsoft .NET Framwork. Nothing inherently wrong with this, however components (for example .DLL) are assumed to (default to) "Managed Code". Fortran is unmanaged code. Therefore, one must be careful to explicitly attribute the calling conventions, especially if the library is C++ or C#. (this also may require having a shell function to handle the transition between unmanaged and managed code sections.

Jim Dempsey

Very good point!  The presence of mscoreei.dll and clr.dll clearly indicate that abc.exe requested services of the managed (.NET) code.

In fact, exception code 0x4352 shows up in this thread, where interface between Fortran and C# is discussed: https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/700000

Perhaps that thread gives you some idea, how to declare your data structures for Fortran/.NET interoperability. 

--Eugene

[mecej4]

Eugene Epshteyn (Intel) wrote:
In fact, exception code 0x4352 shows up in this thread, where interface between Fortran and C# is discussed: https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-fo...

Perhaps that thread gives you some idea, how to declare your data structures for Fortran/.NET interoperability. 

Oddly, that thread, it appears, was also originated by the very same Bradley P. Or, do we have two persons named Bradley P. who build mixed applications with C# and Fortran?

[Bradley_P_]

Wow!  I've certainly started a great discussion!  Now if only I could get this problem solved!  :-)

jimdempseyatthecove wrote:

>>so I put a debug line in as the very first line to be executed.  Sadly, when the error occurs it never gets to the first line in the DLL.  Where do I go from here?
Place the debug break point on the first call into the DLL, then use the Step Into....

​I REALLY wish I had this option.  I'm sure if I were able to use the debugger I'd have solved this a long time ago.  Sadly, I've never been able to recreate it in a controlled environment.  It happens at random times on random machines (never mine).

jimdempseyatthecove wrote:

Another issue yet to be addressed is mscorei.dll is part of the Microsoft .NET Framwork....

Eugene Epshteyn (Intel) wrote:

Very good point!  The presence of mscoreei.dll and clr.dll clearly indicate that abc.exe requested services of the managed (.NET) code.
In fact, exception code 0x4352 shows up in this thread, where interface between Fortran and C# is discussed: https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-fo.
Perhaps that thread gives you some idea, how to declare your data structures for Fortran/.NET interoperability.

mecej4 wrote:

Oddly, that thread, it appears, was also originated by the very same Bradley P. Or, do we have two persons named Bradley P. who build mixed applications with C# and Fortran?

Busted!  1) Yes, I'm calling a .NET DLL, and 2) yes, that other thread was started by me as well.  It seems to be my job these days to marry old technology with new.  We have a lot of legacy Fortran code that we don't have time or resources to modernize at the moment (and, in general, it works well).  However, all of our new development is happening in C#, and it's my job to bring the two worlds together, since I'm really the only one around here that knows both.

Now, back to the problem at hand.  I don't believe this is a calling convention nor data structures, though I have struggled through those in the past (as evidenced by the other thread).  The reason for my skepticism is this.  Here are two lines I've added to the beginning of my Fortran code:

print *, 'About to call the DLL from Fortran'
call HelloFromDll()

public static void HelloFromDll()
{
    Console.WriteLine("Hello from the DLL.");
}

Note that the DLL call has no arguments, so it can't be a data structure (nor any argument issues, for that matter).  Over hundreds of calls on a variety of machines, the DLL call is successful approximately 2/3 of the time, and fails approximately 1/3 of the time.  I have no further information than the subject of this email provides.  Again, any help or insight would be appreciated!

Thanks!

Brad.

[Steve_Lionel]

How about you compile the Fortran with /check:stack and see what happens. When you build your C# DLL, are you specifying x64 rather than "Any CPU"?

[Eugene_E_Intel]

>  the error 1) only happens on some machines and not others, and 2) only happens occasionally without any pattern I’ve been able to discern.​  I have never been able to reproduce it in a controlled environment.

Another thing to check: do all machines have the same version/release of .NET framework?  It would be interesting to check, if the failures happen on a particular version of .NET framework.

[Eugene_E_Intel]

And another thing:

Years ago, I had to call Java class from a native C++ code.  That involved making calls to Java Native Interface (JNI).  The first thing one must do in JNI is to create a Java Virtual Machine instance: without JVM, there's no Java code to call.  Similarly, when I later had to call C# code from a native C++ code, the preferred way (at that time) was to export COM Interop interface from C# DLL.  Then the native C++ code could do the proper COM initialization (CoInitializeEx, CoCreateInstance, etc.) and COM Interop implementation would ensure that .NET is properly initialized (either in the same process, or in another process, depending on C# COM Interop settings).   This seems to be the most shared link about this topic: https://support.microsoft.com/en-us/help/828736/how-to-call-a-managed-dll-from-native-visual-c-code-in-visual-studio-n

(More recent link: https://social.msdn.microsoft.com/Forums/vstudio/en-US/440aca96-288a-4d5c-ab9a-87ea2cdd5ca8/how-to-call-c-dll-from-c?forum=csharpgeneral )

In your case, Fortran code is a native code, and it's trying to call .NET managed code.  I don't know, how you initialize .NET.  Perhaps the managed DLL is loaded, but the .NET framework and CLR are not properly initialized.  Your random crashes seem to be similar to thread synchronization issues, and when .NET is started many threads are created.  If your managed DLL doesn't have the right threading model, bad things could happen.  (In Microsoft COM world, there was "apartment threading", "free threading", and .NET adopted some of that and extended it with additional modes.  Specifying incorrect threading model lead to random mysterious crashes, similar to what you are experiencing.)

[Bradley_P_]

Steve Lionel (Ret.) wrote:

How about you compile the Fortran with /check:stack and see what happens.

I tried "/check:stack" and it didn't seem to make any difference at all.

Steve Lionel (Ret.) wrote:

When you build your C# DLL, are you specifying x64 rather than "Any CPU"?

Yes.

Brad.

[Bradley_P_]

Eugene Epshteyn (Intel) wrote:

>  the error 1) only happens on some machines and not others, and 2) only happens occasionally without any pattern I’ve been able to discern.​  I have never been able to reproduce it in a controlled environment.

Another thing to check: do all machines have the same version/release of .NET framework?  It would be interesting to check, if the failures happen on a particular version of .NET framework.

Yes, all machines have the same version of .NET.

Brad.

[Bradley_P_]

Eugene Epshteyn:

What you're describing with your Java experience does sound similar.  However, so far, I've managed to avoid COM entirely.  I agree that it may very well be a threading issue, but that doesn't get me much closer to resolving it.

Thanks!

Brad.

[Eugene_E_Intel]

I would recommend that you create a simple native C code that loads your managed DLL.  If the same exception can happen without the use of Fortran code, then the issue could be localized to the managed DLL.

[jimdempseyatthecove]

Bradley,

Keep in mind that Fortran does not support C++ or C# exception handling. See if you can create s shell C calling convention routine, that contains try/catch around calls into your formal DLL entrypoints. IOW use an exception handling stub function between the Fortran and managed code. Maybe a catch all will explain what the error is.

Jim Dempsey

[FortranFan]

Bradley P. wrote:

.. I've managed to avoid COM entirely ..

If OP can provide specific details on the actual problem or a put together a simple (non-proprietary) model of the same that reproduces the issue, then chances of workable solutions are increased greatly.  If OP feels he has "managed to avoid COM entirely", then some other "wrapper" layer is involved that just makes it appear as if COM is not involved.  In other words, the so-called COM-callable Wrapper (CCW) aspects have been moved elsewhere, for there is no getting around COM when .NET managed code is to be called from the native (unmanaged) side, Fortran being no exception.  Perhaps the problem lies in such a layer, who knows!?

Using the link provided by @Eugene Epshteyn in Quote #28 and with IFCOM module (and the methods therein), one can put together Fortran code that interoperates in x86 (Win32) and x64 modes with COM-visible elements of a .NET class including its methods.  But that won't reproduce OP's issues.

OP appears to be relying on a repeat of the thread from 2016 where someone with great insight,and perceptive capabilities managed to provide a workaround without actually need to try things out.