- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK, that sounds helpful. Please tell me how to enable traceback.
Thanks!
Brad.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Add the compiler option /traceback to the compiler command line or enable traceback in the project settings.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Abc.exe is the user application. It's calling into the Windows API somewhere.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
/traceback does not change the code - it adds nonexecutable data to the EXE. I wonder if you have malware corrupting EXE files.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page