Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28383 Discussions

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

Bradley_P_
Beginner
2,744 Views

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.

0 Kudos
33 Replies
Steve_Lionel
Honored Contributor III
2,180 Views

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.

0 Kudos
Bradley_P_
Beginner
2,180 Views

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

Thanks!

Brad.

0 Kudos
mecej4
Honored Contributor III
2,180 Views

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

0 Kudos
jimdempseyatthecove
Honored Contributor III
2,180 Views

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

0 Kudos
jimdempseyatthecove
Honored Contributor III
2,180 Views

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

0 Kudos
Steve_Lionel
Honored Contributor III
2,180 Views

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

0 Kudos
Bradley_P_
Beginner
2,180 Views

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.

0 Kudos
Bradley_P_
Beginner
2,180 Views

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.

0 Kudos
andrew_4619
Honored Contributor II
2,180 Views

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..... 

0 Kudos
JohnNichols
Valued Contributor III
2,173 Views

Try a different computer, a program I run crashes on one Intel NUC and has run perfectly for weeks on a second identical NUC. May be a hardware error. On the first NUC it took 15000 loops over 12 hours to usually crash - not worth the effort to find the problem.

John

0 Kudos
jimdempseyatthecove
Honored Contributor III
2,180 Views

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

0 Kudos
Steve_Lionel
Honored Contributor III
2,180 Views

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

0 Kudos
Bradley_P_
Beginner
2,180 Views

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.

0 Kudos
Steve_Lionel
Honored Contributor III
2,180 Views

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?

0 Kudos
Bradley_P_
Beginner
2,180 Views

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.

0 Kudos
Steve_Lionel
Honored Contributor III
2,180 Views

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.

0 Kudos
jimdempseyatthecove
Honored Contributor III
2,180 Views

>>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

0 Kudos
FortranFan
Honored Contributor II
2,180 Views

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

 

0 Kudos
Steve_Lionel
Honored Contributor III
2,180 Views

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.

0 Kudos
FortranFan
Honored Contributor II
2,009 Views

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.

 

0 Kudos
Reply