debugger exceptions for fortran file I/O for XE

debugger exceptions for fortran file I/O for XE

I just installed  XE  which seemed to go OK. I did a clean solution and then a full debug build for X32 which  appeared to go normally. This is a Quickwin application BTW.

When running under debug in VS2010 shell I am getting "first chance exceptions"  for "Invalid handle exception for current stack trace". These are associated with every Fortran open statement, inquire statement and Quickwin routines that use a unit (eg open of a child window & setactiveqq...)

The units are always explicitly declared as 4 byte integer variables and are initialised with sensible numbers. Most of this is mature code that has been used for years.

 The exceptions are all continuable and the program seems to function correctly by the way.

Any clue as to what might be the problem?




38 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I take back the "the program seems to function correctly", it does under debug but in release the process appears in task manager but doesn't get past some on the initialisation as we do not get to display anything before the application process disappears without trace or error or exception!

Switching of optimisation has no effect. :-(

I little more floundering around to go and then I will have to do a full un-install and regress back to an older version :-( 


I couldn't find any problem with my code, it is some issue related to handing file open in the Intel libraries I think. In debug the exception happens during the open command, all the parameters look good, and having ignored the exception (which must be handled) we don't  even get a fortran io error.

Uninstalling and going back to update 5 was a total pain as XE had partially uninstalled update 5 which would not uninstall and a repair would not create vs2010 integrations. however after repair it would uninstall top allow a complete reinstall from the downloaded media!

It all works now but some insight into what the issue might be would be good as at some more opportune points I will need to move forward.



While running under the debugger or probably when the program is compiled as a debug build the currently register debugger will be signaled by SEH about the caught exception and if the debugger does not handle that exception or simply returns the execution back to program.This is called first chance exception.

The exceptions (invalid handles) all occur on call to the Fortran Open command the error it is triggered in my code it the the fortran library code. Further, it occurs on any and every open or inquire statement that had reference to a Fortran 'unit' number and "inquire" by file name does not generate an exception. In all cases the open/inquire have error handling and return zero (no error).

. The release version starts and terminates silently after a few seconds (it is seen in the taskmanager) without creating a window. No error, no traceback.

Out of interest I switched all optimisation off and then also tried heaparrays but the behaviour is unchanged.

Totally totally baffled.

As I have some work I need to do I have un-installed and revered to update 5. Can I have separate installs of the two versions on the same PC (using 2010 shell) to allow me to investigate more at my leisure?


>>>. The release version starts and terminates silently after a few seconds (it is seen in the taskmanager) without creating a window. No error, no traceback>>>

This probably means that no suitable exception handler has been found and/or debugger was not able to handle the exception so the default OS procedure in such a situation is to terminate the process.

>>>The exceptions (invalid handles) all occur on call to the Fortran Open command the error it is triggered in my code it the the fortran library code. >>>

You can try to monitor your application with the help of Application Verifier coupled with debugger in order to catch and invetigate those invalide handles.As your code is compiled and executed in Windows environment I suppose that those handles are created by OS code which deals with the files(CreateFile() function).

Are you using the /iface:cvf switch?  Sometimes that can cause stack issues.

Are you willing to share your project with Steve, so we can try and figure out what the underlying problem is?


:@Lori No that iface:cvf stuff went a long time ago.  A question is that can XE and XE13 update 5 co-exist on the same machine using VS2010 shell?  Or perhaps failing that I will install XE on another machine of mine I believe the licencing allows this (A have a normal commercial single user licence).

I am reticent to share the project due to commercial sensitivity however creating a smaller sub-set  that creates the problem would be easy enough I think and better anyway. I can't do this at the moment as I had to uninstall XE 14.

There must be some wampy interaction either from my code with the runtime stuff or specific to my machine that causes this otherwise I would expect a thousand users would be heading  for Intel with pitchforks right now.....






Yes, the two versions can coexist and you can switch back and forth using Tools > Options > Intel Composer XE > Visual Fortran > Compilers.

Retired 12/31/2016

OK thanks, I am guessing it is a custom install and I have to tell it to keep the old version and integrations?

Actually, no. Just install both versions normally. You get the later integration, but that allows you to select the older compiler.

Retired 12/31/2016

OK thanks Steve, a small observation not worth a thread,  the c_loc,, c_sizeof etc  do not get highlighted in blue in VS editor as like all the others intrinsic s do, even the non-standard ones. Is that deliberate or on omission? It would be nicer if they did. I suspect it is deliberate because they are module procedures. 

I believe you are correct. We may want to revisit this in the future.

Retired 12/31/2016

Program Main

	    implicit none

	    do while(.true.)




	function initialsettings()

	    implicit none

	    logical(4) :: initialsettings

	    integer    :: iochk


	    initialsettings= .true.

	end function initialsettings

Having striped every thing away my Quickwin application only has one line of user written code that is executed, the open statement and this still causes the invalid handle exception (see attached jpg). 

The Project still contains 19 other source files and around 700 subroutines which get baked into the exe, I will try to remove things a bit at a time unit it works, but this might be hard work due to interdependencies.


Downloadimage/jpeg Capture_1.JPG42.64 KB

Can you post disassembly of the code around address 0x7775fba1? I suppose that at this address the already invalid handle is  used  by NtReadFile or NtWriteFile(invalid handle exception is probably thrown from KernelBase.dll).I think that variable which holds the integer value of handle gets corrupted somehow in the course of program execution.

Iliya, I'm not sure that is going to help me a great deal, we are heading into territory that is rather beyond my knowledge, and is quite probably some unforseen or unusual  interaction within the Intel quickwin coding. Prior to the exception in my test case I haven't executed any of my coding, we are on the first executable statement!. I have attached a screen grab of the disassembly.

I am hoping to generate  a greatly reduced size project I can sent to Intel.



Downloadimage/jpeg asm.JPG40.06 KB

I reattached the disassembly dump at the exception but with symbols loaded and also the call stack. This was the full program rather than the reduced program but the behaviour is identical.


Downloadimage/jpeg asm2.JPG59.74 KB
Downloadimage/jpeg stack.JPG42.86 KB

It looks like a indirect call into Thread Environment Block (TEB) structure which could probably cause the invalid handle error.The exception is thrown during stack cleaning (add esp,4) after function call. Later I will check with windbg what is located at FS:[0x0C0] address.

I suppose that error is not directly related to your program,although without seeing what is called at FS:[0x0C0] and inspecting its arguments nothing can be said about the culprit.It could be also system induced error mainly because TEB structure is set during process creation phase.

@iliya: Thanks for input, I'll gave a further dig around it later perhaps, got to dash now to catch a flight to Paris.


My thought is is goes wrong in the fortran _for_release_lun   (lun=logical unit number) as all open and inquire statements that have a unit number crash, but for example an enquire by file rather than unit does not crash...

Can you explain what cadfil.exe!_for__release_lun() + 1bc does? It seems that at this address  is called NtReleaseMutant which next calls itself. Afaik that function receives a handle to Mutant(Mutex) object which in turn is obtained from the call to NtCreateMutant.Could that handle be invalid?

Does your code call NtReleaseMutant? because it seems so by looking at diassembly where ReleaseMutant is checking SEH block.

You are right that we are stepping into Windows kernel territory which is scarcely documented.

_for__release_lun()  is not my routine, it is part of the fortran system invoked via the "open" statement. fortran release logical unit number (the forttran "file handle") is my guess.


So the problem probably originates in Fortran system code?Manually debugging with the VS debugger will not help us at least to understand whose handle is corrupted.If you could create minidump file and upload it.

Yes that why I think a need to pair down the project and send it to intel. I'll have a further look at it when I get back home in a couple of  days unless I get bored in a hotel somewhere....

I am still not sure if the problem is caused by Intel fortran compiler,but I do not  exclude such a possibility either.As I mentioned in my previous post a full process minidump could be very helpful in order to find where the problem originates.

I did some work on this last night with some very surprising results.

I copied all the source files and made a new project with the intention of eliminating bits of source code step by step until the problem went away. But the application build and ran with NO problems!. I found some compiler settings were not the same in the new project so  some changes later they were identical and it still worked! I note there are some differences on the linker command line that I need to investigates and it is not also beyond the realms of possibility that  library paths could be an issue (versions of library found that is linked to).

I haven'y checked the help yet but is there a verbose mode for the linker that shows the paths of libraries that are used?



/verbose:libs is the linker option. In VS, it's "Show Progress > Show some progress messages".

Retired 12/31/2016


Congratulations on solving the problem.

I have attached a zip with two build logs. There are two different projects that contain exactly the same source files, one is the 'old' project and one the 'new' project (called qwin1), both in the same solution is vs2010 shell.

The are both built with exactly the same compiler options on the latest compiler revision and build with no errors. The link commands are slightly different as:

The Old project uses relative path and has /LIBPATH:"." in the build.

The new project has absolute paths and has /IMPLIB:"C:\Users\....\QWin1\Debug\QWin1.lib" added (it did this by default). Qwin1 is the project name but this lib is not created by the project and does not appear to exist.

I have the verbose option on the linker and it appears (as far as I can see) that exactly the same libraries are used in the link.

Project old generates an exception (handle error in _for__release_lun() ) (as described earlier in this topic) on the first Fortran open (and all others as well)  but returns no Fortran error from IOSTAT.

Project New runs fine, no problems. On the old compiler (update 5: XE both projects build and run OK. 

Anyone got any explanation? I makes no sense to me. Clearly I can make a new project and it works but this leaves me unhappy as  things not working for no explained/logical reason is very worrying.




Downloadapplication/zip Desktop.zip5.67 KB

I don't see anything obvious. Ignore the /IMPLIB setting - that gets used only when generating a DLL. An interesting experiment would be to copy the failing project to a new folder and do a Rebuild there. Same problem? I wonder if you have something on the system corrupting your EXEs.

Retired 12/31/2016

@steve not tried your suggestion yet but I have noted that in the failing project 1 source file (getfileopen..) generates an .asm file but when I look at the build properties for that file for that file I note that no asm listing is asked for. BUT the command line for that file is different (a couple more warning diagnostics are excluded) AND its appear to have  /Fa"Debug/" in the command line!

So I removed the source file from the project.

Closed VS saving the project

Opened  VS and the solution

Added existing source file (the missing one) and build. It compiles with no ASM generated.

I then customised the properties for that file to suppress warnings about 6463 and 7410 and recompiled and I now get as assembly listing! But the is no FA entry for the command line in VS for that file.

Is this project just messed up?

Interesting. Please attach the .vfproj file so I can take a look.

Retired 12/31/2016

the Vproj is attached, it is xml?


Downloadapplication/octet-stream cadfil70.vfproj10.78 KB

hmmm looked at that in notepad there are a mess of configurations release/win32 and debug/win32 are the only used ones.

I see what is happening. The project has a sort-of non-default value for the assembly output directory, and even though no assembly listing is asked for, the IDE adds /Fa to specify where one should be placed and this causes the listing to be created.

To fix this, temporarily change the Output File > Assembler Listing value to Assembly Only. Change ASM Listing Name to <Inherit from project defaults...> and then change Assembler Listing to <Inherit from project defaults...>

Retired 12/31/2016

Ah OK yup that problem has now gone away the original issue is still with me. Further tests required. 

OK I left all the project files where they where an made a new project in the same solution and removed the old project. It builds and runs with no problem in debug and release for both compiler versions (XE and XE

After extensive tests I cannot find any reason why the old project fails. The only difference I have found is that if you look at the verbose logs for the linker the old project cycles through the system libraries (Ifort/sdk etc) in a slight different sequence so it is possible that if some calls can be resolved from more than one library then a different code might result. If this were the case there is a bug lurking to bite again at some point.....

I seem to have wasted about 10+ hours on this so I give up and will just except that it now works



What's that deskey32.lib thing.  How does it end up being pulled into the link?

It is an interface layer for a USB device, there are !DEC$ objcomment lib:"deskey32.lib" in the source and the lib is sat in the project folder. There is only one version of the lib on the PC other than a 64 bit version which has a different name which I think you can guess.

Leave a Comment

Please sign in to add a comment. Not a member? Join today