mfc >> can't bebug a dll

by msnews.microsoft.com » Thu, 20 Jan 2005 11:32:07 GMT

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




mfc >> can't bebug a dll

by Joseph M. Newcomer » Thu, 20 Jan 2005 12:38:16 GMT


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

On Thu, 20 Jan 2005 11:32:07 +0800, "msnews.microsoft.com" < XXXX@XXXXX.COM >



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



mfc >> can't bebug a dll

by PanTao » Thu, 20 Jan 2005 14:44:05 GMT


"Joseph M. Newcomer" < XXXX@XXXXX.COM >
??????: XXXX@XXXXX.COM ...

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






can't bebug a dll

by Scott McPhillips [MVP] » Thu, 20 Jan 2005 20:54:57 GMT




When you mix release and debug versions of MFC it can work only if the
parameters passed between exe and DLL are simple types, used simply.
But if you pass any objects that reallocate their own heap memory, such
as CString and std::vector, it fails because the exe and DLL are using
different heap managers. Memory acquired in the exe cannot be deleted
in the DLL, and vv. If your exe/DLL interface requires such flexibility
then both sides of the interface must use the exact same DLL version of
the MFC library: all debug or all release.

--
Scott McPhillips [VC++ MVP]



can't bebug a dll

by Joseph M. Newcomer » Fri, 21 Jan 2005 06:49:07 GMT

erhaps 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" < XXXX@XXXXX.COM >
wrote:


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


can't bebug a dll

by PanTao » Fri, 21 Jan 2005 15:07:49 GMT


"Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp>
??????:uTApB$u$ XXXX@XXXXX.COM ...


I see ~ Many thanks~ I will avoid mixing these two MFC version.
PanTao




can't bebug a dll

by PanTao » Fri, 21 Jan 2005 15:34:23 GMT

any thanks~ I have found that problem.
The problem is that the exe is a just startup program , it seems that it
execute another exe
program and quit itself. The VC debug tool icon start soon becomes enable
after begin deduging.
I notice that but don't think out why it is so. And the debugging window
shows that the program has
exit, but I failed to find out it before.

Now I use the second program as my debuging command, it is ok now. It seems
the dll debug
function is also ok in VS7.

Now I adjust the project release setting, enable generating debug
information, and disable optimazion,
it works ok now.
For debug version, I undefine the _DEBUG , but It report can't find some
definition such as
badCast::badCast(). There is something more I need to adjust, but it is not
important now.

cheers and regards,
PanTao




"Joseph M. Newcomer" < XXXX@XXXXX.COM >
??????: XXXX@XXXXX.COM ...




Similar Threads

1. Can't debug DLL's with "Multi-threaded Debug DLL" under VS 2003

Hi,

For some strange reason debugging a DLL only works for me when I
compile with Single-Threaded or Multi-Threaded, not with
Multi-Threaded DLL.

I have done the following in Visual Studio 2003:

I created a Win 32 DLL project with the project wizard (console
project with application setting "DLL" and "export symbols") and a Win
32 console project (console project with application setting "console
application").

The wizard will generate one mini function (called fnsomething) in the
DLL project. I will call just that from the console main project.

I make the console project dependant of the DLL project so the export
library of the DLL project gets used automatically.

I set the compile options for both projects to "Multi-Threaded Debug",
compile the DLL project and copy the DLL to the executable directory
of the console project.

Single stepping through the DLL function works fine.

But when I change both projects to "Multi-Threaded Debug DLL",
single-stepping doesn't work anymore (sure I copied the DLL again
after recompiling the DLL project). At program start VS doesn't say
"debug symbols" loaded anymore for the loaded DLL, now it says only
"exports loaded", which means it can't find the symbols anymore. But
the .pdb file is still there.

Has anyone a explanation for this?

Regards,
    Gunter

2. Can't debug DLL's with "Multi-threaded Debug DLL" under VS C++ 2003 - Visual Studio

3. C# program can't find namespace of classes in C++ dll

4. Yet Another: Can't call C++ dll functions from C#

5. Can't pass simple array to a C++ DLL

I am having some problems with passing an array to a C++ dll.  I have tried 
2 techniques, and neither work.

Here is my DLL:

__declspec(dllexport) int Test(short* pArray)
 {
 short First;
 short Second;
 short Third;
 First = pArray[0];
 Second = pArray[1];
 Third = pArray[2];

 return 0;
 }

Very simple, get a pointer and store the first 3 int16's pointed to by the 
pointer.

Here is my definition in VB.Net:

    <DllImport(MYDLLSHORT, _
    CallingConvention:=CallingConvention.Cdecl)> _
    Friend Function Test(ByRef MyArrayPointer As IntPtr) As Integer
    End Function

Here is my test code:

Dim Test1(100) As Short

        Test1(0) = 3
        Test1(1) = 2
        Test1(2) = 1

        ' pin variable and create GC handle instance
        Dim gh As GCHandle = GCHandle.Alloc(Test1, GCHandleType.Pinned)
        ' get address of variable
        Dim AddrOfTest1 As IntPtr = gh.AddrOfPinnedObject()

        Test(Test1)

When I run the code and break inside the Test function, I find that pArray 
does not point to the array.  The variables First, Second, and Third are 
loaded with the first 3 int16's but the array is not there.  If it worked 
correctly, First would be 3, Second would be 2, and Third would be 1.

So I changed to this VB code:

        Dim AddrOfTest1 As IntPtr = Marshal.AllocHGlobal(200)
        Marshal.Copy(Test1, 0, AddrOfTest1, 100)

The same thing happens.  The C code loads First, Second, and Third with the 
first 3 16 bit words pointed to by the pointer, but it is not the array 
data.

The array data should be 3, 2, 1, followed by 98 words of 0.

Can you tell me why the pointers returned by AllocHGlobal and 
AddrOfPinnedObject are not pointing to my array?

Thank you for your help.

Clark




6. Can't access COBOL DLL from C# program

7. Can't reference dll

I get an error when trying to add a reference to a DLL program from a Realia 
COBOL program that is 32 bit.  The error message says "Please make sure the 
file is accessible and that it is a valid assembly or COM component.  I can 
access this file using C++ but not C#.  My COBOL DLL program passes data by 
reference.  My coding is shown below:

[DllImport("progcmp1.dll", CharSet=CharSet.Auto, EntryPoint="TRANPROG", 
CallingConvention=CallingConvention.StdCall)]
public static extern void TRANPROG(string parms);

private void OnSubmit(object sender, EventArgs e)
{
   StringBuilder parms = new StringBuilder("00000000", 87);
  TRANPROG(parms.ToString());
}

8. Can't find dll - CSharp/C#