topic Add the compiler option in Intel® Fortran Compiler

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

Bradley_P_ — Thu, 22 Feb 2018 18:07:45 GMT

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.

That's not a standard Windows

Steve_Lionel — Thu, 22 Feb 2018 21:40:19 GMT

That's not a standard Windows error code. It could be from anything.

You should rebuild your program with traceback enabled - it would at least show you the line number in your EXE, which would be a start.

OK, that sounds helpful.

Bradley_P_ — Thu, 22 Feb 2018 22:05:01 GMT

OK, that sounds helpful. Please tell me how to enable traceback.

Thanks!

Brad.

Add the compiler option

mecej4 — Thu, 22 Feb 2018 22:28:33 GMT

Add the compiler option /traceback to the compiler command line or enable traceback in the project settings.

The presence of Abc.exe in

jimdempseyatthecove — Fri, 23 Feb 2018 13:38:15 GMT

The presence of Abc.exe in the call stack is peculiar. Does your program contain a SYSTEM('Abc.exe') or SYSTEMQQ or similar call to invoke the program.

Note, Abc.exe could also be your Fortran program invoked by some other means than command line.

Traceback should help.

Also check the Windows system/event log around the time of the error. It may have some useful information.

Jim Dempsey

Also see: https://social.msdn

jimdempseyatthecove — Fri, 23 Feb 2018 13:45:38 GMT

Also see: https://social.msdn.microsoft.com/Forums/vstudio/en-US/2556a86b-f82e-4efb-bcdd-19919facbff6/application-error-faulting-module-name-kernelbasedll-version-61760016385?forum=vcgeneral

In that case it showed an incompatibility of running a 32 bit program on 64 bit platform.

*** in particular, the use of Platform==x86 as opposed to ==Win32 or ==x64

If you are using x86 for platform, please change it to one of the two other platforms.

Jim Dempsey

Abc.exe is the user

Steve_Lionel — Fri, 23 Feb 2018 14:44:12 GMT

Abc.exe is the user application. It's calling into the Windows API somewhere.

Yes, "Abc.exe" is our

Bradley_P_ — Fri, 23 Feb 2018 16:06:33 GMT

Yes, "Abc.exe" is our application.

No, I don't think this has anything to do with x86/Win32. We're using x64.

"Traceback" actually looks very promising, and is showing excellent preliminary results. I'm just waiting for a window in which to move it into production so that I can get real data.

Thanks all!

Brad.

Sadly, "Traceback" did not go

Bradley_P_ — Fri, 23 Feb 2018 19:17:17 GMT

Sadly, "Traceback" did not go as well as hoped. Yes, it provided us with a bit more information, but it made it so that the application never successfully completed. It appears to have exposed exceptions that were previously being ignored. Any ideas why it would have this impact?

Thanks!

Brad.

Your program has bugs that

andrew_4619 — Fri, 23 Feb 2018 20:02:30 GMT

Your program has bugs that you need to fix. Adding traceback changes the code so for example, some data corruption that previous corrupted something that was not critical now corrupts something that is critical.....

Compile the code with all

jimdempseyatthecove — Fri, 23 Feb 2018 20:58:24 GMT

Compile the code with all compile time diagnostics enabled. And fix any errors reported. If no compile time errors are reported then the next step is to compile with optimization disabled, and all runtime checks enabled. Then try stress testing the code on various systems in an attempt to expose the error. If errors (g.e. subscript out of bounds) are found, fix them. If (when) no errors show up, keep runtime checks enabled and increase optimization levels, perform stress test, fix errors if possible as they show up. The remove runtime checks, start at /O0 and work your way up.

Note, if the program crashes at a particular optimization level, it can often be the case that only one of the source files is sensitive to the optimization level, and you can compile that source file at a lower optimization level.

Jim Dempsey

/traceback does not change

Steve_Lionel — Fri, 23 Feb 2018 22:10:53 GMT

/traceback does not change the code - it adds nonexecutable data to the EXE. I wonder if you have malware corrupting EXE files.

Quote:Bradley P. wrote:

Bradley_P_ — Fri, 23 Feb 2018 23:36:14 GMT

Bradley P. wrote:

Sadly, "Traceback" did not go as well as hoped. Yes, it provided us with a bit more information, but it made it so that the application never successfully completed. It appears to have exposed exceptions that were previously being ignored. Any ideas why it would have this impact?

I'm happy to report that the above statement is incorrect - I was wrong! I had made a different change specifically for debugging that caused the extra exceptions.

I'm also happy to report that I've made some progress, though it hasn't gotten me much closer to resolving the problem. I should maybe start an entirely new thread on this, but....

