my friend has made a really helpful class library which I use all the time. I usually use Reflector to see what his code does.
What I really wanted to do was to step through his code while I'm debugging. So he gave me his .pdb file.
Foo.dll (release configuration, compile)
Foo.pdb
Now, I'm not sure how I can get it to auto break into his code when it throws an exception (his code, at various points, thorws exceptions .. like A first chance exception of type 'System.Web.HttpException' occurred in Foo.dll ...
Can I do this? Do i need to setup something with the Symbol Server settings in Visual Studio ? Do i need to get the dll compiled into Debug Configuration and be passed the .dll and .pdb files? Or (and i'm really afraid of this one) .. do i need to have both the .dll, .pdb AND his source code ...
I also had a look at this previous SO question, but it sorta didn't help (but proof I've tried to search before asking a question).
Can someone help me please?
Yes you can, if your friend indexes those PDB's, so that the debugger knows where to find the appropriate source in a source-control system, and if your friend uploads those pdb's to a symbol-server, you can perfectly step through the code while debugging.
I have done this for some projects at work, and this works like a charm.
More info about setting up a symbol server:
Source server helps you kill bugs
Setting up a symbol server
Using symstore
The answer is in in the linked question, though perhaps it's not blindingly obvious, so I'll say it: yes, you need to have the source code in order to step through the source code. The PDB file only tells the debugger what line of what source file corresponds to a particular machine instruction.
You don't need to set up a "symbol server" or anything like that. Just get him to send you the source. When you load the PDB file Visual Studio will prompt for the location of the source files if they're not at the same path.
I guess you posted link to another question just to prove that you have searched because that question does have an answer to your question.
Related
I would like to try and avoid the VB6.exe application when trying to compile my project. It tends to create the *.obj files and then crashes leaving me with no idea what went wrong.
"c:\Program Files (x86)\Microsoft Visual Studio\VB98\VB6.EXE" /m MyProject.vbp
I would like to try and use LINK.exe and C2.exe to compile my application instead. I found a really great article located here on the process with all the switches etc. I was hoping someone has tried something link this and been successful so they can tell me exactly what switches I need to use and a step by step process of how to create the object files and then link them all to the EXE.
I ended up getting this old source to compile. I'm sure my situation was unique but I thought I would share in hopes of helping someone else find their way if this happens to them.
First, I could NOT get this one project to compile to save my life in the end. At first it would compile in the IDE, then only by running the following in a command line...
"c:\Program Files (x86)\Microsoft Visual Studio\VB98\VB6.EXE" /m MyProject.vbp
Then that would not even work and I had to use the package and deployment wizard to compile it which worked some of the time.
I think it was really just hit or miss in the end. But at some point something pointed to a specific module file I had that was used to access (read/write) the registry. I think it was between looking at logs and maybe even the windows event viewer etc. So I started thinking... Maybe it will compile if that was not used. So I removed the module from the project, tried to compile, then VB was nice enough to show me every call that would not work because the referenced function did not exist. I commented out all of those as well then I was able to compile with very little effort and it went smooth again!
So that helped me identify what VB was flipping out about but it did not solve the underlining issue (that I could not compile ALL of my source). So I started trying to work all the source back into the application one by one to see where it would break at.
I first added the module file to the project and just compiled.
Success!
I then tried to uncomment the first thing I commented out (reference to the function in that module) and then recompiled.
Success!
I managed to get all the way back through all my commented out lines of code and put them back the way they were originally. I then recompiled for the final time.
Success!
So at this point I had EVERYTHING back to the exact way I had it before I started trying to compile. Now it works with no issues at all!
In a specific partial view, I consistently get a message in the breakpoints I set:
"The breakpoint will not currently be hit. No symbols have been loaded for this document."
Is there any reason for this to happen? What may I have done?
I restarted Visual Studio and I even restarted my computer, but it didn't work.
What do I have to do to debug this page?
Thanks!
Edit
I edit the partial view file with which I am having problems, but the changes do NOT take effect. So, somehow, that bastard compiler is getting the file from somewhere else. Where?!
I had the same situation after modifying a view that used to debug ok. I reverted my changes and debugging resumed working. I found I had a syntax error on a line. There was no clue it was wrong - there was no red underlining and the project compiled fine.
If you have the problem in your view, I suggest commenting most of the code to a minimal skeleton. If debug works again, uncomment some of your lines back in until you find the problem code. Good luck with that.
There are several possible reasons for that:
The version of the source file is not the one you compiled. Try to recompile.
The DLL containing the code is not loaded in the program at runtime. Use the program in a way that the DLL will be needed if you have dynamic loading of DLL.
You are visualizing a source file which is not in the right directory (another copy of the solution somewhere else on the hard disk). Open the right source file.
You didn't compile the program in debug mode. Recompile it in debug mode.
You didn't launch the program in debug mode. Launch it in debug mode.
This is happening to me too...it's a real pain in the arse. The reason is because your PDB files are missing from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root[random][random]\assembly\dl3[random][guid]
I have about 30 DLL files that get built with my project, I have to go into each one of those stupid temp directories and copy the PDB file for each DLL from my VS build bin. I've posted questions on here about it too but haven't gotten any help. For a quick fix, you can try to copy your matching pdb files over but I'm telling you it's gonna get old real fast.
Someone else in my office has fixed the problem by using the "Publish" feature in Visual Studio and publishing their site straight into a web directory but I haven't had any time to mess with that yet. Someone else has told me that it's a x64 bug in Visual Studio but I find that hard to believe considering how crippling it is.
The way I resolved it is by going to the properties(F4) of the file and set the value of Build Action to Compile.
I´ve tweaked the VC++ settings so that all of my actual code will go to one place, while compiler generated binaries will go to another. This ncb file is the exception though. It is a quite large IDE generated binary file (Intellisense database). I can´t seem to be able to move it anywhere other than the solution folder. I´ve reasearched on google and found a few references saying that this is impossible. Does anyone have a workaround?
Visual Studio doesn't allow you to move that file. This article on CodeProject shows how one person worked around this problem, by creating a "poor man's" version of symbolic links. This involves hooking Windows' CreateFile function. This approach seems like overkill to me; I think I would just learn to live with this limitation if possible.
Are there any VC++ settings I should know about to generate better PDB files that contain more information?
I have a crash dump analysis system in place based on the project crashrpt.
Also, my production build server has the source code installed on the D:\, but my development machine has the source code on the C:\. I entered the source path in the VC++ settings, but when looking through the call stack of a crash, it doesn't automatically jump to my source code. I believe if I had my dev machine's source code on the D:\ it would work.
"Are there any VC++ settings I should know about"
Make sure you turn off Frame pointer ommision. Larry osterman's blog has the historical details about fpo and the issues it causes with debugging.
Symbols are loaded successfully. It shows the callstack, but double clicking on an entry doesn't bring me to the source code.
What version of VS are you using? (Or are you using Windbg?) ... in VS it should defintely prompt for source the first time if it doesn't find the location. However it also keeps a list of source that was 'not found' so it doesn't ask you for it every time. Sometimes the don't look list is a pain ... to get the prompt back up you need to go to solution explorer/solution node/properties/debug properties and edit the file list in the lower pane.
Finally you might be using 'stripped symbols'. These are pdb files generated to provide debug info for walking the callstack past FPO, but with source locations stripped out (along with other data). The public symbols for windows OS components are stripped pdbs. For your own code these simply cause pain and are not worth it unless you are providing your pdbs to externals. How would you have one of these horrible stripped pdbs? You might have them if you use "binplace" with the -a command.
Good luck! A proper mini dump story is a godsend for production debugging.
If your build directly from your sourcecode management system, you should annotate your pdb files with the file origins. This allows you to automatically fetch the exact source files while debugging. (This is the same proces as used for retrieving the .Net framework sourcecode).
See http://msdn.microsoft.com/en-us/magazine/cc163563.aspx for more information. If you use subversion as your SCM you can check out the SourceServerSharp project.
You could trying using the MS-DOS subst command to assign your source code directory to the D: drive.
This is the procedure I used after some trouble similar to yours:
a) Copied to the production server all the EXE & DLL files that were built, each with its corresponding PDB to the same directory, started the system, and waited for the crash to happen.
b) Copied back all the EXE, DLL & PDB files to the development machine (to a temporary folder) along with the minidump (in the same folder). Used Visual Studio to load the minidump from that folder.
Since VS found the source files where they were originally compiled, it was always able to identify them and load them correctly. As with you, in the production machine the drive used was not C:, but in the development machine it was.
Two more tips:
One thing I did often was to copy an EXE/DLL rebuilt and forget to copy the new PDB. This ruined the debug cycle, VS would not be able to show me the call stack.
Sometimes, I got a call stack that didn't make sense in VS. After some headache, I discovered that windbg would always show me the correct stack, but VS often wouldn't. Don't know why.
In case anyone is interested, a co-worker replied to this question to me via email:
Artem wrote:
There is a flag to MiniDumpWriteDump()
that can do better crash dumps that
will allow seeing full program state,
with all global variables, etc. As for
call stacks, I doubt they can be
better because of optimizations...
unless you turn (maybe some)
optimizations off.
Also, I think disabling inline
functions and whole program
optimization will help quite a lot.
In fact, there are many dump types,
maybe you could choose one small
enough but still having more info
http://msdn.microsoft.com/en-us/library/ms680519(VS.85).aspx
Those types won't help with call stack
though, they only affect the amount of
variables you'll be able to see.
I noticed some of those dump types
aren't supported in dbghelp.dll
version 5.1 that we use. We could
update it to the newest, 6.9 version
though, I've just checked the EULA for
MS Debugging Tools -- the newest
dbghelp.dll is still ok to
redistribute.
Is Visual Studio prompting you for the path to the source file? If it isn't then it doesn't think it has symbols for the callstack. Setting the source path should work without having to map the exact original location.
You can tell if symbols are loaded by looking at the 'modules' window in Visual Studio.
Assuming you are building a PDB then I don't think there are any options that control the amount of information in the PDB directly. You can change the type of optimizations performed by the compiler to improve debuggabilty, but this will cost performance -- as your co-worker points out, disabling inline will help make things more obvious in the crash file, but will cost at runtime.
Depending on the nature of your application I would recommend working with full dump files if you can, they are bigger, but give you all the information about the process ... and how often does it crash anyway :)
Is Visual Studio prompting you for the
path to the source file?
No.
If it isn't then it doesn't think it has symbols
for the callstack. Setting the source
path should work without having to map
the exact original location.
Symbols are loaded successfully. It shows the callstack, but double clicking on an entry doesn't bring me to the source code. I can of course search in files for the line in question, but this is hard work :)
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.