Breakpoint... No symbols have been loaded.

[Randy_M_]

I am in the process of updating an old VB+Fortran application into the world of 64 bit Windows.  I have a Visual Studio solution which creates a GUI that calls a routine in an Assembler DLL and then a selection from routines defined in Fortran DLLs.

When I try to define breakpoints in the Assembler and Fortran routines I am greeted with the warning:

          "The breakpoint will not currently be hit.  No symbols have been loaded for this document."

I understand that this is usually a result of the .pdb file associated with the DLL being either missing or out-of-date, but I have carefully ensured that the .pdb and .dll files are synchronized and both are in the folder from which the DLLs are being accessed. 

It is probably relevant to mention that the Fortran DLLs are loaded by a VB call to LoadLibrary.  The method for Loading and calling the Fortran routines is essentially the same as it was in the 32 bit world, and (though it has been well over a decade since I have worked on this particular software) I'm pretty sure that I used to be able to define breakpoints in the Fortran code.

It seems clear that I am missing or forgetting something, perhaps obvious and trivial.  Any suggestions about how to solve or diagnose this problem will be greatly appreciated.

Cheers,
Randy MacDonald

[Lorri_M_Intel]

What is more likely is that the DLL being loaded into your application is not the one you just built.

The order that Windows uses to find the DLL is:
    1) Same directory as the executable
    2) Current working directory  **
    3) Windows system directory
    4) Windows directory
    5) Somewhere on PATH

 **  By default in the Visual Studio environment, the current-working-directory is where the solution lives.  You should be able to override that by changing the property settings under Project->Properties->Configuration->Debugging

                  --Lorri

[jimdempseyatthecove]

A while back I encountered a similar situation. The work around I used was to add a " do nothing" routine to the DLL then at start of program have a call to that routine. Then place break point on the call, and then step into. If the step-into fails to step into the DLL, then at break point at call open a disassembly window and step into via the assembly code. Once there, you can set your break points.

Notes:

a) if the new dummy routine isn't present, then this confirms Lorri's suspicion that the wrong DLL is being loaded.
b) before doing the first step-into, open the Breakpoints window and click on the Delete All breakpoints (do not delete them individually as this isn't the same, it looks like it should be equivalent, but trust me that it is not). After deleting all break points, set a new break point at the call to the dummy routine. Once you do this, then future break points set in the DLL will be remembered correctly (assuming the correct DLL is the one that gets loaded).

Jim Dempsey

[jimdempseyatthecove]

Note-2:

A call into a DLL is performed via a vector table. Your Disassembly Step Into will first call to the vector dispatch table, then on next step into, will perform the DLL load and then appear at entry point of called routine in the DLL. IOW perform step-into twice when in disassembly.

Jim Dempsey

[Randy_M_]

Thanks for your notes Lorri & Jim.

I'm quite confident that the DLL being loaded is the one I expect.  I have tested this by renaming it, after which I get the report that the DLL can't be found.

As per Jim's suggestion I have tried to add a "do nothing" routine (called "Tester") to the Assembler DLL and I added a call to this just prior to calling the "official" routine (called "RunUnmanaged").  I deleted all breakpoints, then set a new breakpoint on the call to "Tester".  When the breakpoint at Tester was reached, I first added breakpoints to both Tester and RunUnmanaged.  Both of these breakpoints indicated they will not currently be hit. I then switched to the disassembly window and attempted to step-into Tester.  Maybe noteworthy here is that the "step-into" did not.  The action appeared to be identical to step-over.  This was repeated when I attempted to step-into RunUnmanaged from the disassembly window.

On a second attempt I followed the same procedure, however tried to step-into Tester prior to setting a breakpoint in RunUnmanaged, with the same results.

Jim, with regard to your Note-2 and the vector table, the calls to Tester and RunUnmanaged complete with just one step-into operation each.  Is there some clue in this, or is it just a further indication that the debug environment is really not seeing my .pdb files?

For reference, here is a copy of what I see in the disassembly window:

                Call Tester()
00007FF960E35390  call        00007FF960D07928  
00007FF960E35395  nop  
                Dim lngStatus As Long = RunUnmanaged(iptModelAddress, dgpDataInterface, strMessage)
00007FF960E35396  lea         r8,[rbp+80h]  
00007FF960E3539D  mov         rdx,qword ptr [rbp+398h]  
00007FF960E353A4  mov         rcx,qword ptr [rbp+70h]  
00007FF960E353A8  call        00007FF960D07938  
00007FF960E353AD  mov         qword ptr [rbp+238h],rax  
00007FF960E353B4  mov         rax,qword ptr [rbp+238h]  
00007FF960E353BB  mov         qword ptr [rbp+88h],rax  
                If (lngStatus <> 0) Then
00007FF960E353C2  xor         eax,eax  
00007FF960E353C4  cmp         qword ptr [rbp+88h],0  

Thanks for any additional help or insights.

Cheers,
Randy MacDonald

[IanH]

Is this vb.net (managed CLR code) calling a "native" Fortan DLL?

[Steve_Lionel]

Make sure that in your VB project you set "Enable unmanaged code debugging" in its Debugging property page.

[Randy_M_]

Hi, IanH,

Yes, sort of...  The vb code calls an Assembler routine that in turn passes control to a routine in a Fortran DLL.  The Assembler routine is held in a dedicated DLL and is declared in the

Hi, Steve,

Yes, I guess that's a fairly common omission.  I do have the checkbox "Enable native code debugging" set in the debug tab of the VB project properties.  I also have "Load dll exports (Native only)" checked under Tools/Options/Debugging/General.  Nearby I found "Use Native Compatibility Mode".  I don't know what this is, but it was unchecked.  I checked it and re-ran my tests and still can't find the breakpoints in the Assembly or Fortran routines.  All fields under "Tools/Options/Intel Compilers and Tools/Debugger" are blank.  The first three of these seem to relate to remote debugging, so I expect are irrelevant.  I'm not sure if the same is true for the last field "solib-search-path directories", but it is also blank.

By the way, I have now searched for and deleted all existing RunUnmanaged.dll and RunUnmanaged.pdb files except the pair that I am intending to reference.  This leads me to suspect I have something wrong in the way I am generating the .pdb files.  Is there some way (or tool) by which these files can be inspected for validity?

Thanks very much for all your ongoing help.

Cheers,
Randy

[Randy_M_]

Hello, all,

Sorry for the long delay in updating this thread.  I had been struggling to find a solution to this problem for some time without success, when I remembered Jim's comment in another thread (https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/745746).  In that case, as well as this, the solutions/projects involved were originally VS2005, now imported into VS2015.

His comment was "...Moving solutions and projects amongst differing versions of VS is often problematic. It is much cleaner to recreate the solution and projects when experiencing such problems."  I performed an initial test by creating a very simple VB main and recreating the Assembler project and one small Fortran project directly within VS2015.  In this case there was no problem setting breakpoints or using the other features of the debugger.

Consequently, I am in the middle of the rather long and tedious process of recreating all of the many solutions and projects that comprise the software package involved.  On completion of this, I hope to discover that my problems using the debugger within the Fortran DLLs will have disappeared.  I will report back at that time.

Again, thanks for your interest and input.

Best regards,
Randy MacDonald 

[Randy_M_ · Accepted solution]

It has taken a while to get this conversion completed, but I can now report that the "No symbols have been loaded...." problem did disappear after re-creation of the associated projects and solutions.

The details of the underlying cause remain unknown, however Jim's comment from the thread mentioned above appears to provide the appropriate solution/work-around.

Thanks to you all for your suggestions.

Best regards,
Randy MacDonald