Debigging non-debug process and debug DLL 
Author Message
 Debigging non-debug process and debug DLL

Hi!

I've asked this question before, but got no replies that helped me solve my
problem, other than "it SHOULD work just fine...".

So, if anyone here can help me, or tell me how to solve this annoying
problem.  I'll try to keep things as simple as possible.

I'm writing a third-party plug-in DLL for an application that already
exists.  I did not write the application myself, and therefore don't have
the source code or debug version for it.  According to the VC++5.0 docs, it
is possible to debug a DLL that gets called by a non-debug application, even
if you don't have the source code for the application. I did write a simple
application that tests the basic functions of the DLL, and the DLL itself
works fine.   I'll use the following names to identify the various
components in my project...

MainApp.exe           The final application.  No debug version. It will use
my DLL.
MyTestApp.exe        My own application I use to test basic functions in my
DLL.
MyDLLDebug.dll       My DLL, the debug version.
MyDLLRelease.dll    My DLL, release version.

Now, both MyDLLDebug.dll as well as MyDLLRelease.dll works fine with
MyTestApp.exe as well as MainApp.exe.  The problem is that when I try to
debug my MyDLLDebug.dll with MainApp.exe, MainApp.exe causes an access
violation as soon as VC starts running it (when I press F5).  When I press
Shift+F5 (execute), MainApp.exe runs fine and runs both MyDLLDebug.dll as
well as MyDLLRelease.dll without problems, depending if I'm in debug or
release build modes.

I have entered MainApp.exe in the "executable for debug session", and added
MyDLLDebug.dll as DLLs to load.

As I said, my problem is that MainApp.exe causes an access violation, and VC
throws me back into the disassembled code for MainApp.exe, which means
nothing to me since I don't have the debug version of it.

Please note that this has nothing to do with Debug Vs Release versions of my
DLL, because when MainApp.exe is run by itself and accesses either
MyDLLDebug.dll or MyDLLRelease.dll, it works fine.  It's only when I try to
run VC in debug mode (F5 Vs Shift+F5).

Anybody have any ideas?

Thanks in advance...

Steven Schulze
Concord,  CA



Sun, 13 Aug 2000 03:00:00 GMT  
 Debigging non-debug process and debug DLL

Build your release version with debug symbols.

We build three versions of our projects, release mode, debug mode and
DRelease, which has debug symbols, the same optimization flags and produces
a PDB file in the linker. (NOT in the compiler!)

Whenever someone has a problem we start by trying to duplicate it with pure
debug code. If that doesn't work, or we're dealing with a mixed environment
where some of it must be release, we drop in the DRelease modules.

The reason for building the PDB in the linker and not in the compiler is
that if the PDB file is built by the compiler then its full path is stored,
while the PDB file generated by the linker just assumes that its in the same
directory as the DLL or EXE. That way we don't have to match all the
directory structures while debugging.


Quote:
>Hi!

>I've asked this question before, but got no replies that helped me solve my
>problem, other than "it SHOULD work just fine...".

>So, if anyone here can help me, or tell me how to solve this annoying
>problem.  I'll try to keep things as simple as possible.

>I'm writing a third-party plug-in DLL for an application that already
>exists.  I did not write the application myself, and therefore don't have
>the source code or debug version for it.  According to the VC++5.0 docs, it
>is possible to debug a DLL that gets called by a non-debug application,
even
>if you don't have the source code for the application. I did write a simple
>application that tests the basic functions of the DLL, and the DLL itself
>works fine.   I'll use the following names to identify the various
>components in my project...

>MainApp.exe           The final application.  No debug version. It will use
>my DLL.
>MyTestApp.exe        My own application I use to test basic functions in my
>DLL.
>MyDLLDebug.dll       My DLL, the debug version.
>MyDLLRelease.dll    My DLL, release version.

>Now, both MyDLLDebug.dll as well as MyDLLRelease.dll works fine with
>MyTestApp.exe as well as MainApp.exe.  The problem is that when I try to
>debug my MyDLLDebug.dll with MainApp.exe, MainApp.exe causes an access
>violation as soon as VC starts running it (when I press F5).  When I press
>Shift+F5 (execute), MainApp.exe runs fine and runs both MyDLLDebug.dll as
>well as MyDLLRelease.dll without problems, depending if I'm in debug or
>release build modes.

>I have entered MainApp.exe in the "executable for debug session", and added
>MyDLLDebug.dll as DLLs to load.

>As I said, my problem is that MainApp.exe causes an access violation, and
VC
>throws me back into the disassembled code for MainApp.exe, which means
>nothing to me since I don't have the debug version of it.

>Please note that this has nothing to do with Debug Vs Release versions of
my
>DLL, because when MainApp.exe is run by itself and accesses either
>MyDLLDebug.dll or MyDLLRelease.dll, it works fine.  It's only when I try to
>run VC in debug mode (F5 Vs Shift+F5).

>Anybody have any ideas?

>Thanks in advance...

>Steven Schulze
>Concord,  CA



Tue, 15 Aug 2000 03:00:00 GMT  
 Debigging non-debug process and debug DLL

Quote:

>Build your release version with debug symbols.

>We build three versions of our projects, release mode, debug mode and
>DRelease, which has debug symbols, the same optimization flags and produces
>a PDB file in the linker. (NOT in the compiler!)

