cannot debug into native c++ dll.

[=?Utf-8?B?RmFiaWFu?=]

Hi,

I have a pretty complicated program which consists of the following basic
modules:

1. a C# application
2. a C++/CLI application which is controlled by the C# app via IPC remoting
3. lots of native code which is wrapped by the managed C++/CLI code

A remark to this complicated structure: We are controlling hardware via
C/C++ driver interfaces. The C# app is the main user interface. We have seen
that the CLR's threading + memory management is not suitable for time
critical hardware interfaces. So we separated the hardware stuff from the
main process.

I start the C# UI in debug mode from within Visual Studio 2008. The UI
process then starts the C++/CLI and native code process and establishes the
interop connection. I usually just attach the debugger to the C++/CLI process
and can debug into the native code without any problem.

Now recently I had to create an extra VS solution only containing C++ dlls.
(I am using these dlls for 2 different projects). It consists of native code
windows dlls, exporting the classes and functions via dllexport. I have built
the dlls in debug mode and I have copied both dll and pdb into the ececution
directory of my original main app.

But: I cannot debug into these dlls although the debug information should be
there. The debugger just steps over a routine call instead of stepping into...

Do you have any ideas?

Thanks in advance for your help,

Fabian

[SvenC]

Hi Fabian,

I have a pretty complicated program which consists of the following
basic modules:

1. a C# application
2. a C++/CLI application which is controlled by the C# app via IPC
remoting
3. lots of native code which is wrapped by the managed C++/CLI code

...

But: I cannot debug into these dlls although the debug information
should be there. The debugger just steps over a routine call instead
of stepping into...

Do you have any ideas?

Make sure that under debugging options you select as debugger type
"mixed". By default this might be "auto" or "managed only" which
excludes native code.

--
SvenC

[=?Utf-8?B?RmFiaWFu?=]

Hi Sven,

...
3. lots of native code which is wrapped by the managed C++/CLI code

...

But: I cannot debug into these dlls although the debug information
should be there. The debugger just steps over a routine call instead
of stepping into...

Make sure that under debugging options you select as debugger type
"mixed". By default this might be "auto" or "managed only" which
excludes native code.

In Visual Studio 2008's debugging options I just found a similar option
under "Just-In-Time". Both "Managed" and "Native" were already selected.
The weird thing is that I can debug into the native C++ dll projects in the
main project's solution. They are also not compiled with /CLR. So the only
difference I see is that the new dlls do not belong to the main Solution
file.

regards,

Fabian

[SvenC]

Hi Fabian,

>>But: I cannot debug into these dlls although the debug information
should be there. The debugger just steps over a routine call instead
of stepping into...

Make sure that under debugging options you select as debugger type
"mixed". By default this might be "auto" or "managed only" which
excludes native code.

In Visual Studio 2008's debugging options I just found a similar
option under "Just-In-Time". Both "Managed" and "Native" were already
selected. The weird thing is that I can debug into the native C++ dll
projects in the main project's solution. They are also not compiled
with /CLR. So the only difference I see is that the new dlls do not
belong to the main Solution file.

Are those dlls compiled as debug versions? I think it is not sufficient to
just create pdb files for the release version of those dlls to debug them.
They must be debug builds.
Also make sure that if you have both debug and release dlls of your
projects available that your debugging session uses the debug dlls.

What type of solution do you use for debugging? A C++/win32 app,
a C# console or win forms or something else? Or do you attacht the
debugger to a running process?

--
SvenC

[=?Utf-8?B?RmFiaWFu?=]

Hi Sven,

Are those dlls compiled as debug versions? I think it is not sufficient to
just create pdb files for the release version of those dlls to debug them.
They must be debug builds.

Everything is built as "debug".

Also make sure that if you have both debug and release dlls of your
projects available that your debugging session uses the debug dlls.

I have no release dlls in this case.

What type of solution do you use for debugging? A C++/win32 app,
a C# console or win forms or something else? Or do you attacht the
debugger to a running process?

The startup project is a C# Windows.Forms app. The second process containing
containing / accessing native C++ dlls is a C++/CLI Windows.Forms app.
To debug both processes I start the C# Windows app which then starts the
C++/CLI exe. When everything has started up I attach the debugger to the to
the C++/CLI process so it is attached to both the C# and the C++/CLI app.

I saw sth. else: When I have a look at the Modules window
(Debug->Windows->Modules) I don't see any of the external dlls. But they are
used.

Thx,

Fabian

[SvenC]

Hi Fabian,

The startup project is a C# Windows.Forms app. The second process
containing containing / accessing native C++ dlls is a C++/CLI
Windows.Forms app.
To debug both processes I start the C# Windows app which then starts
the C++/CLI exe. When everything has started up I attach the debugger
to the to the C++/CLI process so it is attached to both the C# and
the C++/CLI app.

When you attached, did you recognize the field "Attach to:" right above the
list of processes with a "Select..." button on the right?
Click select and change from "Automatic" to "these code types" and
activate managed and native.

--
SvenC

[=?Utf-8?B?RmFiaWFu?=]

Hi Sven,

When you attached, did you recognize the field "Attach to:" right above the
list of processes with a "Select..." button on the right?
Click select and change from "Automatic" to "these code types" and
activate managed and native.

That did the job. Thanks a lot!

regards

Fabian