Debugger Issue - Symbols not Loaded

[Andre_P_]

Hi - I am having a problem when debugging.  I searched this forum, but have not been able to find ta fix.

I have a large .dll project.  I call the .dll file from Excel.  I have Visual Studio 2010.  In Project->Properites->Debugging, I have the path to the excel.exe file and use Excel as the exicutable to debug.

Everything worked well a few months ago.  I had computer refresh and now all of my breakpoints are ignored when debugging.  The breakpoints have an exclimation point and have the message that "no symbols have been loaded for this document"

I am using Fotran Studio XE SP1 Update 3 with Visual Studio 2010.

Any ideas?

Andre

[Steven_L_Intel1]

Make sure that the path to the DLL you are loading in Excel is exactly the one you built in a Debug configuration.

[Andre_P_]

Thanks for the reply Dr Fortran.

I checked the path to the .dll as well as cleaned and re-built the .dll.  The breakpoints still do not work.

I also get the error message when I try to debug

Any other ideas?

[Andre_P_]

Also - I re-installed Fortran Studio XE 2013 and noticed that there was an error message that the Debugger Extension could not be installed because it required Visual Studio 2012 (I use the 2010 shell).

Could that cause the breakpoints to be skipped?

[FortranFan]

Andre P. wrote:

Thanks for the reply Dr Fortran.

I checked the path to the .dll as well as cleaned and re-built the .dll.  The breakpoints still do not work.

I also get the error message when I try to debug

false

Any other ideas?

You can ignore this message about EXCEL.EXE and similar messages about other components that are "external" to your code and which may be involved in your computations - the above simply says you'll not be able to debug EXCEL.EXE code, no big deal.  But you can click on the Yes button and proceed to your code.  I personally prefer to check the "Don't show this dialog again" and not have to bother with it again.

[Andre_P_]

Thanks FortranFan - that helps, I press the Yes button, but it still skips all of my breakpoints.

[IanH]

How did you "check the path to the .dll", in response to the suggestion in #2?  With these symptoms I would be reviewing the list of DLL's loaded into the Excel process when Excel is being debugged using Debug > Windows > Modules (stop Excel using Debug > Break All at some point when you know that it has your DLL loaded).  I would also examine the symbol status and symbol file fields within the resulting window to make sure that they match the symbol file that is being generated by my build process for the DLL.  I would check these things twice.

The warning about the debugger extension is for debugging support for the coprocessor card that Intel offers, if memory serves me correctly.  If you don't have or develop for such a card then the warning is not relevant to you.

[DavidWhite]

My projects similarly are DLL's run from Excel.

I load the DLL's from Excel without any specified folder location, so the DLL location needs to be added to the PATH.

When I need to debug the DLL, I build the debug version in VS as usual.  Then I copy the debug version of the DLL to the location that Excel expects it.

Then running from VS in debug mode works, and the breakpoints are hit.

As several posters have mentioned, you need to make sure that the debug version of the DLL is the one being used by Excel.  The trap is, that if I rebuild the DLL and forget to copy it to the location where Excel loads it from, then the images don't match, and the breakpoints won't be found.

In addition, when copying the DLL across, make sure that Excel does not already have the DLL loaded (best to close Excel first)

Regards,

David

[FortranFan]

David White wrote:

..  

The trap is, that if I rebuild the DLL and forget to copy it to the location where Excel loads it from, then the images don't match, and the breakpoints won't be found.

...

For a long time now, since I first started using Digital Fortran along with Visual Studio 6, I've had a post-build event setting in my Visual Studio DLL projects to copy the file to the desired location.  This has served me well, especially during debugging of my Excel solutions that make use of such DLLs.  Something worth a consideration if forgetting to copy the DLL is getting to be annoying.

In Visual Studio 200X versions, you'll find this setting under Properties -> Build Events -> Post-build Events: you can add the copy statement under Command Line; I prefer to add an description too which gets displayed on the Output window serving as a reminder. 

[Andre_P_]

Hi Ian - Thanks for the reply, comments in-line

IanH wrote:

How did you "check the path to the .dll", in response to the suggestion in #2?

I deleted the .dll file and tried to run excel, there was an error that the .dll file could not be found.  Then I rebuilt the project.

IanH wrote:

With these symptoms I would be reviewing the list of DLL's loaded into the Excel process when Excel is being debugged using Debug > Windows > Modules (stop Excel using Debug > Break All at some point when you know that it has your DLL loaded).  I would also examine the symbol status and symbol file fields within the resulting window to make sure that they match the symbol file that is being generated by my build process for the DLL.  I would check these things twice.

OK, Using Debug > Windows > Modules , I found the .dll I am trying to debug.  The symbol file shows the corect path.  There is a small exclimation point on the icon and an error message that states: " The module did not load from the default load address"

[Andre_P_]

I copied all of the source files in to a new project and built a new .dll.  Everything works fine now.

Thanks to everyone for the help.

Andre