Unable to debug dll source code with symbol server

I’ve blogged in the past about using a Symbol server and I recommend to all people to use symbol servers whenever possible, to helping people troubleshooting problem on dependencies. Basically with a symbol server you can reference a dll in your project, but you can debug original source code as if you have the original project linked instead of having the dll.

Sometimes this process just don’t work. Recently I’have a customer that had problem with this scenario, and the real strange stuff is: I’m able to step in dll source code without problem from any machine, but noone of the customer’s developers are able to make it work. After I’ve sent them detailed instruction it worked, and we were able to track down the problem.

Visual Studio has a nice option to cache symbols in local directory to avoid downloading each time from the server. Here are my usual settings.

Visual Studio options to use local folder as a symbol cache

Figure 1: Visual Studio symbols settings

Developers in customer sites decided to use a subfolder of %TEMP% directory and this was the cause. As soon as they moved symbol cache to something like c:\symbols everything starts working. The underling cause is probably due to long paths.

If you have problem using symbol server, try using a really short path for your Symbols Local Cache directory.

In this specific situation we are using free symbols server in conjunction with MyGet nuget package feeds. In my machine here is the location for a source file during debugging.

Z:\Symbols\src\pdbsrc\MyGet\alkampfer\11111111-1111-1111-1111-111111111111\BIGEND\GianMariaRicci\Jarvis.Framework.Kernel\2C5AB5CBD1C74688974B2DDB55F51EDA1\Jarvis.Framework.Kernel\ProjectionEngine\ConcurrentProjectionEngine.cs

Usual %TEMP% variable is something like c:\users\gianmaria.ricci\appdata\local\temp (this is my system and it is long 44 characters), so it is not a good idea to use it for symbol source cache.

Since it is really easy to have really long path for your source when you use a symbol server, it is always a good idea using a short path for symbols cache directory, something like x:\SymSrc is probably the best solution.

If this does not solves your problem, another suggestion is using Fiddler to inspect the traffic between your Visual Studio and the Source Server to understand what is happening.

Gian Maria.

Troubleshoot remote debugging of Managed Code

Setting up Remote Debugging is usually a simple task, you can read the Set Up Remote Debugging guide on MSDN and you are ready to go, but sometimes it does not work and you are not able to connect to the remote process; in this post I want to give you some suggestions to troubleshoot the most common problem that you can encounter.

First: you need to be aware that Remote Debugging Managed Code is only available when you use the authenticated mode, if you run the remote debugger without authentication you can debug only Native Code, but the main problem is that usually the host and remote machine are not in the same Domain. To bypass this situation you need to create what is called “Shadow Account”, this means that you need to have in both machines the same user with the same password.

How to setup authentication if you do not have a domain

Figure 1: How to setup authentication if you do not have a domain

As you can see in Figure 1, I logged in the remote machine with the same user I’m logged in the host machine (the machine where I’m running Visual Studio), then I launch the remote debugger and configure to use Windows Authentication, you should also verify that current user has the Debug permission. As you can see from the description of the remote debugger is now operative and tells me: Msvsmon started a new server named gianmaria.ricci@WIN-FEVDGL2V37P. The part username@machinename is the name of the server.

Second: You need to be sure that the appropriate firewall ports are open in both machines, you can verify ports used if you launch the configuration of Remote Debugger, that tells you to open DCOM port (TCP 135) and IPSEC (UDP 4500 / UDP 500) if you run under IPSEC. If you still have problem to connect, you can try to disable the firewall on both machines, try to connect again, ad if it still does not work you probably have some authentication problem, so refer to first step and verify that you are logged in the remote machine with the same user you are using in the host machine. If you are able to connect with firewall disabled, turn on one debugger at a time (host and remote) and verify which is the one that is blocking the connection.

Third: please be sure that in the Attach to Process dialog you are using Default Transport and the qualifier in the form username@machinename, because this is required to do an authenticated connection. Finally, if you are able to see the list of remote processes and attach to them but your breakpoints in code are not hit you should check the type of code you are debugging, pressing Select Button in the Attach To Windows and choose the right type of code that is used by the remote process, as seen in Figure 2.

Choose the right type of Code Type that is running in the remote process

Figure 2: Choose the right type of Code Type that is running in the remote process

Please verify also you have opened in Visual Studio the same code that is running in the remote machine and that Pdb files are correct and also that you are compiling in Debug Mode and generation of Pdb files is enabled in the Visual Studio. (You can even debug a program in release mode, but you need to be sure that you are generating Pdb files in release mode).

If everything went good and you are able to attach to a remote process, you can also configure Visual Studio to automatically run the program in the remote computer as shown in Figure 3. In this scenario usually you can setup a shared folder in the remote machine and configure a post build action that automatically copies the result of the build in the remote machine through the shared folder. The important fact is that the Start External Program should point to a valid executable in the remote machine and the user should be logged in the remote machine with Remote Debugger opened and working.

Configure Visual Studio to start and debug a process in the remote machine

Figure 3: Configure Visual Studio to start and debug a process in the remote machine

Everything should work, when you press F5 the program should start in the remote machine and you have the debugger attached to it.

Gian Maria.