The "172" is being thrown on a line that is making a call to an external DLL. I control the external DLL, 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? How do I diagnose a call that simply blows up, but does so only occasionally? How do I figure out what's wrong or how to fix it?

Thanks!

Brad.

How do you access the DLL? Do

Steve_Lionel — Sat, 24 Feb 2018 00:19:25 GMT

How do you access the DLL? Do you just call the entry point and link in the export library, or are you using LoadLibrary and GetProcAddress? What happens if you run this in the debugger and do a "step into" at the line of the call?

Quote:Steve Lionel (Ret.)

Bradley_P_ — Sat, 24 Feb 2018 00:25:54 GMT

Steve Lionel (Ret.) wrote:

How do you access the DLL? Do you just call the entry point and link in the export library, or are you using LoadLibrary and GetProcAddress? What happens if you run this in the debugger and do a "step into" at the line of the call?

I am just calling the entry point as per the export library. If you can show me how to use LoadLibrary and GetProcAddress, that might get me closer to figuring out what the problem is. In terms of a debugger, I don't have that luxury - I have never been able to reproduce the error in a controlled environment of any kind. As far as I know, it's random, and never happens on my machine.

Thanks!

Brad.

You're more likely to get to

Steve_Lionel — Sat, 24 Feb 2018 01:30:00 GMT

You're more likely to get to the issue with direct linking, but if you want to try, look at the DLL\DynamicLoad sample you can get from the Parallel Studio XE for Windows samples.

Random problems are the pits. Next thing I would suggest is to temporarily disable anti-malware programs and see if the problem goes away. Might also be interesting if you could boot to Safe Mode and see if the problem is reproducible. That your debug statement isn't executing is interesting, suggesting something is corrupting the DLL in memory.

>>so I put a debug line in as

jimdempseyatthecove — Sat, 24 Feb 2018 13:02:40 GMT

>>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. For debugging purpose, I usually insert a dummy subroutine into the DLL and then call that at the start of the program. This can be a do nothing subroutine and would be innocuous in the event you forget to remove it for the release build.

Note, If the step into performs a step over, then the debug info database is likely not found (e.g. wrong DLL is being loaded). Additionally, when you reach the call to the dummy routine, open a Dissassembly, you do not have to understand assembly, then use step into a few times. You will see the instruction pointer advance to a call instruction, then the next step into (may) transfers to the DLL dispatch table, then the next step into should appear at the entry point of the subroutine. At this point the source window should show the DLL source code. If it doesn't then either the wrong DLL is being loaded or your DLL was not built debug information or linked with keep debug information.

Jim Dempsey

Quote:Bradley P. Thu, 02/22

FortranFan — Sat, 24 Feb 2018 18:38:35 GMT

Bradley P. My Fortran is, to say the least, rusty. ..

Bradley P... The "172" is being thrown on a line that is making a call to an external DLL. I control the external DLL..

@Bradley P.,

You may save yourselves a lot of time and from further grievance by providing details on your application and the subprograms it invokes from external DLL which you state you control. Specifically the build logs of your DLL and the ABC.exe application and the source for the called and the calling routines. If you cannot share them on the forum here, look into whether you can use the Intel Online Service Center for support with confidentiality:

https://supporttickets.intel.com/?lang=en-US

Another possible cause of the severe Program Exception is stack corruption due to calling convention differences between the DLL and your application - see this:

https://software.intel.com/en-us/fortran-compiler-18.0-developer-guide-and-reference-iface

This is a 64-bit program, so

Steve_Lionel — Sat, 24 Feb 2018 20:44:32 GMT

This is a 64-bit program, so calling conventions are unlikely to be at play. As Bradley says that the issue is sporadic, that makes many traditional investigative techniques difficult.

Quote:Steve Lionel (Ret.)

FortranFan — Sun, 25 Feb 2018 13:41:33 GMT

Steve Lionel (Ret.) wrote:

This is a 64-bit program, so calling conventions are unlikely to be at play. As Bradley says that the issue is sporadic, that makes many traditional investigative techniques difficult.

I was hoping for OP to look into the details himself, for there is more to it besides the x86-related STDCALL vs CDECL differences that one may willfully ignore in this x64 case e.g., whether the aspect about the hidden string length parameter if arguments of CHARACTER type are involved are consistent. What does the so-called external DLL expect, after all the other arguments or after each individual string parameter, /iface:mixed_str_len_arg? And if the caller has the same settings. Depending on how the code is structured, I can imagine a scenario where problems arise sporadically based on input data.

Maybe the above point is not applicable to this issue, but again details such as called routine interface vis-a-vis what the caller does, whether explicit interfaces are being used or not along with build settings of the external DLL and the calling application can all help provide better clues to the underlying problem and it may help expedite the resolution.