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 remote debugging 2015 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 remote debugging 2015 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)
