Debugging a dynamically loaded DLL

Debugging a dynamically loaded DLL

I have an application which loads a DLL dynamically and then calls a subroutine in this DLL, much along the lines of the LOADEXP1 example in the samples. However I am not able to step into the called subroutine in the debugger. The DLL is compiled with full debug and I have copied the dll, pdb and exp files into the same place as the executable.
The only difference from the example that I can see is that the executable and DLL are not in the same workspace and indeed not in the same directoty.

5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Copying the dll around is a Bad Thing. I always modify the default path of the binary in Project/Settings/Link, especially when creating a dll. Typically, my workspaces are set up as:

RootDir (empty project)
  |
  +- ExeProject (.dsp + .f90)
  |
  +- DllProject (.dsp + .f90)
  |
  +- Bin

Both ExeProject and DllProject are set up to produce the binary in "..Bin". I think there should be no debug problems with this or similar setups.

HTH
Jugoslav

Jugoslav
www.xeffort.com

First of all, I want to thank you for the answer you provided to this question as it addressed the basis of a bug which a program of my own enjoyed. I was copying both an exe and a dll to another directory and found the result dysfunctional - to say nothing regarding difficulties using the debug facility.

Secondly, would you please give me an inkling as to why copying dll's is such a bad idea?

Well, you said it yourself -- because in the instance when you forget to copy it, you'll experience weird problems in debugging and behaviour (for example, looking at one code in the debugger but something else is actually executed). Of course, once the final version is established you can copy it around as you wish.

Also, that is in accordance with Jugoslav's Law : "Never have two different instances of the same thing on your computer". (Because you'll inevitably forget which is the right one). Having said that, uh, I fixed a bug on xftfile.f90 on a place different than the "referent" one... gotta go... :-))))).

Jugoslav
www.xeffort.com

Thanks Jugoslav, I was debugging the incorrect copy of the DLL...

Leave a Comment

Please sign in to add a comment. Not a member? Join today