Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: How to debug a dll?

1 view
Skip to first unread message

Igor Tandetnik

unread,
Nov 18, 2009, 9:12:41 AM11/18/09
to
chrisben wrote:
> My exe program is in C#, though my question will apply to C++ also. I have
> no problem to step into the dll codes as long as I called the method from my
> application in debug mode. However, as I set the breakpoints in an internal
> timer thread of the dll, compile it in debug mode, copy it over to my exe
> project running directory, that breakpoints never get hit.

This suggests strongly that the code in fact never gets run. Debug it to figure out why.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925

Victor Bazarov

unread,
Nov 18, 2009, 9:14:35 AM11/18/09
to
chrisben wrote:
> My exe program is in C#, though my question will apply to C++ also. I have
> no problem to step into the dll codes as long as I called the method from my
> application in debug mode. However, as I set the breakpoints in an internal
> timer thread of the dll, compile it in debug mode, copy it over to my exe
> project running directory, that breakpoints never get hit.
> Any suggestion on this?

Make sure that the dll is actually loaded - look in the 'Modules' window
for your DLL and if it's loaded, compare the path with the one you think
you use. Also, consider copying the PDB file along.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

chrisben

unread,
Nov 18, 2009, 10:06:03 AM11/18/09
to
I put cout line after the breakpoint, I can see cout print out, but the
program went through breakpoint without stop. So it got run.
thanks

"Igor Tandetnik" wrote:

> .
>

chrisben

unread,
Nov 18, 2009, 10:21:02 AM11/18/09
to
Here is the process

exe is C# compiled at VS 2008. dll is unnamged c++ compiled at VS2003.

after compiling the dll in debug mode, I copied
the corresponding dll, exp, lib, and pdb to the debug folder of exe project.
exe project has debug unnamged codes checked.

When exe start, the codes can step into the dll codes from C# exe project
without problems, ONLY IF I set the starting breakpoint in C#. Howwever,
though I set breakpoint in C++ dll in the same method, my program will not
stop there (regardless different thread or not, just found it).

One thing I just found, if I set breakpoint at C# codes, I can actually step
into the C++ dll codes. If I set breakpoint in the same method of my C++
codes, program will not stop.

I think maybe I did somthing wrong on the way of set up break point. Where
can I see teh Module window? I did not find it in my windows options in
VS2008.

Thanks

Chris

"Victor Bazarov" wrote:

> .
>

chrisben

unread,
Nov 18, 2009, 10:45:01 AM11/18/09
to

correction. I made one mistake. Instead, if I set breakpoint in that call
method, regardless in c# or in c++ dll, it works. Breakpoint does not work
ONLY if I put it in that timer thread codes. Though I am sure it is called.

Thanks

Victor Bazarov

unread,
Nov 18, 2009, 11:32:05 AM11/18/09
to
chrisben wrote:
> My exe program is in C#, though my question will apply to C++ also. I have
> no problem to step into the dll codes as long as I called the method from my
> application in debug mode. However, as I set the breakpoints in an internal
> timer thread of the dll, compile it in debug mode, copy it over to my exe
> project running directory, that breakpoints never get hit.
> Any suggestion on this?

Make sure your debugger is set to "mixed" mode, not "auto".

chrisben

unread,
Nov 18, 2009, 12:45:02 PM11/18/09
to
Thanks Victor. It did not work even if I set as mixed in dll project.
However, I figure out a way to work, though quite weird.

Currently, the dll project is not part of my exe project solution, as they
are compiled at different studio. If I set the breakpoint in dll project,
copy over the dll never get the break point triggered. However, if I open the
cpp file from the solution of my exe project, even at run time, and then set
breakpoint there, it works. Even though I only open a file, not really a
project, and the dll was compiled when the breakpoint was not set.

It is working but I am wondering why. BTW,where can I see that Modules
window you refer to in the first msg?
Thanks


"Victor Bazarov" wrote:

> .
>

David Wilkinson

unread,
Nov 18, 2009, 1:45:12 PM11/18/09
to
chrisben wrote:
> Thanks Victor. It did not work even if I set as mixed in dll project.
> However, I figure out a way to work, though quite weird.
>
> Currently, the dll project is not part of my exe project solution, as they
> are compiled at different studio. If I set the breakpoint in dll project,
> copy over the dll never get the break point triggered. However, if I open the
> cpp file from the solution of my exe project, even at run time, and then set
> breakpoint there, it works. Even though I only open a file, not really a
> project, and the dll was compiled when the breakpoint was not set.
>
> It is working but I am wondering why. BTW,where can I see that Modules
> window you refer to in the first msg?

I'm not sure I understand that either.

Back in the VC6 (and earlier) days, the only way to debug a DLL was to start the
executable from the DLL project. There was a line in the DLL project settings
which (if memory serves) was called "Executable for debug session". Presumably
the same can be done using the "Command" line in the new IDE. Does this work?

--
David Wilkinson
Visual C++ MVP

chrisben

unread,
Nov 18, 2009, 4:56:06 PM11/18/09
to
i tried start from dll project. did not work. maybe because i have vc9 exe
and vc7 dll. i did not find the option you mentioned in vs 2003, though i can
start different exe from command line option. i did not go deep into it since
it seems working on my exe directly after i load the file where I want to set
breakpoint. i am sure I am doing it in a "standard procedure" :).
thanks

"David Wilkinson" wrote:

> .
>

chrisben

unread,
Nov 18, 2009, 4:59:02 PM11/18/09
to
should say " I am NOT doing it ..."
0 new messages