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


New Contributor I

I am having recurring "exception thrown" problems with a piece of legacy software.  The most common is a wntdll.pbd error saying the file is not loaded and referring to ntdll.dll.  Neither is on my machine.  This problem moves around from run to run, even when two runs are made sequentially with no other changes.  To me, that the symptom of a memory error.  The messages I get also vary, sometimes indicating "a heap has been corrupted" or "access violation writing location ..." and citing libilcoremdd.dll.  A frequent form of the problem is an exception that occurs when an array is ALLOCATEd of DEALLOCATEd.  The ALLOCATE or DEALLOCATE command appears to work correctly, but if I insert an error trap to check after the command is executed, if find problems.  For example, DEALLOCATE (P,G,Z) appears to work OK, but if I immediately test ALLOCATED(P), I find it's .TRUE.  I've seen similar behavior with ALLOCATE.

Three attachments:

1)  A screen shot of a thrown excution;

2)  An output file up to the point of failure; and

3)  The listing file of the module containing PIECEWISE, the subroutine where most of the problems have been occurring, at least lately.  (Sorry, your web site wouldn't allow a .lst file, which would have shown you my compiler options.  I attached the .for instead.)

Your good offices are greatly appreciated.

Mahalo, Mike McCurdy

0 Kudos
10 Replies
Black Belt Retired Employee

Ignore the part about wntdll.pdb, etc. Instead, look at the console window for this application for the actual error. It's not possible for us to analyze the problem from only a part of a program, but you'll see a better error message in the console window (which may be "behind" the VS window.)

New Contributor I

Thanks, Doc.  I had already checked the console window, which is embedded in the screen shot I attached to my original post.  In spite of debug:/full, /traceback, /check:bounds, /check:stack, the only thing showing is stuff I wrote there.


I belatedly discovered the STAT option for ALLOCATE/DEALLOCATE and attempted to use it for exception handling, with no luck.  The attachment pertains.  If the watch box at lower left corresponds to the x in the red circle, none of the three arrays was ALLOCATEd, ISTAT was set to a non-zero value, and there was a failure to transfer control to the next statement, which was attempting to handle the exception.  Once again, there's no traceback.


Aloha, Mike

Black Belt

What is the value of ELLMAX?

And are P, G and Z_ valid (array descriptors)? IOW should they be junk addresses/references the array descriptors might be readable but not writable.


Also, the error message box contains "has triggered a breakpoint"... meaning the code encountered a break instruction  INT03 (0xCC). This is not a non-Debug Break exception thrown at that location. Your break point is set at two lines late4r on the CALL statement. An INT03 appears to be executed at a location where it was not set. This reminds me of a frustrating debugging secession several years ago where an errant breakpoint 0xCC was placed in a multi-byte instruction but not as the first byte. This resulted in errors other than "triggered a breakpoint" (memory trashed etc...). I was able to identify where memory was trashed and then by setting a break on memory change at the trash location, I could identify the instruction causing the error. *** However, inspecting the Disassembly showed that the instruction byte codes were correct and should not have written to the location that triggered the data break point. This was perplexing (was my CPU failing). After some thought, I made a "guess" that what the debugger was showing me was not what was there at time of execution. There is more to the story than this, but the end result analysis was:


Sometimes the MS VS debugger in maintain the tables of where breakpoints are set gets into an unstable state where it will not show where all break points are set (Debug | Windows | Breakpoints). IOW there are phantom breakpoints that can be located at arbitrary byte locations (I presume former breakpoint locations). These do not show up in the list of breakpoints, but are found, and inserted into the code when you Continue, Step Into, Step Over *** then removed at next break. The way to correct this is to: Debug | Windows | Breakpoints then click on the Red X


CAUTION do not delete them one by one .OR. Ctrl-A and delete all the selected breakpoints as this will not delete the phantom breakpoints. Use the Red X.


As to if this is your problem I cannot say, but it is an easy enough test to perform.


Jim Dempsey

Valued Contributor II

Nice code. 

Did you check that ELLMAX exists and has a value.  I avoid using the simple check on astat and want to see a positive response.  

 allocate (HTMAX(K,K), STAT = astat)
        if(astat == 0) then
            write(*,*)"Allocated matrix HTMAX(K,K)"
            stop "Failed to allocate matrix HTMAX(K,K)"
        end if

I suggest a log file and list out everything before you call the allocate.  This morning I had a complete failure to execute a program and it was a missing value in an input file.  

Good luck. 


New Contributor I



Thanks for both of your replies.


I attempted to do essentially what you suggested in your second e-mail.  However, the run-time monitor (or whatever it is) appears to have thrown the exception in the process of executing the ALLOCATE, hanging execution in spite of optional STAT = ISTAT.  That gave me no opportunity for error handling, not even to get an error code I could follow up on, let alone a traceback.  Please see the "ALLOCATE problem 211205.docx" file I attached to my second post, which contains a screenshot of how things looked when the exception occurred.  I've re-attached it here.


As John Nichols suggested, I did ensure that ELLMAX existed and had a value, and that the value is within the acceptable range.


Mahalo, Mike

Black Belt

This may be a case where something overwrote your code at (in the sequence of the instructions for) the allocate. I notice in your log window that the next to the last column is -1200 whereas all other numbers in that column are positive and increasing by 20. Might this have cause your program to go awry?

You could break before the allocate, then open a disassembly window. Important, in the Disassembly window. Right-Click and the check Show code bytes. then screenshot the disassembly from the IF(ALLOCATED... through IF(ISTAT....  This may require multiple screenshots. Paste them in a .docx file. Then remove your early break point and continue to crash. Then reopen the disassembly window and compare code.

If you locate a changed byte, you can rerun the program with a break prior to the crash, then set a data break at the byte address(es) of the changed code. Then continue to find where the problem is located.

Jim Dempsey



ELLMAX is "acceptable" - what is it's value? How much memory do you have in your PC?

Valued Contributor II

Did you try and allocate only one array at a time.  If one is causing the issue it is easier to fix one. 

Black Belt

I suspect (wild guess really - debugging help for this sort of problem often requires the helper the code and input so they can recreate the problem) that your program is trashing memory on its heap in some way prior to the allocate statement, the Windows (or C runtime library) debug heap manager detects that trashing when it is called as part of the allocate statement, and the breakpoint is the debug heap manager's way of reporting this to your debugger.  (If pressed I would have said that the debug heap manager would give a more specific exception that what you are showing, but perhaps I am mistaken.)

What are the "details" of the exception (there's a "copy details" button in the little window in Visual Studio reporting the exception).

What does the Output window (Debug > Windows > Output) say?

What command line options are you using (you can copy and paste them into a forum post).

Why not /check:all ?

The heap correction checks that the Windows and/or C runtime debug heap manager carries out can be triggered manually by your program.  You can then use a bisection technique (allowing for any randomness in reproducibility) to track down the offending part of the code.  The method to manually trigger debug heap manager checks depends on Fortran compiler command line options.



I agree with Ian: compile and run with /check:all first.

Are all of your interfaces declared with INTERFACE blocks or in MODULEs?  Or do you have F77 style EXTERNAL procedures (no arg checking).  And are you using /gen-interfaces to allow the compiler to auto generate interfaces for your EXTERNAL procedures and check arguments at call sites? 

Is this all Fortran or is it mixed with C/C++ or VB?  You aren't calling C to malloc or free Fortran data are you?

Are you calling external 3rd party DLLs or libraries?  


If you can CLEAN the project, create a zip of the solution folder and all other related files and create a bug report on Online Service Center that would be ideal.