Remote debugging with VC2008

[Granta Guy]

Hello,

I have a mixed (native and .Net) project, and I'm getting an error that I
can't reproduce on my production machine.

I've spent most of the day trying to figure out remote debugging. I've build
my release build with symbols, so I'm generating a .pdb, I've managed to run
msvsmon on the remote machine, can connect, start up my remote application,
but I cannot set any breakpoints. If I force an error, I can get a successful
break into MFC code, but not my own - and the call stack won't show my code
either.

I've set the debugging symbols up to point to the remote machine (as a
shared folder), and VS reports that it has loaded them successfully.

How can I get a useful call stack, and how can I load breakpoints?

[Charles Wang[MSFT]]

Hi,
I understand that your remote debugging failed due to unable to catch the
breakpoint.
If I have misunderstood, please let me know.

I performed a test at my side, however unfortunately I could not reproduce
your issue. I recommend that you check the following:
1. If your breakpoint could not be targeted, there should be a warning when
your mouse moves to the breakpoint. What is the message?

2. Check if the symbols are loaded. In debugging process, click Debug,
select Windows->Modules to see if the required symbols are loaded. If any
symbol is not loaded, please manually load it.

3. Check if you select the debugging code type as "Managed, Native". When
you are in debugging process, click Debug menu, select Attach..., click
Select... button for "Attach to" and select "Managed" and "Native", and
then select your process;

4. In Visual Studio, click Tools->Options, select Debugging->General, and
cancel the selection of "Enable Just My Code (Managed only)". If you could
not ensure that your source file totally matches your released executable,
please also cancel the selection of "Require source files to exactly match
the original version".

5. Permission checking. Please refer to this article to see if your
debugging user account satisfies the requirements:
Verify the Permission Settings for Remote Debugging
http://msdn2.microsoft.com/en-us/library/bb521312.aspx

Hope this helps. Please feel free to let me know if you have any other
questions or concerns. Have a nice day!

Best regards,
Charles Wang
Microsoft Online Community Support
=====================================================
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from this issue.
======================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
======================================================

[Granta Guy]

My problem was that I wanted to debug MFC-based code, so I just picked
native, rather than native and managed. That seems to have been the issue...
so thanks, remote debugging working, awkward bug fixed!

But i have a subsequent question. Most of my MFC codebase has come from VC6.
Now that it is in the managed world, I noticed a lot of managed to native
transitions (and vice-versa) in the call stack. I'm concerned that these
might be impacting performance. What is the recommended approach? Should I
mark up the majority of my code as native?

[Charles Wang[MSFT]]

Hi,
Thanks for your response.

For remote debugging, I appreciate your understanding that since your
project is a mixed project, it is required to specify native and managed as
the debugging code type. If your project is a pure MFC project, you can
just select native as the debugging code type.

For your subsequent question, if there are many managed-native transitions
in the call stack, the performance may have a little impact since there are
always additional data marshalling. However VC++ 2005 C++ Interop mechanism
ensures that it can win better performance than explicit PInvoke. You may
refer to:
Using C++ Interop (Implicit PInvoke)
http://msdn2.microsoft.com/en-us/library/2x8kf7zx(VS.80).aspx

For mixed using managed code and native code in a project, I recommend that
you first separate your pure managed code files and pure native code files
with different compiling option. For example, for a pure native code file,
you can right click the file, click Properties, select C/C++ -> General,
select "Compile with Common Lanage Runtime support" as "No Common Language
Runtime support".

Additionally you can even use "#pragma managed(push, off)" to compile your
functions as unmanaged for those files which are compiled with /clr. For
example:
// pragma_directives_managed_unmanaged.cpp
// compile with: /clr
#include <stdio.h>

// func1 is managed
void func1() {
System::Console::WriteLine("In managed function.");
}

// #pragma unmanaged
// push managed state on to stack and set unmanaged state
#pragma managed(push, off)

// func2 is unmanaged
void func2() {
printf("In unmanaged function.\n");
}

// #pragma managed
#pragma managed(pop)

// main is managed
int main() {
func1();
func2();
}

You may also want the following references:
Performance Considerations for Interop (C++)
http://msdn2.microsoft.com/en-us/library/ky8kkddw(VS.80).aspx
managed, unmanaged
http://msdn2.microsoft.com/en-us/library/0adb9zxe(VS.80).aspx

Performance of pure native C++ class in a managed C++/CLI DLL comp
http://groups.google.com/group/microsoft.public.dotnet.languages.vc/browse_t
hread/thread/d0ecbf3b232a3036/562e9c4575a71f22?hl=en&lnk=st&q=Performance+of
+pure+native+C%2B%2B+class+in+a+managed+C%2B%2B%2FCLI+DLL+#562e9c4575a71f22

Hope this helps. If you have any other questions or concerns, please feel
free to let me know. Have a nice day!


Best regards,
Charles Wang
Microsoft Online Community Support

======================================================
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from this issue.
======================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
======================================================