I'm currently working on a tool that allows me to change C++-code on the fly. Changed files are compiled in the background, loaded from the .obj, relocated & linked, and patched into the running process.
This works fine so far.
However, I have been unable to load symbols for the new functions so that they are visible by the debugger. I have tried creating a virtual module using SymLoadModuleEx and adding symbols via SymAddSymbol, but that didn't work.
Ultimately, I would like to be able to add symbols and line information for the new functions. I could do that from either a .pdb file or the COFF info stored in the .obj (I have both), but I seem to be missing the crucial part that informs the debugger.
Is there a function for this that I simply missed? Or an undocumented code for RaiseException that is understood by the debugger (similar to naming a thread)?
I use Visual Studio, but any help in getting this to work in either the VS debugger or WinDBG is greatly appreciated.
Related
I have a very frustrating problem, I'm debugging my code, and for complete Call Stack I need to get symbols for msvcr120.dll (msvcr120.i386.pdb).
The thing is, that I can't get it.
tried loading it from MS Symbols Servers, result:
SYMSRV: http://msdl.microsoft.com/download/symbols/msvcr120.i386.pdb/16F5E2EF340A453ABC8B8F67DC6FD8082/msvcr120.i386.pdb not found
http://msdl.microsoft.com/download/symbols: Symbols not found on symbol server.
tried downloading manualy symbols packages for various Windows versions from MS, downloaded aprox. 2GB, got symbols for msvcr from 90 to 110, and two 120 (from Win 10 package):
msvcr120.i386.coresys.pdb
msvcr120_clr0400.i386.pdb
So, is there a way to get "msvcr120.i386.pdb" ?
In order to get the proper PDB for the file, you need to know which module is actually loaded. If you create a crashdump (.DMP) of the program while running (which you can do with taskmanager), it should show you the exact file loaded, including it's full path. You can also use a tool like dependency walker, which may do a better job at finding the full path.
Once you have the path, you can then specifically try to force-load symbols for that module by right-clicking, loading, and pointing to the exact file in question. That should get the proper hash and load the correct PDB from the MS symbol store into your local cache.
What's likely happening is that the program you're running either has a manifest calling out a specific SxS version of the DLL, OR your program has crashed enough that Windows has placed it in "compatibility mode". Either way, that means the program and VS are finding different versions of the DLL, thus the problem you're having. You can also see this when your program crashes on a different machine than the one you're debugging on, especially if they're not both exactly in the same place for windows updates.
If you do dev work regularly, you should disable Windows automatically putting things into compatibility mode. It will save you lots of headaches down the road.
I have built a particular dll with debug information (compiler option /Zi and linker option /DEBUG). Through an interrupt statement in the main program, I launched the Visual Studio for debugging. In the list of modules shown as seen from Debug->Windows menu, I could see that the symbols have been loaded for the dll interested in. However when I open a C++ file from that dll and try to set a breakpoint, it says debug symbols are not available for the document. There is no question that this C++ file was compiled into that dll, and that it is the same source used to build the dll (I only did it). Why does this happen? Please help, before I shoot myself.
I don't have a definitive answer, only a few suggestions.
Sometimes mdm.exe (Machine Debug Manager) stops to work properly. Terminating the process and re-starting Visual Studio helps. If the problem persists between reboots however that probably isn't the cause.
Source-file-times (last modified) that are in the future can cause all kind of weird problems. To check file times, you can do a search for nothing (Windows XP) or "*" (Windows 7). That will list all files in the selected folder. Then sort the result by date to see the max/min file time. I have no idea where the incorrect file-times come from - I just know that it happens from time to time. Might be Visual Studio itself, might be some other tool I'm using.
You could try to start the application that uses your DLL from Visual Studio, with your DLL project already open. To do that, open the "Configuration Properties", select the "Debugging" page, and enter the .exe that should be started (+ arguments if you need any). Then start the debug session as you would for a .exe project.
A cure for many problems with Visual Studio is to "clean" the project manually, and do a full re-compile. Delete all files that are generated during a build process or that store solution or project "options". i.e. all .suo .ncb .user files plus everything in the "intermediate" and "output" folders. If you're using source control, just retrieve the whole project from your source control system into a clean directory, and re-build from scratch. (Getting everything "fresh" from source control also takes care of any potential file-time problems - at least with source control systems that don't preserve file-times)
Another possible reason would be, that VS loads the wrong .pdb file. A .pdb file with a matching name could be found in a symbol server/symbol directory configured for VS (or system wide through the _NT_SYMBOL_PATH variable), or in the VS symbol cache directory. How a .pdb file with a matching name came to be in such a place is a different story, but one can easily check if the wrong .pdb file is loaded: delete the .pdb file generated by the build, and start a debug session. If VS traces "symbols loaded" for the .exe/.dll in question, it must have found a .pdb file in some other location.
Sometimes VS seems to mess up breakpoint locations in some way. I don't exactly know when or how this happens, but one of the symptoms is, that if one deletes some breakpoints, they magically reappear when starting the next debug-session. I found that setting a new breakpoint, then deleting all break points by Debug/Delete All Breakpoints, and the re-setting the required ones helps.
1) Are you not able to hit the breakpoint at all ? Generally, it gets resolved once the code in the module or stack frame needs to be hit.
2) Check if your pdb is not source information stripped
Do a Build->Clean Solution, close visual studio and then restart it and do a fresh build. This happened to me once before, and that seemed to fix it, just some outdated pdb information, I suppose.
In my case, I had renamed the C++ project. The compiler was outputting newName.lib while my other projects were still referencing oldName.lib which of course would not be removed by a Build->Clean.
I found this out by following the advice to manually clean the build directory. The subsequent linker unresolved external reference gave away the situation.
I ported an application from VC6 to VS 2008. I rebuilt the application in release build. The Pdb file is available in the folder where exe is located. But when I loaded the application and put break point I am getting the following message
"The breakpoint will not currently be hit.No symbols have been loaded for this document"
What would be the cause of the issue?
The debugger could not find either the application or the PDBs.
When you start the program, exactly which binaries are loaded are shown in the Output window. Make sure the right files are being loaded. When everything loads properly, the output looks something like this:
'hacks_vs10.exe': Loaded
'C:\Users\john\Documents\Visual Studio
2010\Projects\hacks_vs10\x64\Debug\hacks_vs10.exe',
Symbols loaded.
When the PDB is not found, instead of saying "Symbols loaded" it says:
Cannot find or open the PDB file
Make sure that you are first running the correct version of your application (check the running path), and then make sure that the PDB is in that directory. You can change where the PDB is generated to by tweaking "Project>Properties...>Linker>Generate Program Database File"
The debugger could not find code associated with the source location you put the breakpoint at.
There can be a number of reasons for this. The one I've most often found was a section of code that was truly not compiled in. (either because of preprocessor conditionals or dead-code removal).
I imagine there can be other reasons too (e.g. inlining, though in theory, the compiler could generate the proper mapping for all the inlines. I don't know what VS2008 does here).
Are you sure you're putting the breakpoint in a code path that is supposed to be executed ?
The PDB file you mention is probably not related to the release build,
Debug information is normally absent in the release build (though you can enable it if you have to but should anticipate surprising effects due to compiler optimizations).
Therefore, you can only set breakpoints on known DLL entry points (possible via the Module List view - it has been a while since I used Visual Studio intensively) or directly on assembly instructions.
Note that you could perhaps compile part of your application with debug symbols.
I have just solved a similar problem
I re-referenced all my DLL's
went to (Tools->Options, "Projects and Solutions", "Build and Run") and set "On Run when projects are out of date" to 'Prompt to build'
I'm not sure which of these fixed the problem, but it did!
Got this callstack when I open a Windows crash dump in Visual Studio 2005:
> myprog.exe!app_crash::CommonUnhandledExceptionFilter(_EXCEPTION_POINTERS * pExceptionInfo=0x0ef4f318) Line 41 C++
pdm.dll!513fb8e2()
[Frames below may be incorrect and/or missing, no symbols loaded for pdm.dll]
kernel32.dll!_UnhandledExceptionFilter#4() + 0x1c7 bytes
...
Looking at the module load info:
...
'DumpFM-V235_76_1_0-20110412-153403-3612-484.dmp': Loaded '*C:\Program Files\Common Files\Microsoft Shared\VS7Debug\pdm.dll', No matching binary found.
...
We see that this binary was not even loaded, because the machine used to analyze the dump is a different machine than the machine that produced the dump.
I don't have access to this other machine at the moment -- can I somehow get this stack fixed, or will I always need the exact binary at this exact path location?
If you absolutely want to debug this dump in Visual Studio, then you can get away with copying the system DLLs from the machine that produced the dump to the same folder where your .dmp file is. That way, it will load those binaries instead of trying to find them in the same path on the debugging system as they were on the original system (which probably will contain different versions of the same modules).
As Naveen pointer out though, you won't have this problem when loading the dump in WinDBG (for reasons I have yet to understand). That is why when I get a dump from clients, I always analyze them in WinDBG.
If you need help on using WinDBG for crash dump analysis, the following Web site is full of info on the subject: http://www.dumpanalysis.org/.
Another option is to use the ModuleRescue tool from the folks at DebugInfo.com. This will scan a dump file, allow you to choose the module that isn't loading symbols, and then it generates a fake module that has just enough info in it for the debugger to load the symbols from the symbol server.
When Visual Studio can't load the symbols for this module and opens a dialog asking you to find the symbols, just point your debugger at that fake module and it will load correctly.
This tool basically does the same thing that WinDbg does, albeit with a different workflow.
In a way following on from reading a windows *.dmp file
Having received a dump file from random customer, running the debug session to see the crash, you often find it is in a MS or other third party library. The next issue is that you may not have knowledge of the PC setup to such an extent that you can ensure you have the actually modules available.
For instance I'm currently stuck trying to get symbols to load for ntdll.dll (5.01.2600.5512). In MSVC 2005 the path column in the modules list window shows a * before the fully pathed file name, and refuses to load symbols I have downloaded for XP/SP1/SP1a/SP2/SP3.
I have the symbol server setup to download from the internet and store in a local cache which seems to have been working fine for modules that I do have on my PC.
Using GUI equivelant to the method
Set _NT_SYMBOL_PATH=srv*d:\SymbolCache*\\server1\Third-Party-PDB;srv*d:\SymbolCache*\\server2\Windows\Symbols*http://msdl.microsoft.com/download/symbols
Perhaps I have the wrong symbols, but as new ones are not downloading where do I go to next? Do I have to contact the customer and ask what SP they have installed, and any other patches? Do I have to install that machine and then run up the debugger with the dmp file to get the symbols I need?
If you are using WinDbg (part of the Debugging Tools for Windows package), then it's simple to have it pull the right symbols for you from Microsoft automatically. Configure the symbol path using the ".symfix" (or ".symfix+", to simply append to your existing symbol search path) command.
Once you have that done and you have the crash dump loaded in WinDbg, type ".reload /f" to cause WinDbg to reload the symbols. It will use the information within the dump file itself to pull the correct symbols from Microsoft's public symbol server, regardless of what DLLs you have on your machine.
If for some reason the symbols aren't loading properly after you have done this, enter "!sym noisy" into WinDbg's command window and reload the symbols again. As WinDbg attempts to load them, you will see it output any errors that it encounters in its search/load process. These error messages will help you further diagnose what is going wrong and why the correct symbols aren't being loaded.
This post has information that may also be of use.
If you're typing "Set _NT_SYMBOL_PATH = srv..." into a command prompt, there are two things to consider:
cmd.exe's set command does not ignore whitespace, so this defines a variable called "_NT_SYMBOL_PATH", not "_NT_SYMBOL_PATH".
You must start the debugger as a child of that command prompt. However, you don't have to do this if you use the Control Panel to set persistent environment variables, or if you use the setx command (in Windows Vista or one of the Windows Resource Kits).
If you're setting the symbol path some other way, then this doesn't apply.
What are you using to debug the minidump? I.e., WinDBG or Visual Studio? And how was the minidump generated?
There should be enough information in the minidump to resolve system dll symbols correctly. Are you using a local download of symbols or http://msdl.microsoft.com/?
Update: You should be able to add the public microsoft symbol store to Tools->Options->Debugging->Symbols->Symbol file (.pdb) locations, and then manually load the symbols by right clicking on the module in the Modules window and loading them if it isn't done automatically.
It's also possibly (likely) that VS 2005 doesn't look at _NT_SYMBOL_PATH to resolve minidump symbols.
Try following the instructions at this kb article, and make sure your symbol path is configured correctly, that WinDbg has access to it, and that the ntdll symbols (for example) are actually downloaded to your symbol cache. The article also provides instructions on how to manually download and verify symbols in you cache via the SymChk tool.