Visual Studio .NET Debugger not working with Intel Fortran

Visual Studio .NET Debugger not working with Intel Fortran

Hello all!

I've run into an itneresting issue. I've been trying to use the debugger that is part of the MS Visual C++ .NET 2003 Standard to debug Fortran code (Intel Fortran Compiler V8.0).

The trouble is, none of the variables I add to the watch list are ever recognized (they are reported as being undefined) I can view no arrays using the Array Visualizer, and the Command Window (in Immediate mode) doesn't understand any of the variables either.

What could be causing this? I read in the Forums here that the Intel Fortran compiler is completely supported by the VS.NET debugger.

Any help would be greatly appreciated.


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


Awhile back I read about the need to configure the debugger for various operations. This problem wouldn't happen to be related to this, would it?

The only configurations I've been able to find for the debugger are for the target path, command line parameters, and working directory.


No configuration should be needed. When you start VS.NET, does it show the Intel Fortran logo (F in a blue box) in the splash screen? In VS.NET, select Help..About, then Intel Fortran Compiler Integration. What version does it show?

Retired 12/31/2016

I have the Intel Fortran logo (F in a blue box) in the splash screen displayed when open up the studio, I may be slightly lucky that I can do a little debug under visual studio 2002. I have a question with ID 8943 on this forum which I am trying to get some helpon debug aswell. My personal experience is:

1. The debug won't show the array with dimensions equal or more than 3.

2. Sometimes, thewatch windowtells you that the variable is not defined, but theyactually can produce correct result.

3.Sometimes it can beeven worse, the data show in the watch windows can show the wrong data.

4. If you are trying to set data breakpoint as it can be done in CVF6.5 under VS 6.0 (used to track the data change), it can be very difficult. I have not found a solution yet, I followed the document and no chance of success yet.

I hope someone who has some success experience on using the debug under IVF can share some good experience with everyone.



Message Edited by wu_internet on 04-28-2004 06:07 AM

The logo does appear in the splash screen.
The following information is shown in the "Help. About" area.

Intel Fortran Compiler Integration for Microsoft Visual Studio .NET 2003, Version 8.0.1877.2003

This version is the free trial download version. Would this play a part in the issue?


Please download and install the 8.0.047 kit. You get 30 days of full support for the trial. I'm not sure if you had to register with Premier Support to get the trial, but if not, follow the registration instructions in the e-mail you got that included a serial number.

Retired 12/31/2016


I have just downloaded and installed the "47 kit" you told me about. I also installed the patch. Latest version listed by VS.NET now is:

Intel Fortran Compiler Integration for Microsoft Visual Studio .NET 2003 Standard, Version 8.0.2149.2003

However, I am still unable to do any debugging. All watched variables are still listed as undefined, etc. I did register with Premier and have posted over this issue with them as well.


It might be interesting to note, that when stepping through the code, there is a portion which is written in C (input output stuff for console applications under Windows. Standard operation.). In this section of the code, I CAN view the variables and arrays. It seems to be a Fortran only scenario


Please continue this with Premier Support. I'm sorry to hear you're having troubles, and I hope they're resolved soon.

Retired 12/31/2016

Just out of curiosity, is anyone else having this issue?


Exactly! I have the almost same problem with debugger. I am running visual 2002, IVF Pro 8.0 (w_fcp_p_8.0.048 kit) and Win XP. The variables in the watch list is said "undifined" while the program can run very well. There was no this problem with my C++ programs.

I just hate trying to look up a problem and instead of finding a solution, find such as message as "Continue with Premier Support". That does NOT help the rest of us who are having the same problem and are trying to decide whether we have to purchase many copies of a newer version of CVF or if we have to purchase many copies of IVF (Intel) or maybe neither, and have to purchase many copies of yet another brand of Fortran to solve this problem.