But the problem has nothing to do with Release vs Debug.  Since the
MainApp.exe runs fine with EITHER build, I don't think that's the problem.
For instance, when I'm in either Debug or Release build, and I press
SHIFT+F5 (execute), it runs just fine in both cases.  But when I'm in Debug
mode and press F5 (debug), the MainApp.exe causes an access viotalion (not
even my own DLL, but the non-debug MainApp.exe).  Can you see the
distinction here?

What you are saying is that I should run the Release with debug info
following your description, but all I want to do is simply run the Debug
version, and debug it.

I just tried what you said, and I still have the same problem.

Quote:
>Whenever someone has a problem we start by trying to duplicate it with pure
>debug code. If that doesn't work, or we're dealing with a mixed environment
>where some of it must be release, we drop in the DRelease modules.

I assume you talk about a Debug vs Release build problem, which is not my
case.

Quote:
>The reason for building the PDB in the linker and not in the compiler is
>that if the PDB file is built by the compiler then its full path is stored,
>while the PDB file generated by the linker just assumes that its in the
same
>directory as the DLL or EXE. That way we don't have to match all the
>directory structures while debugging.

This doesn't seem to apply to my problem.  In my case, anyway, the
MainApp.exe looks for DLLs in it's own directory, and since MainApp.exe
causes the access violation, it means that MainApp.exe was run, so I don't
think it's got something to do with not finding certain files.  Am I wrong?

Any other ideas?

Steven Schulze
Concord,  CA

Quote:



>>Hi!

>>I've asked this question before, but got no replies that helped me solve
my
>>problem, other than "it SHOULD work just fine...".

>>So, if anyone here can help me, or tell me how to solve this annoying
>>problem.  I'll try to keep things as simple as possible.

>>I'm writing a third-party plug-in DLL for an application that already
>>exists.  I did not write the application myself, and therefore don't have
>>the source code or debug version for it.  According to the VC++5.0 docs,
it
>>is possible to debug a DLL that gets called by a non-debug application,
>even
>>if you don't have the source code for the application. I did write a
simple
>>application that tests the basic functions of the DLL, and the DLL itself
>>works fine.   I'll use the following names to identify the various
>>components in my project...

>>MainApp.exe           The final application.  No debug version. It will
use
>>my DLL.
>>MyTestApp.exe        My own application I use to test basic functions in
my
>>DLL.
>>MyDLLDebug.dll       My DLL, the debug version.
>>MyDLLRelease.dll    My DLL, release version.

>>Now, both MyDLLDebug.dll as well as MyDLLRelease.dll works fine with
>>MyTestApp.exe as well as MainApp.exe.  The problem is that when I try to
>>debug my MyDLLDebug.dll with MainApp.exe, MainApp.exe causes an access
>>violation as soon as VC starts running it (when I press F5).  When I press
>>Shift+F5 (execute), MainApp.exe runs fine and runs both MyDLLDebug.dll as
>>well as MyDLLRelease.dll without problems, depending if I'm in debug or
>>release build modes.

>>I have entered MainApp.exe in the "executable for debug session", and
added
>>MyDLLDebug.dll as DLLs to load.

>>As I said, my problem is that MainApp.exe causes an access violation, and
>VC
>>throws me back into the disassembled code for MainApp.exe, which means
>>nothing to me since I don't have the debug version of it.

>>Please note that this has nothing to do with Debug Vs Release versions of
>my
>>DLL, because when MainApp.exe is run by itself and accesses either
>>MyDLLDebug.dll or MyDLLRelease.dll, it works fine.  It's only when I try
to
>>run VC in debug mode (F5 Vs Shift+F5).

>>Anybody have any ideas?

>>Thanks in advance...

>>Steven Schulze
>>Concord,  CA



Wed, 16 Aug 2000 03:00:00 GMT  
 Debigging non-debug process and debug DLL

Are you *sure* your app is loading the correct DLL?
Even though you  put a complete path to your app in the "exe to debug"
project setting, the app won't be able to find the DLL in your
xxx\Debug or xxx\Release directories.
Now - it looks like you are trying to start your app, then start
debugging. This may cause problems as, with the "EXE to debug" project
setting set. pressing [F5] will cause another instance of that app to
be loaded. So, just press [F5], and let VC start your app, which will
load your DLL, and you'll stop at your first breakpoint in your DLL
(assuming you have a breakpoint set).
BTW, what happens when you try to run multiple instances of this app
without doing anything with VC?
Bob

On Wed, 25 Feb 1998 22:14:23 -0800, "Steven Schulze"

Quote:

>...
>I'm writing a third-party plug-in DLL for an application that already
>exists.  I did not write the application myself, and therefore don't have
>the source code or debug version for it.  According to the VC++5.0 docs, it
>is possible to debug a DLL that gets called by a non-debug application, even
>if you don't have the source code for the application. ...



Sat, 19 Aug 2000 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Debugging code linked to non-debug versions of DLLs

2. NON-debug DLLs in debug

3. Debugging child process, Startup .EXE for debugging DLL

4. Heap Problems: Both Debug and non-Debug versions of CRT are active

5. mixing DEBUG and NON-DEBUG versions of CRT

6. redirecting a debug string to the debug IDE window in non-MFC app (ala TRACE)

7. redirecting a debug string to the debug IDE window in non-MFC app (ala TRACE)

8. Debug / non-debug compatibility

9. Linking to debug and non-debug CRT libraries.

10. Attaching to a Process for DLL debug

11. Debug DLLs via Attach Process - can't always access

12. How can I debug DLL code for any (=unknown) processes

 

 
Powered by phpBB® Forum Software