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.
Related
I try to debug my product with a PDB file.
When the process is running, I am attaching the visual studio to the process, and then I am trying to load the relevant PDB File.
When I Right click on the DLL, and Load Symbols, i expect to get a File dialog to chose my PDB file, but for some reason, the visual studio found the PDB file in temp folder:
C:\Users..\AppData\Local\Temp\SymbolCache...
I tried to delete this folder, to remove all the folders from the symbols settings, but for some reason, it still detect the DLL on the temp folder.
Even if i try to load a different DLL, it create new folder inside the symbol cache, and it think that the PDB file is existing over there.
Offcurse that i am not able to put breakpoint because it dosent find the real PDB file...
Anyone have any idea how i change it so i will get the File Dialog to chose the right PDB file?
note: I am using Visual studio 2013.
Thanks for the help!
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.
I'm trying to remote debug my webpart. I can successfully attach to the remote process but my breakpoints do not load. Can anyone help me?
PS I've checked the "modules" but my assembly is not loaded there.
PPS My .dll is GAC deployed and I am the admin of both the dev and server.
PPS The .pdb files are on the bin folder of the application: inetpub/.../9090/bin
I was wondering if I can force the "modules" to load a given .dll. Is it?
Is debugging enabled in the web.config of the target web application?
http://msdn.microsoft.com/en-us/library/e8z01xdh%28v=vs.80%29.aspx
UPDATE
http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/05/11/pdb-files-what-every-developer-must-know.aspx
The section on PDB loading says:
The first place searched is the directory where the binary was loaded.
If the PDB file is not there, the
second place the debugger looks is the
hard coded build directory embedded in
the Debug Directories in the PE
file.If the PDB file is not in the
first two locations, and a Symbol
Server is set up for the on the
machine, the debugger looks in the
Symbol Server cache directory.
Finally, if the debugger does not find
the PDB file in the Symbol Server
cache directory, it looks in the
Symbol Server itself.
You need to move the PDB into the same folder in the GAC, or into the same path that you built the assembly from.
Use this method to enable viewing the GAC folders
http://blogs.msdn.com/b/johnwpowell/archive/2009/01/14/how-to-copy-an-assembly-from-the-gac.aspx
I have a C++ application that is built in Visual Studio (2008) and links to a Boost DLL. When debugging, it seems like I need to copy the Boost DLL into the debug folder so the exe I am running in the IDE can link to it. I could use a post-build step to copy the DLL, but I was wondering if there is a setting in Visual Studio that can give it an additional search path for DLLs while debugging?
There is a slight mis perception here. Visual Studio itself does not directly control the loading of DLL's into an application while you are debugging. The loading of DLL's is directly controlled by the operating system. The operating system searches a set of interesting directories for DLL's when a load is requested.
The main way in which VS influences the DLL's loaded is by virtue of copying them to the build output directory. This is typically the directory in which the application is run and hence is one of the paths the OS will search for necessary DLL's.
What directories the OS searches is controlled by a few items. The easiest of which to alter is the environment variable (LIBPATH I believe). In Debug mode you could alter this environment variable to point to your other directory and have the DLL load from there.
There is nothing you can directly set in Visual Studio though.
There are not of lot of options on Windows for DLLs that are implicitly linked to the EXE. Short from storing the DLL in the same folder as the EXE, you can store it in a directory that's listed on the PATH environment variable. Only c:\windows\system32 is guaranteed to be listed, you can't reasonably use that folder. An installer that changes the system environment would work, still not reasonable.
The only real option is to store the DLL in the WinSxS side-by-side cache. You'll need to write a manifest so that Windows can find the DLL. And you'll need to write an installer to put the DLL in WinSxS. Given the quality of the documentation, you'll need to really, really want to do that.
If this is only a consideration for debugging then perhaps it really isn't such a big deal to change the PATH on your dev machine. Use Control Panel, System applet.
You can extend the PATH within Visual Studio by setting the environment variable. There's a good explanation here:
How do I set a path in visual studio?
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)