I am investigating a crashing program but cannot load symbols for native image DLLs in Visual Studio 2013. The application is 32-bit and uses .NET 4.0.30319. I confirmed this by checking what version of clr.dll is loaded into process from the modules window. Also from the modules window, I checked where mscorlib.ni.dll was loaded from:
clr.dll C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
mscorlib.ni.dll C:\Windows\assembly\NativeImages_v4.0.30319_32\mscorlib\ce5f61c5754789df97be8dc991c47d07\mscorlib.ni.dll
I was able to successfully generate the PDB for mscorlib.ni.dll:
but when I try to load it into VS 2013 by right clicking on the stack frame for mscorlib.ni.dll and selecting Load Symbols, I get a messaged that says "A matching symbol file was not found in this folder."
I have looked through:
Creating Ngen Pdbs for Profiling Reports/
And followed the simple instructions for generating the PDB because I just want to see function calls at this point,
Get the right .net native symols for Windbg
How to get the PDB file for mscorlib.ni.lib (.Net Framework 3.5)
It looks like the most common source of error is choosing the correct bitness. I know from the modules tab that I am loading the 32-bit variant of mscorlib.ni.dll and again from my screenshot, you can see that I am using the same version of the the .NET framework and the 32-bit version of Ngen.exe. I tried this for WindowsBase.ni.dll and saw the same behavior where I was successfully able to generate the PDB but could not load it.
I have the debugger enabled to Just-in-time debug Managed and Native code.
Questions:
Am I using the wrong version of ngen.exe on to create this PDB?
What does Visual Studio check when it tries to load a PDB?
Is there some other setting I need to enable in VS to debug this type of code?
Thanks!
Related
I am trying to debug some issues occurring within an external library (ClosedXML). If I can work out exactly what's going wrong, I should be able to apply workarounds to the code that calls it.
I have added ClosedXML and manage it via NuGet.
Unfortunately, the debugger states that ClosedXML.PDB cannot be loaded. The checkboxes for 'Microsoft Symbol Servers' and 'NuGet.org Symbol Server' are both checked.
A suggestion was to generate my own pdb file. So, I cloned the ClosedXML repo, checked out the 0.95.4 commit (the version of the NuGet package I'm using) and built the project in Debug mode. I then directly referenced the pdbs produced in the ClosedXML binaries folder in the 'No Symbols Loaded' page in Visual Studio. Unfortunately, none of them work. They each have the same error message:
...\source\repos\ClosedXML\ClosedXML\bin\Debug\net46\ClosedXML.pdb: PDB does not match image.
...\source\repos\ClosedXML\ClosedXML\bin\Debug\net40\ClosedXML.pdb: PDB does not match image.
...\source\repos\ClosedXML\ClosedXML\bin\Debug\netstandard2.0\ClosedXML.pdb: PDB does not match image.
This isn't surprising as the DLL and the PDB weren't built on the same machine, but it is unfortunate.
So, my current workaround is to dereference the NuGet package and instead reference the DLL I've built locally. This works, but it is far from ideal.
To confirm, 'Just My Code' is disabled.
Is there any way I can debug the external code without resorting to changing references each time?
You can use my Runtime Flow tool to investigate called methods and parameters in ClosedXML without .pdb.
I'm trying to debug some of the examples provided in the Maya API SDK.
Building the DLL with Visual Studio 2010 in debug mode worked fine, and the plugin, once loaded into Maya, worked fine.
However after attaching, Visual Studio complains about cannot find or open the PDB file.
I ignored those warning and set some break points, but clearly VS does not break.
Regarding building plugins and debugging by attaching them to Maya, I've read:
https://alliance.seas.upenn.edu/~cis660/wiki/index.php?title=Debug_CPP_Plugin
http://devmaster.net/forums/topic/6965-how-to-debug-a-plugin/
http://www.creativecrash.com/forums/api/topics/help-33-how-do-i-debug-my-plugin
On SE, I have read the following suggestions:
Why is Visual Studio 2010 not able to find/open PDB files?
PDB does not match image Error
Visual Studio 2010 "Cannot find or open the PDB file"
In particular, I tried:
making sure that the plugin that I am loading into Maya is the one that I just built;
verifying that the PDB has the same name, is in the same folder, has been created at
the same time than the DLL;
loading manually the PDB ("A matching symbol was not found");
activating the Symbol Server in VS (fine, but I got only the Microsoft ones obviously)
Usually, putting the pdb in the same folder will always work - however, the times where this doesn't is usually because your dll is being loaded from elsewhere in the path and its not actually running the dll you think it is (at least, that's what happens to me).
Once your app is running, try and delete the dll - if you can, its not loaded. Or you can look at the path in the modules window in VS. That will also give a clue to why its not loaded and give you the option to manually load symbols from anywhere on disk.
For test purposes, I am debugging a minidump(created with .dump /ma) in Visual Studio 2010.
I have symbols available for that dump, but do not have the current binary (it is an executable).
The Module window in VS2010 shows 'No matching binary found' which seems right, since it cannot be found on the path where it was on the target machine.
I still would like to load the symbols, so I right-click the module, select "Load symbols from symbolpath" (which contains a path to the correct pdb), but a dialog pops up which asks me to select the binary file. I am unable to load the symbols for my module.
Why does VS need the image file? WinDbg is able to load the symbol file and show me the faulting stack without a problem.
I think it is by design. Visual Studio is designed and developed by a team while WinDbg is by another,
http://msdn.microsoft.com/en-us/library/htzy3t6f.aspx
If you load a minidump file that was saved with a heap, Visual Studiocan load the symbols even if the application binary is not found. Minidump files without heaps need the binaries to load symbols.
If you want Visual Studio to be the same as WinDbg, you should go to Microsoft Connect and create a feature request,
http://connect.microsoft.com/intro/
I am having Windows 7 x64 SP1. I have downloaded symbols from:
http://msdn.microsoft.com/en-us/windows/hardware/gg463028
I have downloaded and installed x64 RTM and x64 SP1 symbols for Windows 7 x64 SP1. Installed on T:\Symbols folder.
But When I debug a 64-bit native C++ application, the symbols would not load at all. For ntdll.dll, for instance, the PDBs are located in:
T:\Symbols\ntdll.pdb\6192BFDB9F04442995FFCB0BE95172E12
T:\Symbols\ntdll.pdb\CFF40300FD804691B73E12CF2A150EE02
But Visual Studio (2008/2010) will not load symbols. While debugging, from Modules View, I select ntdll.dll and say Load Symbols From -> Symbol Path, the specify the ntdll.pdb. For both of mentioned paths, it will always say:
A matching symbol file was not found in this folder.
I have also added this folder (T:\Symbols) in Debugging -> Options, but it will still not load the symbols. While debugging, Load All Symbols button would be enabled, and clicking would not load the symbol either!
For 32-bit the PDB filename would be wntdll.pdb for ntdll.dll and would be stored in GUID-named folders in fashion mentioned above. But VS will not load symbols for 32-bit debugging either.
Quite interestingly (and frustratingly), when I select Load Symbols From -> Microsoft Symbols Server, it will download and load the symbols perfectly. It will download the symbols at following location (full path for ntdll):
\Users\...\AppData\Local\Temp\SymbolCache\ntdll.pdb\6192BFDB9F04442995FFCB0BE95172E12
Here you can see the GUID is matching with the GUID-named folder in T:\Symbols path, but for manually installed symbols VS is rigid not to load it!
For NTDLL.PDB, despite the respective folder being same, and the size of PDB also being same, the timestamp might be different.
Sometimes VS would also place symbols in:
C:\...\AppData\Local\Temp\SymbolCache\MicrosoftPublicSymbols
If VS would download correct symbols ONLY from Microsoft Symbols Server, then what the use of locally downloaded symbols?
My question is basically how to load locally downloaded and installed symbols?
The download links for the RTM or SP1 symbols are pretty much useless. After each patch day you will get a changed ntdll.dll or other central OS libraries. This will render your "old" pdbs useless. You need to download them therefore from the symbol servers to be sure that you are up to date.
But since not all dlls are changed you should set your Symbol server download cache to the same location where you have unpackaged your downloaded symbols.
Go to:
Tools - Options - Debugging - Symbols
and set the path for Cache symbols in this directory.
Load all symbols means that you do load all symbols for all modules that are loaded in your current process. But it will not dowload all symbols for all dlls that are used by Windows. If you do download Windbg you get a tool called symchk.exe which allows you to download the symbols for all binaries recursively.
I have just been issued with a Windows 7 (64 bit) machine at my code shop. We run Visual Studio 2005. I filled out the Tools|Options|Debugging|Symbols panel, pointing to the Microsoft Symbol Server and caching to C:\windows\symbols, and started a new instance of our app. There was a pause as the MS symbol server was contacted, then the EULA turned up and I accepted, but then no symbols loaded. This is a pretty big problem as much of what's going wrong in my department is down to memory management which requires the OS symbols.
All the local symbols for the app loaded fine, as well as (apparently) MFC80U.i386.pdb. When I examined the Symbol Load Information for ntdll.dll this greeted me:
C:\Windows\System32\wntdll.pdb: Cannot find or open the PDB file.
C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\IDE\wntdll.pdb: Cannot find or open the PDB file.
C:\Windows\symbols\dll\wntdll.pdb: Cannot find or open the PDB file.
C:\Windows\dll\wntdll.pdb: Cannot find or open the PDB file.
C:\Windows\wntdll.pdb: Cannot find or open the PDB file.
I have also downloaded and installed the Windows 7 RTM symbol packages (to C:\Windows\Symbols), both x86 and x64 just to be sure. Still no luck. The x64 ntdll.pdb file lives in C:\Windows\Symbols\ntdll.pdb\CFF40300FD804691B73E12CF2A150EE02 and is NOT called wntdll.pdb as the Symbol Load Information seems to request.
Is it the case that Windows 7 symbols just don't like VS2005?
Try using another directory that you have complete control over, say C:\Symbols.