Debugging x64 code in Visual Studio 2010 doesn't allow one to view 64-bit addresses

Debugging x64 code in Visual Studio 2010 doesn't allow one to view 64-bit addresses

I originally posted this a while back in the general IVF forum, but no one was quite sure what to do with it. Now that there is a dedicated debugging forum, I'll try here! Here is a summary of what I found, and what went on:

When I attempt to build our code for x64 architecture through VS and
debug it, then view the "Memory windows" during debugging, I get nothing
but ??????'s for all addresses and variants of display types.

can successfully tell the window to display a given address using
LOC(variable) (but going by straight memory address gives problems as it
will show me 0x7FFFFFFF). LOC(variable) works fine, except that no
matter what variable I choose, it shows me nothing. In a possibly
related issue, attempting to use data break points results in the
breakpoints being skipped entirely.


Now, using the immediate window I can get the address of implicitly
defined variables, but when I paste it into the memory window I don't
think it works quite right. If I want to look at the location of implicit_variable_1, I go to the 'Immediate Window' and type LOC(implicit_variable_1)
and get an address, #00000001888EBD20 (which would be a 64-bit address
if I am not mistaken). I then go to the memory window and paste this
address into the 'Address:' field and the memory window brings up
location 0x7FFFFFFF (the 2GB or 32-Bitlimit, if I am not mistaken) and a
whole lot of ??????? (the original question that started this thread).
If I type the variable name implicit_variable_1 directly into
the 'Address:' field, it shows me a memory region starting at 0x00000020
or something equally incorrect (along with said ???????s).

If I switch to the not implicitly defined variable var_1,
and I type its name directly into the memory window's 'Address:' field,
it pops up with a seemingly correct memory location. One that holds
what I am expecting and corresponds to what I get from the 'Immediate
Window' using LOC(var_1). For example, if I type var_1 into the Memory Window, I get address 0x0000000186DAF9F4, and when viewed as a real, it shows me the value that var_1
should have. However, if I turn this around and type the address into
the 'Address:' field directly, I once again get taken to address
0x7FFFFFFF and see all ???????s. Typing LOC(var_1) in the
'Address:' field takes me to 0x86DAF9F4 (seemingly corresponding 32-bit
address, even though it is above the 32-bit addressable space) in the
memory region and shows me all ?????????s.

If I attempt to set a
data break point on the address of the explicitly defined variable
(0x0000000186DAF9F4 or what I presume is its 32-bit equivilent of
0x86DAF9F4) it tells me it is setting a breakpoint "When '0x7FFFFFFF'
changes (4 bytes)" which is clearly incorrect.

It seems to me (in
my only slightly educated opinion) that there is confustion about 32
and 64-bit applications and addressing schemes. That said, I have no
idea if it is a Visual Studio issue, or an IVF issue, or if it is no
issue at all and I just have something set incorrectly

Here is a simple program that is able to reproduce this issue:
[fxfortran]program fortBreakTest

implicit none

! Variables
double precision, dimension (1000000) :: array
integer :: i, j, k
! Body of fortBreakTest

i = 0
j = 0
k = 0

do i = 1, 1000000
array(i) = i

i = 1

j = 2*i

do i = 1, 10
k = k + i

print*, "I, J, K = ", i, j, k

end program fortBreakTest [/fxfortran] In the debugger I have break points on the i=0 and i=1 lines. If I ask for the location of array(1000000) in the Immediate Window, I get

LOC(array(1000000)) into the Memory Window's 'Address:' field brings up
the memory location 0x40216298 and gives me a whole lot of ????????s in
the display. Pasting the address (0x0000000140216298) into the Memory
Window's 'Address:' field brings up 0x7FFFFFFF and displaysa lot of

Entering array(1000000) in the 'Address:' field
brings up 0x0000000140216298 and shows the contents of that array
element correctly. However, if I take even a single step with the
debugger the Memory Window switches from the correct memory location to
0x7FFFFFFF and displays ????????s all the way around.

Hopefully this will allow you to reproduce what I am encountering and suggest a fix/way around it. Thanks again for your help.


As a quick update, creating a very nearly identical program in C++
(compiled with Visual Studio's C++ compiler, not Intel's) and running
the exact same tests worked just fine. The Memory Window in C++
debuggerhappily accepted addresses in 64-bit form, both if input
directly, or as the address of the array variable.


This occurs(ed) with both IVF and the latest we've tried, 12.1.3526.2010.Thanks for any help people can provide, this bug makes it near impossible for us to begug the 64-bit version of our application and we'd really like to have that ability. I can post screenshots of this behavior if it will help.

4 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

This may be one of those 'Fortran culture' versus 'C culture' issues.

> Pasting
LOC(array(1000000)) into the Memory Window's 'Address:' field brings...

If, in the Memory window, you type


instead of either LOC( the same variable ) or the 64 bit hex address value given by the Immediate window, the correct value is shown.

This may be a little irritating if you are used to typing in 0xnnnnnnnnnnnnnnnn when debugging a C program, and it can even be a significant problem when debugging mixed C and Fortran codes. However, for a pure Fortran program, just typing the subscripted variable works, which suggests that the GUI evaluates what you type in as an address expression without dereferencing that address.


sorry to hear that you did not get help instantly. Thanks to your good description I was able to reproduce the problem and can confirm this as bug in the Fortran Expression Evaluation (FEE) which comes with our integration.
A defect was filed (DPD200288770) and engineering is already working on it. I'll let you know as soon as it is fixed.

Best regards,

Georg Zitzlsberger


I'm happy to announce that we'll have this problem fixed with Intel Composer XE 2011 Update 11. It will be available in a couple of weeks.

Best regards,

Georg Zitzlsberger

Laisser un commentaire

Veuillez ouvrir une session pour ajouter un commentaire. Pas encore membre ? Rejoignez-nous dès aujourd’hui