Breakpoints Ignored

[Jacqueline_N_]

I am having a problem when I try to test my fortran dll within the Visual Studio 2013 debugger.  My exe calls the dll, and the dll executes, but all of my breakpoints are ignored. So it is executing the code but I cannot debug the fortran code.  

My development environment has Visual Studio 2013 and Intel Parallel Studio XE 2015 installed.

The solution contains two projects.  Project 1 is a VC# application.  Project 2 is a Fortran dll.  I have tried identifying the startup Project as single startup and multiple startup (Project 1 action=start; Project 2 action=none) yet none of the changes have any effect on the recognition of the breakpoints within the dll.  I have tried placing the .pdb and .dll in the directory of the .exe; have tried placing the .pdb and .dll files within the project.  None of these approaches have worked.

I welcome your assistance.

thank you

[Steven_L_Intel1 · Accepted solution]

Make sure that you set the option "Enable unmanaged debugging" in the C# project.

[Jacqueline_N_]

Thank you Steve!

Within the C# projects properties I found:

Debug->Enable Debuggers->

I activated the checkbox for "Enable native code debugging"; "Enable SQL Server debugging", and "Enable the Visual studio hosting process" were already checked.

As an informational point, my MVSP 2013 Version is 12.0.21005.1 REL with MS .NET Framework Version 4.5.50938

[Steven_L_Intel1]

The other thing I know that can cause this problem is if the DLL that the C# project loads is not the one that was built in the project.

[jimdempseyatthecove]

Try inserting a call to some function in the dll that you know works, and make that call such as to load the dll. (I think there is an option to list the dll being loaded in the console window)

Then place the break point on the call of interest. When you reach the break point, open the disassembly window and use the debugger step into and see where you end up. You may have to step into a few times to reach the dll. This can verify if the correct dll is being called. Note, if you have multiple versions of your dll, you may be mislead into thinking you called the right one. Insert some innocuous statement in the front of the routine being called that you know is not in the release code such as WRITE(*,*)"todays date here"

Jim Dempsey