Why are no Symbols loaded when remote debugging?

user_23681 0
Viewed 59014

I want to use remote debugging. The program that I want to debug runs on machine b. Visual Studio runs on machine a.

On machine b I have a folder with the following files:

  • msvcr72.dll
  • msvsmon.exe
  • NatDbgDE.dll
  • NatDbgDEUI.dll
  • NatDbgEE.dll
  • NatDbgEEUI.dll

If you think some files are missing, could you also describe where they are usually located?

In the next step I started the msvsmon.exe and my program on machine b. On machine a, I started Visual Studio 2008 and my solution in which the program was written. Then I choose "Debug - Attach to Process". I chose "Remote Transport (Native Only with no authentication)". I used the correct IP as a qualifier and took the right process (program.exe). After a while the following message occurred in a popup-window:

Unhandled exception at 0x7c812a7b in program.exe: 0xE0434F4D: 0xe0434f4d

I can continue or break; When continuing, the exception occurs again and again and again. So I pressed break and the following message occurred:

No symbols are loaded for any call stack frame. The source code cannot be displayed.

remote-debugging visual-studio-2008
14 Answers

Make sure you copy the .PDB file that is generated with your assembly into the same folder on the remote machine. This will allow the debugger to pickup the debug symbols.

ktrauberman_214610
  1. Add a shared folder on your dev machine that points to the location of the .pdb files
  2. Set up an environment variable called _NT_SYMBOL_PATH on the remote machine that points to the shared folder on your dev machine

The remote debugger will now search your dev machine for symbols. No need to copy them over for every build.

See MS Video here.

Start watching 8-9 minutes in. He demonstrates how to setup the remote debugger to load symbols from a drive share on your development machine.

Good luck!

user_1403020

Remote debugging in .NET will not work if you don't place the .PDB files into the same directory where the debugged code exists.

If VS still can't find source for debugging, the debugged code and the VS project source are not the same version. The solution is rebuilding and redeploying the project.

artur02_139370

0xE0434F4D is an exception from the CLR (i.e., managed code). You need to do remote debugging with authentication and choose to debug managed code. Alternatively, it is possible to extract out the managed exception info using some debugger extensions but it is a bit more hard work.

References:

If broken it is...

1800_INFORMATION_31460

I ran into this issue and the above solutions did not fix it for me. In my case, my VS2010 solution had many projects in it. The project I was trying to remotely debug was not set in my VS2010 solution as the StartUp Project, because my make scripts were not quite right.

I right-clicked on the project within my solution I was trying to debug and selected Set as StartUp Project and then my symbols loaded properly and my breakpoint was hit.

user_73925020

I had the same problem while remote debugging, it got resolved with the following steps on VS 2008:

  1. you copy the local pdb file along with your binaries
  2. Run the same version of msvmon as your application was built for, If your application is built for x86 architecture, you need to run the x86 version of msvmon, even If you are running it on x64 machine. It will give warning when you try to run, but it should run.
user_101385680
Related