Re: can't bebug a dll

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Joseph M. Newcomer (newcomer_at_flounder.com)
Date: 01/20/05 

Date: Thu, 20 Jan 2005 17:49:07 -0500

Perhaps someone can explain why you are not getting breakpoints. I don't use VS.NET except
when it is unavoidable. In VS6 you often have to explain to the debugger that it must
preload the DLLs. I could not find a similar feature in exploring VS7. So all I can do is
point out what may still be a problem in VS7; if it is, it is so incredibly considerate of
the VS7 designer to make the DLL preload ability so blindingly obvious (remember, this is
the guy who had a "vision" that says "screw the users, we don't need a system that is easy
and obvious to use, as long as it fits my idea of what I think a development environment
should be, no matter how impractical and unusable it is to everyone else")

You cannot mix debug and release MFC environments without expecting serious disasters.
Don't do it. Don't even try. It isn't worth the effort. What will happen is that you will
have two different MFC runtimes each believing it has the sole correct image of what is
going on, and this is a sure formula for complete and total disaster.

You will lose a bit of support, but you can create a release version without optimizations
and with debug symbols, and you can debug with it. You won't get ASSERT and VERIFY and
other aids for debugging, but you have to give up something here. The correct solution is
to get the debug version of the application.
                                joe

On Thu, 20 Jan 2005 14:44:05 +0800, "PanTao" <bandianxing@hotmail.com_remove_please>
wrote:

>
>"Joseph M. Newcomer" <newcomer@flounder.com>
>??????:2pcuu05goe1cujo5njk5v3dveelblsrqui@4ax.com...
>> Yes, but why do you care that the exe contains no debug information? Since
>> you are
>> debugging the DLL, this message can obviously be ignored.
>>
>> In VS6 you had to explicitly specify what DLLs you wanted, but I can't
>> find a similar
>> feature in .NET 2003.
>>
>> There are serious problems combining release MFC executables with debug
>> MFC DLLs; you get
>> conflicts since you have two different MFC runtimes conflicting for
>> resources. However,
>> you said the DLL is a simple windows sdk program, which is a set of terms
>> which generally
>> don't fit together (MFC also uses the Windows SDK, for example); what I
>> believe you are
>> saying is that the DLL is not an MFC-based DLL, so there should be no
>> conflict when it is
>> used with an MFC executable, so the issues about the DLL being linked with
>> an MFC debug
>> version don't make sense.
>> joe
>
>I see now.
>Currently I am trying set up the debug envirement. I use a simple example to
>try.
>The exe is a release version and MFC based, and my example is a simple sdk
>dll, but I can't make
> the break point effective. It is strange and annoying. I had tried
>debugging com dll example before
> with VC6, and it was always OK. I don't know what I miss here. Any
>suggestion?
>
>And latter , my real debug target is a MFC based dll, and the dll should
>linked to a lot of library. Now
>I don't have some debug version of those dll, and some of them is also MFC
>based. So since the
>exe is MFC based release verion , and I only need to debug my own dll, I
>think I only need to changed
>those linked dll to release version. Is it so?
>
>many thanks,
>PanTao
>
>> On Thu, 20 Jan 2005 11:32:07 +0800, "msnews.microsoft.com"
>> <_bandianxing_@hotmail.com_>
>> wrote:
>>
>>>hello, all
>>> I am trying to debug a dll. The exe file is a mfc release version
>>>file, and the dll currently is a simple windows sdk program.
>>>My environment is windows XP, vc dotnet 2003, and I have set the exe as
>>>the debug commmand in the project-debug-debugging-command.
>>>While I debug the problem, the exe is executed, and report the the
>>>exe file contain no debug information. but the breakpoint in my dll is not
>>>effective. What may be the problem?
>>>
>>>And also, if the exe is a mfc release version , may I link the dll with
>>>mfc debug version? Is there some conflict?
>>>
>>>many thanks,
>>>PanTao
>>>
>>
>> Joseph M. Newcomer [MVP]
>> email: newcomer@flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Relevant Pages

  • Re: newbie configuration questions
    ... When you say integrate multiple libraries, are you talking about 3rd party ... >> there is an MFC specific group microsoft.public.vc.mfc. ... >> the filename let's you know it's a debug DLL. ...
    (microsoft.public.vc.language)
  • Re: Debug works fine, but not in Release and vice-versa.
    ... At times it is possible that some operations work fine in Debug mode but not in Release mode and vice-versa. ... Release build crashes when creating dialog from DLL ... At the time of the crash, ... user32 were claimed to not be valid) the original MFC call was to ...
    (microsoft.public.vc.mfc)
  • Re: Cant Debug COM Interface
    ... When I start to debug the application the DLL is ... a com client in vb.net which is referencing the interface of the COM Server ... If I use this application as Host application I can debug without ... For debugging I can start the ...
    (microsoft.public.vsnet.debugging)
  • Re: Extension DLL with CDialog
    ... I have created an MFC Extension DLL, ... Compiled it both in release and debug mode.. ... MS closed the bug report ...
    (microsoft.public.vc.mfc)
  • Debug works fine, but not in Release and vice-versa.
    ... At times it is possible that some operations work fine in Debug mode but not in Release mode and vice-versa. ... Release build crashes when creating dialog from DLL ... At the time of the crash, ... user32 were claimed to not be valid) the original MFC call was to ...
    (microsoft.public.vc.mfc)