Suppose I have a function that throws an exception. Suppose this function is called by a third-party DLL, and the third-party DLL will handle the exception I’ve thrown.
If Visual Studio decides that the third-party DLL is not "user code" (as seen in the image below) then it will stop on my exception by default, even though it gets handled later. It isn’t exactly wrong to do so; it clearly explains that the exception was unhandled by user code. But what is it that makes Visual Studio call some DLLs "user code" and others not?
I had a theory that this happens because the symbols aren’t loaded, but there are modules in the list that have loaded symbols but are still not considered "user code".
Yes, without a .pdb file the debugger can't tell whether it is user code or not. It is explained reasonably well in the MSDN article:
To distinguish user code from non-user code, Just My Code looks at three things: DBG Files, PDB files, and optimization.
In a standard Debug build, optimization is turned off and debug symbols are created for all modules. When you run a debug build, those modules are considered to be user code. If I call a library function that is optimized and does not have debug symbols, however, it is not user code. Just My Code prevents execution from stopping at breakpoints in the library code, which is usually not code you are interested in debugging. In the Breakpoints window, those breakpoints will appear with the Disabled Breakpoint icon.
Related
I am trying to profile my c++ dll, but the profiler is not working with me. I would like to see the call tree an so on, but only the stl functions show up, and not all disjoint - when i click on any function, their caller is "[broken]".
I don't know if my google skills are just not sufficient, but i can not find any information on what [broken] means, and how to fix it.
This is a debug build. I cannot guarantee this is not due to some compiler settings, but i fell like i have tried everything.
It should be noted that breaking the code and adding breakpoints works fine, so the profiler just doesn't access this information
If it adds any information, profiling the specific DLL as specified here gives the exception "File contains no data buffers".
My guess is that something wrong with PDBs of your output (for instance, you may have /DEBUG:FASTLINK set in your linker's settings, which produces reference-only PDBs).
If it's not the case, you may try my profiler - it works as an extension to VisualStudio, is instrumenting (meaning it's function-accurate) and displays stats in realtime.
First and foremost, I'm an absolute newbie at debugging compiled code (until recently, I didn't even know it was possible!). I've successfully used the VC6 IDE to attach to a process but I can't get WinDbg to work...
The problem is that I have a VB6 service that I need to debug in a production server. I really don't understand much of how the .EXE is compiled because it is generated by an external tool called "NT Service Toolkit". The code I have is compiled into an ActiveX DLL that is used by this .EXE.
I've done everything I found on the internet to make the service debuggable with the VC6 IDE: compile without optimizations and generate symbols. When I use the VC6 IDE to attach to it, it works as expected... I can set breakpoints and everything works fine except for the annoying bug that kills the service when the debugging session stops.
When I try to use WinDbg however, I cannot set breakpoints; it fails with an error:
Unable to insert breakpoint 0 at 00000000`0046f715, Win32 error 0n299
"Only part of a ReadProcessMemory or WriteProcessMemory request was completed."
bp0 at 00000000`0046f715 failed
WaitForEvent failed
I've already downloaded symbols for windows' components from the symbol servers, as instructed in the documentation I could find, and I also included the PDB file for my service in the symbols folder...
One thing I noted is that I can get symbolic information when I check the "Noninvasive" box when selecting the process to attach to because I see things like wow64win!ZwUserGetMessage instead of just the address`offset syntax... but when I do, I also get this warning:
WARNING: Process <PID> is not attached as a debuggee
The process can be examined but debug events will not be received
In this case, I can set breakpoints, but when I try to run the service, it fails with:
0:000> g
^ No runnable debuggees error in 'g'
UPDATE
When I set a breakpoint in "Noninvasive" mode, detach, and reattach with "Noninvasive" un-checked, the breakpoints I set while in "Noninvasive" mode remain, and are hit successfully, but I can't set new breakpoints unless I repeat the whole process (detach, attach in "Noninvasive" mode and reattach). Does this make sense? What could I be doing wrong?
I found the problem. It was a conflict in the module names.
When WinDbg loads the modules for a process, it names them as the file where they live, just WITHOUT extension. Therefore, if, as in my case, two modules that must be loaded share the same name, say MyService.exe and MyService.dll, there will be two modules named MyService; in this case, WinDbg breaks the ambiguity by appending _<start-address> to the name, resulting in, for example:
...
MyService
MyService_11000000
...
(The following is a rationalization of what happened, since like I said, I'm pretty new to "attach to process"-type debugging and I lack knowledge of WinDbg internals...)
My problem was that the PDB file for the DLL (MyService.pdb), which was the module I was interested in debugging, was being matched to the EXE file's module (MyService), so the DLL's symbols were not loaded before trying to "restore" the breakpoints, resulting in the Win32 error 0n299 I was seeing earlier... It appears that the g command also tries to "set" the saved breakpoints, and since the symbols were not yet loaded, it would not let me start the thing after the default breakpoint either...
...
Or something like that... Obviously, if someone has a more accurate explanation, I'd very much like to be enlightened. :)
For the moment, I just changed the service EXE's name, and now everything works fine.
We have a DLL which provides the data layer for several of our projects. Typically when debugging or adding a new feature to this library, I could run one of the projects and Step Into the function call and continue debugging code in the DLL project. For some reason, that is no longer working since we switched to Visual Studio 2008... It just treats the code from the other project as a DLL it has no visibility into, and reports an exception from whatever line it crashes on.
I can work around that by just testing in the DLL's project itself, but I'd really like to be able to step in and see how things are working with the "real" code like I used to be able to do.
Any thoughts on what might have happened?
Is the pdb file for the dll in the same directory as the dll? This should all work -- I do just this on a regular basis. Look in the Modules window which will show you whether it's managed to load symbols for the dll. If it hasn't then you won't be able to step into functions in that dll.
It sounds like you have "Just My Code" enabled and VS is considering the other projects to not be your code. Try the following
Tools -> Options -> Debugger
Uncheck "Just my Code"
Try again
I've gotten around this issue by opening a class that will be called in the project you need, placing a breakpoint, keep the file open, and run the debugger. The debugger will hit the breakpoint and the relative path that VS uses will be updated so that future classes will be opened automagically.
I'm sort of conceptually designing a plug-in I'd love to have here. What I'd want is to be a able to tag line in my code (something like how breakpoints are added) and then get a trace log of when execution runs though them. Rather than set breakpoints (because they don't work outside the debugger), I'd rather that inside the compiler, the extra logging be added so the AST.
The main point would be to compare different runs of a program; it crashes if I do A but not if I do B and most of the code should be the same so where is it diverging?
Right now I'm doing this with file IO and a diff tool; it works but is a bit clumsy.
I guess the question is: Could this be done and has something like this been done?
I don't know of anything that exactly fits your description. However...
For debugging-only use, Visual Studio 2010 has "tracepoints". These are added in the same way as breakpoints, but rather than stopping the program, they output some text to the debug output. Because they're set in the debugger, they don't affect your source code at all.
If you want to trace activity in a release build, then just add System.Diagnostic.Trace.WriteLine() calls into your code. These can be controlled using TraceSwitches, so they can be disabled by default and only turned on if you need extra information to diagnose a problem. Unlike Debug.WriteLine() calls they are included (by default) in release builds as well as debug builds. Note that these trace calls do cost a small overhead even if the traceswitch is disabled, so avoid using them in performance critical regions of your code.
I have an executable (compiled by someone else) that is hitting an assertion near my code. I work on the code in Visual C++ 2003, but I don't have a project file for this particular executable (the code is used to build many different tools). Is it possible to launch the binary in Visual C++'s debugger and just tell it where the sources are? I've done this before in GDB, so I know it ought to be possible.
Without the PDB symbols for that application you're going to have a tough time making heads or tails of what is going on and where. I think any source code information is going to be only in that PDB file that was created when whoever built that application.
This is assuming that the PDB file was EVER created for this application - which is not the default configuration for release mode VC++ projects I think. Since you're asserting, I guessing this is a debug configuration?
Short of any other answers, I would try attaching to the executable process in Visual Studio, setting a break point in your code and when you step into the process you don't have source to, it should ask for a source file.
Yes, it's possible. Just set up an empty project and specify the desired .exe file as debug target. I don't remember exactly how, but I know it's doable, because I used to set winamp.exe as debug target when I developed plug-ins for Winamp.
Since you don't have the source file it will only show the assembly code, but that might still be useful as you can also inspect memory, registers, etc.
Update
If you are debugging an assertion in your own program you should be able to see the source just fine, since the path to the source file is stored in the executable when you compile it with debug information.