I'm trying to profile a Win32 native application which also makes use of some external DLL's which are same Win32 native build.
When I stop data collection at some point, the profiler starts generating an overview how much process time and data are collected where - but whatever it is, it always shows me "External code" in this tree.
To clarify my problem: this happens for all positions in my application, means where sources are available and which are built with debug symbols!
Any ideas what could cause this? Thanks!
if you want show source code at debug or profiler mode, you must got pdb file for bins(include exe and dlls).
for "some external DLL's", may you can't get a match pdb.
for you win32 exe, you must generate pdb file for debug, you can google it.
When debugging a C++ Project using Visual Studio 2010, it cannot find the source for crt. When I am trying to go inside one such module, it displays "No Source Available". It also does not provide an option to Browse so that I can help it locate the source location.
Under the Option Solution->Common Properties->Debug Source Files, the proper location to the crt source is updated.
In lack of source level debugging of crt I have to read through the disassemble which is getting difficult.
Can anyone help me figure out what might be going wrong?
Please Note ** I am using an external build system via Visual Studio to build my C++ Project.
With the guidance of Hans here how I narrowed down to the problem.
While the breakpoint was still active, I listed all the Symbol Load information. I realized that msvcr100d.i386.pdb did not match the dll. It actually went all the way down to fetch from the microsoft public symbol store which off course had the symbols stripped off. So that was the root cause of my problem.
And here is a similar problem in social.msdn
You can see the cause of the problem by using Debug + Windows + Modules while you have a break active. Right-click msvcr100d.dll and select "Symbol Load Information" to get info about the .pdb that the debugger uses.
For some reason the Microsoft Symbol Server supplies one that has the source info stripped. It is probably intentional, something to do with service and security patches of the DLL getting out of sync with the source code in vc/crt/scr. You can get a real answer instead of a guess by posting to connect.microsoft.com
A workaround of sorts is to compile your code with /MTd instead of /MDd, if that's possible at all. Project + Properties, C/C++, Code Generation, Runtime Library setting. The debugger will then use the .pdb file in vc/lib. Do keep your eyes on the ball, debug your code instead of the CRT's.
You can find the sources for the CRT in your installation folder, subfolder VC\CRT\SRC.
If they're not there, did you install them when installing VS2010? (not sure whether you can really choose this).
I am having some trouble debugging a visual studio 2008 C++ project. When I start running it in debug, the breakpoints are disabled with the message
The Breakpoint will not be hit. No Symbols have been loaded for this
document.
I have tried cleaning and rebuilding, but this doesn't make a difference.
I also tried looking in Debug->Windows->Modules. If I right click on the module I am trying to debug and press Symbol load information it brings up a list of places it has tried to load the symbols from. The first in the list is correct and the file exists, but next to it is this error
C:\path\to\my\symbol\Debug\MyProject.pdb: Unknown symbol handler for
error
Does anyone know what causes this or how to fix it?
First of all, it is possible that some of your modules won't show in the module window, because some of them may be loaded dynamically (only as needed).
You might want to check in your project properties under Linker > Debugging > Generate Program Database File and Generate Debug Info. Be sure these two are set properly.
Also, check if C/C++ > General > Debug Information Format is set to Program Database for Edit And Continue (/ZI) or something similar.
I know you mentioned that your symbol file exists, but checking what I just mentioned will ensure you have the right version of your symbol in the right place.
Finally, check if all your project and files in your solution are set to compile as Debug and not Release or something else, because no symbols will be generated (hence none will be loaded) for this project / file.
Hope this helps a bit.
In my case, the problem was solved by checking "Use Managed Compatibility Mode" in Tools / Options / Debugging / General.
In case anyone has this problem when using 'Attach to process', the answer to this question solved it for me:
Visual Studio is not loading modules when attaching to process
Specifically, switching to 'Native code' in the 'Attach to' options instead of 'Auto'.
I have managed to solve this by copying my source sideways and checking out a completely clean copy. I assume it was some setting stored in the projects .suo file.
Go to the "Properties" for the website that would use that dll for debugging and then select "Native Code" in the "Debuggers" section below:
There could be a problem with the mspdbsrv.exe process. Try killing it and start debugger again.
For me the fix was in restarting the Visual Studio :) As simple as that. Nothing else helped - tried to Clean (even deleted all files in the Debug folder), checked settings, even killed the mspdbsrv.exe process, but only VS restart did the trick.
In the Modules window you can right click and add your Debug output folder to folders where your system looks for symbol files. Also, the thing that worked for me was deleting all the output files manually, Clean won't do it every time and that's why even though the .pdb file is generated, it doesn't correspond to your output files, thus not loading symbols from it.
Delete all files in the bin and obj folders. Then build the solution again. If your problem was like mine, it seemed like VS was loading an older version of a specific unknown file that rebuilding the solution/project would not replace. Make sure to make a copy of your solution/project before trying this. Good Luck!
Make a copy of your "Debug" folder within your project's folder, then delete every file in the original "Debug" folder. As additional measure if you had your visual studio already running with your project loaded, close it after deleting Debug's contain and reopen it before re-build the whole project, theoretically this action will create new copy of symbol files and the rest needed to debug your code.
I found out this problem occurred to me when I moved my files to other computer and try to compile and debug my code from there, although all folder and drive names were the same, some how the IDE was unable to use the previously created symbol files.
Hope this work around works for some one else !.
VS2015 C++
I ran into the same problem after cancelling the loading of symbols whilst attempting to debug my application in VS2015. After this, VS2015 refused to load the symbols for the project I was interested in (multiple sub projects in a solution with C# calling C++ DLLs). Solutions above did not work for me, but this did.
For Visual Studio 2015 (C++):
Right click on your project that your break point is in and select
properties Expand C/C++
Select General under C/C++
Change the Debug Information Format to any other option
Click Apply
Change the Debug Information Format back to its default "Program
Database for Edit And Continue (/ZI) (or whatever you prefer)
Click Apply
Now rebuild your project
Hope this helps.
Alan M
1) Right click on the project you want to debug.
2) Select [Properties]
3) Select the [Build] tab
4) Make sure [Define DEBUG constant] and [Define TRACE constant] are checked
5) Click the [Advanced] button at the bottom of the Build tabpage
Make sure that [Debug Info:] is set to [full]
6) Click [OK]
7) Rebuild the project
In my case, "use library dependency inputs" in "linker->general"should be set to yes, then the problem is solved.
None of the above helped me...
At the end I changed from Debug\X64 to Debug\win32, this helped, probably it's some configuration which isn't the same in both. Maybe this will help as a
workaround for someone...
Hope that could help anyone.
I'm debugging a WIA driver, and came across this similar problem.
I noticed this log :
DLL named C:\Windows\System32\WIA\wiadriverex.dll cannot be loaded (LoadLibraryEx returned 0x0000007E). Make sure the driver is installed correctly
Then I realized that it is due to DLL dependency. Then I copied required DLLs to System32, the problem is gone. Pay attention, copy to System32, or it won't work for me.
It helped in my case:
Debug -> Attach to process
Scroll down to w3wp.exe
Check "Show processes from all users
After refresh scroll again to w3wp.exe
Select new one with type x64, Managed (Native compilation)
Try disabling /GL option if it has been enabled in C/C++ / General / Optimization / Whole program optimization.
Initially, I had no issue with debugging my program but after tweaking here and there the issue that OP says began to arise.
The module and its symbols were loaded and nothing in this guide seemed to correspond to my problem. Turning /Zi to /Zl also didn't help.
I'm not sure why, but, it's sort of a compiler behavior I haven't been experienced before. FYI, /GL option is not a default in the C++ projects in VS2017.
In my case, the error was due to the fact that part of the code was connected as an external library. In order for debug process to work also when going into the code of the external library, it was necessary to add not only its headers, but also the implementation files - folder Source Files of Solution Explorer.
In my case it was debugger type.
I used remote windows debugger, changing it to local solved an issue.
Debugger options:
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 am analyzing a .dmp file that was created and I have a call stack which gives me a lot of info. But I'd like to double click on the call stack and have it bring me to the source code.
I can right click on the call stack and select symbol settings.. where I can put the location to the PDB. But there is no option for the source code directory.
The source code directory is unfortunately hard coded into the pdb's however if you know the folders required you can use windows concept of symbolic links, junctions.
I use the tool Junction Link Magic
Read this article about how to set up a Source Server (aka SrcSrv) integration at your site.
I took the time to follow these steps for our codebase, and now we are able to take a .dmp file from any build of our software in the past 6 months... get a stack trace with symbols... and view the exact source code lines in the debugger. Since the steps are integrated into our automated builds, there's very little overhead now.
I did need to write a custom indexer for ClearCase, but they have pre-existing ones for Perforce, TFS, and maybe others.
It is worth noting that the .dmp support in VS2005 is a little shaky.. it's quite a bit more stable in VS2008.
You'll also need to configure Visual Studio to grab the symbols for the MS products from here in addition to your own symbol server:
http://msdl.microsoft.com/download/symbols
That is described in a few places such as on the Debugging Tools for Windows site.
Windbg allows you to setup source paths same as PDB's paths.
After loading the PDB, manually navigate to the source file that matches the current execution location. A PDB contains the path and filename of the source files that built its associated binary, and I suspect the debugger is smart enough to hook things up when it notices that the filename being displayed and the filename associated with with current binary location, match.