I'm storing some artifacts, and I have .lib files and .dll files in separate subdirectories. Are .pdb files searched for based on the startup directory (like .dll files) or are they searched for based on the link directory (i.e. the location of the corresponding .lib)?
I know I can specify the search paths, but I'm interested in the default Visual Studio 2010 behavior.
Edit: Doh, this has been indirectly asked and answered before, and I didn't find the question on my initial search.
While remote debugging how are the pdb located (VS 2008)
As you know, when the debugger starts a session, it begins to search for the location where PDB are located. The following article describes the mechanism and the search order of the process.
Related
In MS Visual Studio 2003, I have several related projects and solutions inherited from other developers.
Some binary files (with extensions including ncb, opt, idb, pdb, and pch) reference absolute file-system paths that don't exist on my PC but did on the previous developers' PCs.
One or more of the projects seem to depend on these paths, because the paths appear in the "Resolve Ambiguity" dialog-box when I try "Go To Definition" in source files in some projects.
I have checked the properties of all the solutions and projects in Visual Studio and can't find any reference to these paths. How can I change or remove them without directly editing the binary files?
Edit:
I've used a third-party text-editor to search all file types in the whole directory tree for these solutions and projects.
I've searched for the bad paths containing both single and double-backslashes.
Also, one of the paths contains a username, so I've searched for just the username without the rest of the path.
All of the bad paths are referenced only in binary files. They don't appear in any source-code, solution (.sln) or project (.vcproj) files.
Solved...
According to other resources, the binary files can be deleted.
I deleted those files and rebuilt the solution, which caused Visual Studio to recreate the binary files, and now there's no reference to the nonexistent paths.
I had thought the path references might be the cause of a problem I had running a test application for the solution, but that turned out to be unrelated - the test app was loading an old DLL from C:\Windows\SysWOW64 when I expected it to be using my latest built version.
I have a *.dmp (dump) file of my crashed application. Now, I want to analyze the crashed process on a different machine. That is, the app crashed on one machine, and I have Visual Studio on other machine.
Now, what do I need to be able to see stack trace and all symbols of my app? Is *.exe file and the *.dmp file sufficient?
Or do I need also the source code and PDB file?
If so, should the source code and executable file be placed in the same directories structure as it is on the machine the process was running?
How to attach PDB file to crash dump file in Visual Studio?
No, you definitely need the .pdb files to get decent stack traces. By far the simplest way is to do this from the machine on which you built the program, the source code and .pdb files will be in the right place.
Next best thing is to copy the exact same executables into the exact same folder in which it was installed on the failing machine. Copy the .pdb files into that same directory, that's where the debugger looks next if it can't find them in the original build location. Once the debugger lands on a statement with source code and the .pdb wasn't stripped then it will prompt you to give the source code file location.
Next best thing is Tools + Options, Debugging, Symbols and add the path to the directory that contains the .pdb files.
In that same dialog, also turn on the Microsoft Symbol Server (http://msdl.microsoft.com/download/symbols). That gets you the symbols for the Windows DLLs and lets you accurately trace back to your own code if the crash occurred in a Windows DLL.
I'm not using the default Visual Studio project path to build my program into, because I want to emulate a release, and write tools to search for resources. After tinkering with the settings, I've got VS to output to the right folder, and to copy the DLLs to a bin folder in the main folder. However, I can't get the .EXE it generates to find the DLLs, it will only find what's in it's directory, but I don't want to be messy like that. The debugger works fine, but it won't work standalone. How do I tell VS to tell the .EXE where to find it's DLLs? Do I have to edit the PATH? That seems messy, as I've never had good experiences with it. I've tried Project Settings -> VC++ Directories, but it still won't find it, as I'm assuming that that's for .LIB files.
Here is a diagram of my folder hierarchy.
-root
--bin
---[Required DLLs]
--data
---[Program Resources (images, sounds, configs, etc.)]
--Program.exe
Using Visual C++ 2010 Express Edition.
How do I tell VS to tell the .EXE where to find it's DLLs?
Edit the Release Run Configuration and change the working directory where your dlls reside.
You will still have to run your exe through the ide for this to work.
Do I have to edit the PATH?
No
This doesn't have anything to do with Visual Studio. It is Windows that can't find the DLL. It has no reason to look in an arbitrary subdirectory for a DLL. It isn't otherwise clear whether these are implicitly loaded DLLs or if you use LoadLibrary to load them yourself.
You don't have much of a problem if you use LoadLibrary(), just pass the full path name of the DLL. GetModuleFileName(NULL, ...) helps you build the path string. You'll have a Big Problem if these are implicitly loaded. In that case, there should be preciously few reasons to not store the DLLs in the same directory as the EXE. And yes, you don't want to mess with the PATH environment variable. Or the current working directory.
In Resharper, there's an option to navigate to sources from symbol files. If I enable downloading, the navigation works - I can step into the code of Console.Writeline and so forth.
However, I have already downloaded the entire reference source - is there a way to direct Resharper to that source, so it doesn't download unnecessarily?
I've configured the reference source according to the instructions on the site
It's not possible at the moment. Please vote/watch http://youtrack.jetbrains.net/issue/RSRP-126489
I was able to get this working with Visual Studio 2015 RTM and ReSharper v9.1.3 (and Visual Studio 2013). This is what I did...
NOTE: This is quirky. I'm not sure why, but sometimes the downloaded symbols have source code info in them and sometimes they don't. I had to repeatedly delete symbols from my cache and try to get the appropriate ones by attached the debugger to apps/websites and go to the Tools->Options->Debugging->Symbols and clicking Load All Symbols. I also did some source-stepping, and I had to copy the PDB files from my Symbol Cache into directories in the GAC and in C:\Program Files (x86)\Reference Assemblies. Finally, I went to the properties of the Visual Studio project and add F:\dd to the list of Reference Paths. I'm now able to right-click Navigate to Sources to most classes.
Short version:
You have to use http://referencesource.microsoft.com/symbols as your symbol server instead of the default Microsoft Symbol Server
The symbols expect to find the Reference Source files in F:\dd.
Delete all cached symbols so it pulls them fresh from the newly added symbol server.
Long version:
Configure Visual Studio according to the instructions found on the official .NET Reference Source site.
Go to Visual Studio's Tools->Options->Debugging->Symbols, stop using Microsoft Symbol Servers and use the Reference Source Symbol Server (http://referencesource.microsoft.com/symbols) instead.
Delete all of your cached symbols! The PDBs in your cache do not have any information about the source code files. Visual Studio may have locked some of them, so you may have to close it first.
Download the zipped up Reference Source file for the .NET Framework version you're working with.
.NET v4.5.1
.NET v4.5.2
.NET v4.6
Here's the tricky part. The zip file you downloaded contains a folder called Source. The symbol files will expect that folder to be F:\dd. You can open up one of the PDBs retrieved from the new symbol server you added to see what I mean:
If you have an F:\ drive, it's easy: extract the Source folder from the zip file to F:\ and rename it to dd and you're good to go.
If you don't have an F:\ drive, you create an F:\ partition or load a virtual disk. I used a mapped network drive by extracting the Source folder into the shared folder C:\Code.
Then I mapped a network drive to \\MYPC\Code:
I didn't want to rename the folder to dd, so I named it ReferenceSource and created a directory junction using Command Prompt (must run as Administrator):
cd C:\Code
mklink /j dd C:\Code\ReferenceSource
Voila. Now I have an F:\ drive mapped to C:\Code and a junction dd that points to C:\Code\ReferenceSource.
I have a Visual Studio (2008) solution consisting of several projects, not all in the same namespace. When I build the solution, all the DLL files used by the top level project, TopProject, are copied into the TopProject\bin\debug folder. However, the corresponding .pdb files are only copied for some of the other projects. This is a pain, for example when using NDepend.
How does Visual Studio decide which .pdb files to copy into higher level bin\debug folders? How can I get Visual Studio to copy the others too?
References are as follows: all the DLL files are copied to a central location, without their PDB files. TopProject only has references to these copied DLL files; the DLL files themselves, however, evidently know where their PDB files are, and (most of them) get copied to the debug folder correctly.
From MSDN:
A program database (PDB) file holds
debugging and project state
information that allows incremental
linking of a Debug configuration of
your program. A PDB file is created
when you compile a C/C++ program with
/ZI or /Zi or a Visual
Basic/C#/JScript .NET program with
/debug.
So it looks like the "issue" here (for lack of a better word) is that some of your DLLs are being built in debug mode (and hence emitting PDB files), and some are being built in release mode (hence not emitting PDB files). If that's the case, it should be easy to fix -- go into each project and update its build settings. This would be the default scenario, if you haven't done any tweaking of command line options.
However, it will get trickier if that isn't the case. Maybe you're all in release or debug mode. Now you need to look at the command line compile options (specified in the project properties) for each project. Update them to /debug accordingly if you want the debugger, or remove it if you don't.
Edit in Response to Edit
Yes, the DLL files "know" that they have PDB files, and have paths to them, but that doesn't mean too much. Copying just DLL files to a given directory, as others have mentioned, won't clear this issue up. You need the PDB files as well.
Copying individual files in Windows, with the exception of certain "bundle"-type files (I don't know Microsoft's term for this, but "complete HTML packages" are the concept) doesn't copy associated files. DLL files aren't assembled in the "bundle" way, so copying them leaves their PDB file behind.
I'd say the only answer you're going to have is to update your process for getting the DLL files to those central locations, and include the PDB files ... I'd love to be proven wrong on that, though!
First off, never assume anything. Clean the solution, rebuild it in debug mode, and check to see if all PDB files are created. If not, that's your problem.
If they are created, and they're not all getting copied, you can get around this by creating a post build event that manually copies the PDB files to the desired locations. This is just a workaround, of course.
The only other thing I can think of is that your solution file has become corrupt. You can open your .sln as an XML file and examine the contents. Check the configuration for the projects that are acting as expected and compare them to those that aren't. If you don't see anything, you have to repeat this at the project level. Compare working .csproj (or whatever) project files and the non-working ones.
Edit in response to edit:
If you're just manually copying stuff around, then manually copy the PDF files as well. DLL files shouldn't "know" anything about PDB files, I believe. Just stick them in the destination directory and go have a cup of coffee. Relax.
Check when you clean the solution, that it is actually cleaned.
I've seen Visual Studio leave files hanging around in bin\debug directories even after cleaning. Delete the bin\debug directory on all of your projects and rebuild.
As other posts have said, you may have a compiler/corruption issue.
But, as Will said, if the PDB files are being created, but not showing up where you want them, create a post-build step. Here is the post-build step I define for every project in my solution. It makes sure all output files are copied into a common directory.
If your project file is in \SolutionDir\ProjDir, then the first line of the post-build step will copy the output files to \Solution\Bin\Release or \Solution\Bin\Debug. The second line copies the PDB file if this is a debug build. I don't copy the PDB file for release builds.
So, \SolutionDir\Bin now contains all your output files in one location.
xcopy /r /y $(TargetPath) $(ProjectDir)..\$(OutDir)
if $(ConfigurationName) == Debug xcopy /r /y $(TargetDir)$(TargetName).pdb $(ProjectDir)..\$(OutDir)