Now I (we) have been using Visual Studio 6.0 with CVF 6.1 for many years just fine. We recently spent about 2 months converting our projects to Visual Studio .NET 2003 and thru extensive use of CUSTOM BUILD rules and many .BAT files (since there's now a size limit on custom build rules) have successfully gotten our massive set of code to run properly under .NET 2003. We were just starting to turn this conversion effort over to our developers as their new develoment platform, when we got slapped in the face with the debugger not being able to locate the symbols for any FORTRAN variable that was declared as an ARRAY. Other variables (anything but an ARRAY) is just fine with the debugger.

Well, after pulling out a lot of hair and doing many web searches with Google, MSDN, as well as on the HP, Compaq, Intel web sites and bulletin boards we have seen that several others (but NOT a huge number) have been having the same problem, but no-one is offering any definitive solution. Compaq/HP has passed the buck to Intel, saying that Intel is the only ones with full integration, but now that I am here, I find the same problem being reported with the Intel IVF.

Now I have ordered 1 copy of IVF for a test platform, but at this time I am still awaiting it's arrival. If I am able to solve this problem, we will be needing a few dozen copies of whatever FORTRAN that we find can solve our problem. In the meantime, I am still trying to learn more about this problem and whether or not any solution exists.

Also, our management has ordered us to return to using Visual Studio 6.0 until such time as we are able to get a debugger for FORTRAN which works with the Visual Studio .NET 2003.

Some of my research seems to indicate that the installation of (either DVF or CVF) FORTRAN under Visual Studio 6.0 effective installed a plug-in of some sort into the Debugger. I have also found many similarities in the some of the configuration files for the 2 Debuggers, for example

    C:Program FilesMicrosoft Visual StudioCommonMSDev98BinAUTOEXP.DAT
    C:Program FilesMicrosoft Visual Studio .NET 2003Common7PackagesDebuggerAUTOEXP.DAT

appear to use the same syntax and except for a few minor additions of new types are identical. This leads me to believe that there the core debugger may be quite similar between the 2 versions, although I was unable to find any information to directly support this. It also leads me to believe that under version 6.0, the Debugger had been "TAUGHT" how to read the FORTRAN ARRAY symbols information thru some sort of plug-in.

Now IF the Visual Studio .NET 2003 Debugger fail
ed for everyone, then I would also expect much more outcry from the user community, but I have not seen that. Is there an installation issue? Is there some order of installation and/or some set of options which can be chosen during installation whereby the Visual Studio .NET 2003 Debugger can also be "TAUGHT" how to understand FORTRAN (IVF inyour case)????

--- Jim B

The debugger interface for the "plug in" is very different - the way the Fortran "expression evaluator" is called is very different between the two versions.

There is not a universal solution for the problem some people are seeing. This is why we urge you to contact Intel Premier Support if you have problems with the Intel product.

Retired 12/31/2016

Yes, I've also had similar problems and Intel Premier Support has confirmed that it is a problem - at least for the scenario that I submitted. Intel Premier support said, "Ihave found out that there was already a defect with IDE showing the incorrect values of module variables. I am going to add this issue into the affected list for the defect."

If you want to reproduce the problem I've attached a small project that will demonstrate the problem in the debugger.

Please see the attached zip file -

It contains the file

The main project file for Console2

This is the main source file for the Fortran Console application. It contains the program entry point.

global.f90 - global module containing global declarations used through the program

mod1.f90 - module containing type declarations

sub1.f90 - subroutine to read in some data - uses a contained subroutine readinfo

You can't access the variable grp03 (a variable using a defined structure) in the debugger even though the program successfully reads, and then writes out the information in the structure. As well, even within console2.f90, you can't see the grp03 variable even though it's in scope.
To provide debugging support for the programming work I'm doing, I've resorted to using CVF Version 6.1 while Intel works on the problem.

I think this is broken altogether; on my system with 8.1, grp03 is accessible in watch window, but it displays plain wrong results (which is equal to unusable).

Similar bug(s)is/are reported here and here as well.

In general, I notice a general problem with array descriptors. In Visual Fortran, an allocatable or pointer array is "two-fold": there's so-called array descriptor, which is a 28-byte structure describing array's starting address, allocation status, stride, extents etc, and there are the contents of the "target" itself. With scalar pointers, there's also a 4-byte "pointer descriptor" (containing only target's address)and the address of the "target" itself.

Normally, the programmer does not (and should not) know/care about the descriptor itself (you could reach it through "memory" window). However, thereare (related?) bugs all over the place -- the debugger frequently maps the memory contents of the descriptor instead of memory contents of the target. The compiler itself also has some problems in the area (passing pointer-valued expression as an actual argument is still broken, LOC() returns wrong address here and there). Also, I submitted few bug reports, some fixed, some not (245385 Steve... please...)

