Please keep the questions about PDB files coming! I wanted to provide the background as to how remote debugging worked so you would understand the limitations and ramifications. Well, I don’t have a real answer other than to say that’s just kind of how it is, especially for native code. Eric asks if that’s a reasonable requirement. With remote debugging, if both machines have the local build binaries in the same drive and directories, life is easy because the symbol loading occurs without you having to worry about the type of development you’re doing. Once you have the _NT_SYMBOL_PATH set on the remote machine, when you start remote debugging, Visual Studio will let you know that it will be downloading public symbols to the remote machine: If you don’t want to do that manually for forty test systems, you can use the PowerShell script I wrote to automate the process. In order to get them you have to set the _NT_SYMBOL_PATH environment variable to point to your symbol server. NET PDB files are loaded on the remote machine, the public build PDB files are loaded there as well. What about the public build PDB files for. For your private builds, you’ll copy the binary and matching PDB file to the remote machine where the loading occurs. With Visual Studio doing the symbol loading for native remote debugging, both local build and public build symbols load where you expect them to load. Here’s a screen shot from the local machine where I was remote debugging to a native C++ application: Run Process Explorer on both machines and in each press CTRL+F to search for handles and DLL strings. Start single stepping with Visual Studio and stop at the entry point of the application.
Put the project in the same drive and directory on both the local and remote machine. Set up remote debugging for a console application using your favorite language. If you want to verify where the PDB files load, here’s how I verified the loading. NET binaries, the PDB files are loaded on the remote machine and for native binaries, the PDB files are loaded on the local machine.įrom Eric’s question, I’m betting he was doing native remote debugging because when he moved the binaries to the same path on both machines, everything worked like expected because it was Visual Studio found the binary on the local machine and in turn, the PDB file as I described in my previous blog entry. The key trick to know about remote debugging is for. However, the one thing I haven’t found discussed in the Remote Debugging documentation is where the PDB files are loaded, which is the crux of Eric’s issue.(For the rest of this article, I’m assuming you’ve read all the remote debugging documentation.) To make everything clear, let me define two terms the remote machine is where MSVSMON.EXE and your application execute and the local machine is where the Visual Studio IDE is running. What approach would you take to remove this restriction for remote debugging?įor the most part, remote debugging works well. But that doesn’t seem like a very reasonable requirement. Just on a hunch, I moved the executable files on the remote machine such the path was the same as where the files were on the build machine, and that fixed the problem. I suspect the information you’ve provided explains a problem I had recently doing remote debugging I copied my private build to another machine, with PDB file right there with it, but when I remote-debugged, VS could not find any of my breakpoints. You’re exactly right, all the information you have provided probably exists somewhere, but not all together. The first question I want to cover is from Eric Hill:
#Visual studio 2012 remote debugger how to#
Please continue to ask any questions you have about PDB files as I am taking it as my personal mission to ensure that everyone developing for Windows knows exactly how to use PDB files!
#Visual studio 2012 remote debugger full#
There was lots of nice feedback, but more importantly great questions! Instead of responding in the blog comments to these questions as I normally do, a couple of the questions were important enough that I wanted to make full blog entries out of them. Thanks for all the comments and emails about my blog entry, PDB Files: What Every Developer Must Know.
0 kommentar(er)
