The breakpoint will not currently be hit.

[Ryan_Smith]

I am unable to debug my Intel Visual Fortran code with Visual Studio 2008. I am able to place my breakpoints, but when Istart the debugger my breakpoints change to hollow circles with a yellow exclamation point with the attached message: "The breakpoint will not currently be hit. No symbols have been loaded for this document." I've double-checked my settings to be sure everything is compiled in debug mode. I've tried deleting the /bin directory andletting a clean build recreatethe files saved there. I've tried all the suggestions I've found on the internet. No luck. Someone please lead me in the right direction to get my debugger working for my Fortran code.

[Les_Neilson]

The "obvious" answer is that that routine is not called anywhere in the program.
I have had this where there are two or more routines with the same name (a valid situation; each doing slightly different things for the exes concerned) and I have been in one exe looking at the "wrong" file.

Search your code for all occurences of the name of the subroutine to : (a) ensure it is called and (b) if there is another routine of the same name which is being linked in instead.

HTH
Les

[Ryan_Smith]

Well, I have the same issue with two different projects. One project is very large and involved, but the Fortran piece is only called in one place from the VB.NETpiece. The other one is very simple. I created the simple one to see if I could recreate the debugging problem. It is a very small vb.net application that calls a very simple VF function. The two pieces work great together and generate accurate results, but I can't get my debugger to work with any of the Fortran lines of code. I'm positive that my breakpoints are placed on valid lines of code that should trigger the debugger. My VB.NET lines of code are working great with the debugger. Help me.

[dajum]

You will see that happen if what is being executed isn't what is being displayed. Check all of you paths in the build and make sure you are starting and executing a file that was built from that source. I find I hit this when I copy projects and forget to change one setting.

[Les_Neilson]

Quoting - Ryan Smith

Well, I have the same issue with two different projects. One project is very large and involved, but the Fortran piece is only called in one place from the VB.NETpiece. The other one is very simple. I created the simple one to see if I could recreate the debugging problem. It is a very small vb.net application that calls a very simple VF function. The two pieces work great together and generate accurate results, but I can't get my debugger to work with any of the Fortran lines of code. I'm positive that my breakpoints are placed on valid lines of code that should trigger the debugger. My VB.NET lines of code are working great with the debugger. Help me.

Well, I have absolutelyno experience of VB but ...
We have some C# projects which call Fortran. When I start debugging then the Fortran breakpoints turn to the hollow symbol with exclamation point - however when I select a command which takes me into the fortran code the debugger will stop on the breakpoint.

Since you say the code executes correctly(grasping at straws here) could it be you have mixed debug VB with release Fortran ?

Les

[Ryan_Smith]

I'm missing something. My simple solution contains 2 projects. One is VB.NET project (VBCaller.vbproj). The other is an Intel Visual Fortran project (VFResponder.vfproj). Each project contains 2 files thatare code.The two VBCaller filesare .vb files. The two VFResponder files are .for files. Everything compiles beautifully. Everything runs beautifully. I have edited the "Debug Source Files" settings to look at every directory I could imagine that might contain the code or "symbols" that the debugger is looking for. I have modified the "Project Dependencies" to every possible combination. I have made changes to the "Startup Project" to try to get the debugger to work on my Fortran code. As far as I can tell, everything is being compiled in Debug mode. I'm not afraid to admit when I don't know what I'm doing, but should it be this difficult to get the debugger to work? Someone please tell me that you've had this problem before and you figured out how to fix it. I'm going on 3 weeks of this not working. I need a hero.

[Steven_L_Intel1]

Can you construct a test case and attach it here? I agree with others that this is almost always a case of the DLL being loaded not being the same as the one you built.

When you start the program in the debugger, select Debug > Windows > Modules. This will list all the DLLs you have loaded, including their paths.

[Ryan_Smith]

Apparently, I have 56 dll files trying to load when I try to debug my VF application. 37 of them have the Symbol Status: "Cannot find or openthe PDB file." 18 of them have the Symbol Status: "No symbols loaded." Only one (msvcm90.dll) has the Symbol Status: "Symbols loaded." Since my warning message says "No symbols have been loaded for this document." I guess I need to figure out which of the 18 dll files with Symbol Status: "No symbols loaded." will cause the "Symbols" to be loaded for my fortran code. I also need to figure out how to "load" the "Symbols" if that's what I really need to do. There has to be a better way.

[Steven_L_Intel1]

The only DLL of interested is your DLL. Check the path to make sure it's the same one you built. If it is, the symbols should load automatically.

[Ryan_Smith]

My compiled dll doesn't even show up in the list.

[Steven_L_Intel1 · Accepted solution]

Oh - it won't until the first time you call a DLL routine from VB.

Something just occurred to me. Right click on the VB project, select Properties > Debugging. Make sure that "Enable unmanaged code debugging" is checked.

[Ryan_Smith]

Thank you Steve!!!!! You are my new best friend. I am hitting the breakpoints in my Fortran code now. The "Debug unmanaged code" setting made all the difference. I thought I had already tried that, but I guess I didn't do it right. Thank you so much for getting me over this hurdle.

[Steven_L_Intel1]

Glad to hear it!