Lemme checkyour particular case... yes. When I type "grp03, x" in the Watch window, I see that grp03%lenf contains hex sequence "00582E30". In Debug->Memory window, when I type 00582E30, I see the real contents of grp03 array, but it's not very useful to watch them as hex bytes.

I think thisis really closeto the category of "showstoppers", and yet it remains buggy in each release.


Would those of you who have reported the problem please provide me with the six-digit case number? Thanks.

Retired 12/31/2016

The number of mine is 243314. The status is Reproduced (Escalated) since three months ago. I had uploaded a simple program to show the problems with this issue.

To me, CVF's debugger is much stronger and can recognize most variables while IVF's debugger seems to work only with the variables defined locally. I have some modules, which also contains subroutines, used in the program. IVF's debugger almost no use for the program. I have to use the old CVF to debug it. Also, I do find the cases that even CVF's debugger can't recognize the variables, quite seldom though.

Thanks for the info - I will see if I can get some movement on the issue.

Retired 12/31/2016

I have also submitted a similar problem sometimes ago under the
issuenumber Q217865: Impossible to view a structure component that is a pointer in debugger

Best regards,

Jean Vezina


The number for my issue was 263998 .


I found a solution for my case, but I am now wondering if I am going to encounter a licensing issue???

My case was very simple to explain. Take this sample F77 program and try to type A into a watch window.
real A(10)
DO i=1, 10
A(i) = i*1.5

Can you see the value of A or does the value show up as
CX0017: Error: symbol "A" not found

I installed a copy of Intel Visual Fortran 8.0. I found that once I did that, my .exe which was built with CVF 6.1 was then able to be debugged using Visual Studio .NET 2003. When I deinstalled IVF 8.0, I could no longer debug because I was missing fileC:Program FilesMicrosoft Visual Studio .NET 2003Common7PackagesDebuggerNatDbgEE.dll
which I then copied from another machine, and I was right back where I started with ARRAYS not being known symbols to the debugger. I then reinstalled IVF 8.0 a second time and looked in that folder and found that in addition toNatDbgEE.dll there are also 3 other new files. In all there are 4 files in that folder with a more recent timestamp as follows:
03/05/2004 03:49a 249,856 fordbgee.dll
03/05/2004 03:49a 53,248 fordbgsw.dll
03/05/2004 03:50a 589,824 forops.dll
03/05/2004 03:49a 53,248 NatDbgEE.dll

When I copy these 4 files to a machine that only has CVF 6.1 and Visual Studio .NET 2003 then the debugger is then able to see FORTRAN 77 arrays.

There is no IVF installed on this machine. Is this permissable to do or does it violate any license?

Yes, it violates your license for IVF. Those files are not considered "redistributable".

Retired 12/31/2016

Is there any way to purchase a license for only the debugger component of IVF? We are currently working on a contract to convert our FORTRAN code to C++ 7 which requires Visual Studio .NET 2003. This is only for a temporary basis so we cannot justify the cost purchasing 9 more full copies of IVF just for the ability of using the debugger with no intention of ever using the FORTRAN 8.0 compilier. We would be willing to pay a modest amount for just that one component of IVF. Who would we contact at INTEL to address this possible license purchase????

No, sorry, we don't sell it that way.

Retired 12/31/2016

Are the debugger support files included with the standard version of IVF or only with the professional version? Are they also included in the trial version?

The Standard and Professional editions are identical except that the Professional also includes the IMSL Fortran libraries.

The trial version is identical to the Standard Edition. The debugger support is in all of these, but is subject to the license.

Retired 12/31/2016

This is a long thread - exactly which problem is it you are seeing?

The current compiler version is 8.1.023 (the version number you give is actually the IDE integration version, not the compiler version).I would recommend contacting Intel Premier Support if the issue, whatever it is, does not seem to be resolved in the current version.

Retired 12/31/2016

Dear ,
You only mentioned the C++ compilier. The problem this thread was addressing was not being able to see FORTRAN arrays in the debugger. For me, the fix was to have the following 4 files from the INTEL VISUAL FORTRAN (IVF)copiedonto each of mymachines.

