Debug Problem

Debug Problem

I have a main fortran program that calls a fortran dll. The main program and the dll share the same common blocks. DLLIMPORT declaration is used in the main program and DLLEXPORT is used in dll for these common blocks. However, in the debug mode with a break point in the main program , the watch window listing the variables for these common blocks shows undefined values. I added write statement to main program for these variables and it returns the proper values.

Why does the watch window show an undefined value when the write statement show a proper value? Can the watch window be set up to show the proper value of the variables defined in the common block when debugging the main program?

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

Compiler version? This was broken in CVF at one point (a year or more ago), but should work in the current version.


Retired 12/31/2016

I am using version 6.6B. This problem existed on version 6.6A as well.

Send a zip file of a sample project to


Retired 12/31/2016

A zipped file has been sent.


I've had similar problems exporting common blocks to DLLs and trying to watch variables. A couple of things to remember:

1) If your DLL code doesn't use any of the common block variables, the block won't be imported and thus you won't be able to 'watch' variables in said block (even if you have the correct import statements and common block definitions). For debugging you can do a dummy use - set a local variable equal to a variable from the common block of interest.

2) Make sure you aren't watching the 'local' definition of the common variable. Supposing in the main program you have a common block called MY_COMMON containing a structure MY_STRUCT containing a variable MY_VAR, you would probably type


in the watch window.

In the DLL you need to be specific about where you want to watch the variable. You should have imported the common block by name (MY_COMMON) and so you need to modify the watch window to:


Having said all that, I've recently noticed a couple of problems with 'undefined variable address' which might be related to debugging the DLL with a release executable. That's a guess though, because I haven't fully investigated it, but it seems reasonable to assume that since the 'owner' of the common block (i.e. the EXE) has no debugging information, you can't see the variables. Having said that you should be able to build your release configuration with a PDB file which should rectify the problem. Again though, I'd need to investigate further

A little further digging on my part has revealed that I can watch common block variables when my exe is debug, or when it is release, with or without the PDB.

However, some of my users report begin unable to watch common variables in the manner I use. The main difference between our machines would be that mine has a full Developer Studio with VC++ 6 and CVF 6.6B whereas the users only have CVF 6.6A.

Steve, are there any differences between the CVF DevStudio framework and the one you get from MS (e.g. with VC++6 etc.)...?

No differences in Developer Studio.


Retired 12/31/2016

Judd, I tried your idea and it works. Using the following structure in the watch window, the proper values were shown.



Well, it almost work. If the common variables are used within the DLLEXPORT subroutine, the variable will show up in the watch window using the MY_COMMON.MY_VAR structure. However, common variables updated by subroutines calls within the DLLEXPORT subroutine are not displayed.

The search for a solution continues!

Have you remembered to DLLIMPORT the common block name into every code file that uses the common block? I forgot to mention it in the previous reply.

You either need it in an include file or have the explicit statement in each file.




Currently I have only one place in my program that uses the common. The DLLIMPORT statement is set up in the same manner as you have specified. The call for the DLL subroutine is located in the main program.

However, the DLL subroutine calls several other secondary non DLL subroutines. These secondary non DLL subroutines are located in separate files and some of them use the same common. These secondary non DLL subroutines are currently compiled together with the DLL subroutine to form the DLL.

Should I place a DLLEXPORT statement in all the secondary subroutines that contain the same common. Normally I would think the DLLEXPORT statement is only required in the subroutine that is called by the main program.

You need a DLLIMPORT (not DLLEXPORT) for the COMMON in all routines that use the COMMON that comes from the DLL. Otherwise, you 1) might not get the same COMMON, 2) will confuse the debugger.

Retired 12/31/2016

I'll note that the Programmer's Guide tells you how to examine COMMON variables in the debugger. As suggested above, you treat the COMMON as if it were a derived-type variable - enter the COMMON block name in the QuickWatch window and a + will appear, allowing you to expand it - or you can use the cblk%varname syntax to look at individual variables.


Retired 12/31/2016

Leave a Comment

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