Q about debugging hangup

[WSinc]

I recently am dubbing a program where it comes acros a read error.

So the breakpoint occurs in a library routine.

The output pane gives a traceback where the READ error occurred, but

I am wondering why I cannot go to the routine and examine the contents of the variables in that routine.

The stack window does not allow me to go to the routine that has the READ statement.

Is there a way around this, other that having to insert print statements there?

[Steven_L_Intel1]

Normally you can use the Stack dropdown to select your program's stack frame. Can you provide a test case that doesn't?

[andrew_4619]

So you are trying to examine variables after the program has crashed. that often does not help as everything can be screwed by that point. Insert a break point at the line  where the crash occurs before running the program in debug to find out what is happening just before the crash. On a read error anyway the error message normally gives some indication of the error.

[Steven_L_Intel1]

I can reproduce the problem. When the DLL libraries are used, the stack is left in a condition that you can't see your program in the stack frame. A workaround is to link with the static libraries (Fortran > Libraries > Use Run-Time Library > Multithreaded (or Debug Multithreaded). I don't know why this is and will send it on to the developers.

[Steven_L_Intel1]

More interesting stuff. VS2013 and VS2015 show this unfortunate behavior, but VS2012 does not. I'm inclined to say that Microsoft made a deliberate choice to not show further stack frames once it runs across a DLL frame for which it has no debug information. There's nothing we can do about that.