C:Program FilesMicrosoft Visual Studio .NET 2003Common7PackagesDebugger

03/05/2004 03:49a 249,856 fordbgee.dll
03/05/2004 03:49a 53,248 fordbgsw.dll
03/05/2004 03:50a 589,824 forops.dll
03/05/2004 03:49a 53,248 NatDbgEE.dll

In my case, I am using the olderCVF 6.1 with Microsoft C++ that comes with Visual Studio .NET 2003. I had to purchase 10 copies of IVF to get the licenses to use the above mentioned 4 files. These debugger files work with either FORTRAN, CVF or IVF.

If your situation is different, you should contact Intel Premier Support.

I have experienced the same problem of examining variables in a .NET debugging session with IVF 8.1.025 (12/3/04). I've included a simple program that will demostrate the problem. This is the same example I've submitted to as issue number: 275151.

I set breakpoints at each of the print statements during debugging to examine the program variables. The print statements in the code produce the correct output to the console (1 & 2 respectively). At the first print statement, I can navigate the watch tree down tdd(1).Tile_Drain_Practice.draincode but the value is not 1 as expected, but some long integer. Then at the Tile_Drain subroutine print statement, I try to watch tdd and get a "undefined variable tdd". Hope this helps.

My colleagues and I are very concerned about this deficiency with the intel compiler -- we don't see this behavior in the Salford 95 Compiler or with CVF running with VC6. We would like to recommend the Intel compiler for use by our Agency on a national basis because it's blazingly fast, but this is a serious concern for debugging purposes. Any help with this would greatly appreciated. We need to make a recommendation on which compiler to buy for our developers in the agency to national headquarters by the end of this week.

PROGRAM Data_Prep_Control
TYPE Tile_Drain_Practice
ENDTYPE Tile_Drain_Practice
TYPE(Tile_Drain_Practice),ALLOCATABLE,TARGET:: tdd(:)

tdd(1)%draincode = 1
CALL Tile_Drain
tdd(1)%draincode = 2
ENDPROGRAM Data_Prep_Control


The issue number for my post to premier is: 275151



All I can tell you is that we have engineers investigating the problem. I am confident that it will get fixed, but I don't know when.

Retired 12/31/2016

Dear all,

allow me anxiously to ask for any new info on this same problem. I must add that this problem occurs ONLY when Visual Studio .NET 2003 is installed on a directory other than C:. I have followed the fix:CS-015862 and everything worked EXCEPT from the debugger. I have also noticed that the forops.dll, fordbgsw.dll and fordbgee.dll are MISSING from the folder ..Common7PackagesDebugger. The error message that I get when starting the debugger is: "The Fortran Debug expression evaluator is not properly installed..."
Please advise

That problem is different and was fixed by the 8.1.021 update.

Retired 12/31/2016

Has there been any progress on that issue lately ?


I have just installed version 8.1.030 of the Intel Visual Fortran compiler and I am still running into similar problems with the MS NET debugger and Intel Visual Fortran. It appears to be able to drill further down into the subroutinesand be able to get the values of the variables, but when I go into a internal subroutine within a subroutineI lose access to all of the external variables.

Has anyone else had any similar problems?


P.S. For the Intel support with access to the problem board, please see issue number263998.

We have fixed some bugs in 8.1.030, but more remain. If you find new problems, please report them - that way they'll get fixed. We do have engineering actively fixing the debugger bugs.

Retired 12/31/2016
sblionel wrote:
We have fixed some bugs in 8.1.030, but more remain...

Steve- Does 8.1.030 address my simplest of example from ID#: 11746? We've been waiting for many moons for Intel to address this...

Thanks for keeping them moving on our behalf. I don't know how they sleep at night, knowing they are selling a product and collecting a paycheck, that is only 1/2 functional. Having a functional debugger is a Necessary part of a software development IDE.

Ken, I think it does. There is a new 8.1.031 which should be available from Intel Premier Support now, I suggest you try that.

Retired 12/31/2016


I just tried your example and it works perfectly in 8.1.030.

Message Edited by sblionel on 05-27-2005 04:48 PM

Retired 12/31/2016

Leave a Comment

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