- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- « Previous
-
- 1
- 2
- Next »
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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"?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
> 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- « Previous
-
- 1
- 2
- Next »