VC Debugger, Debigging non-debug process and debug DLL

Debigging non-debug process and debug DLL

Author	Message
Steven Schulz #1 / 4	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

Doug Boon #2 / 4	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

Steven Schulz #3 / 4	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

Bob Kou #4 / 4	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

Page 1 of 1

[ 4 post ]