Release generating .pdb files, why?

Question

Why does Visual Studio 2005 generate the .pdb files when compiling in release? I won't be debugging a release build, so why are they generated?

Solution 1

Because without the PDB files, it would be impossible to debug a "Release" build by anything other than address-level debugging. Optimizations really do a number on your code, making it very difficult to find the culprit if something goes wrong (say, an exception is thrown). Even setting breakpoints is extremely difficult, because lines of source code cannot be matched up one-to-one with (or even in the same order as) the generated assembly code. PDB files help you and the debugger out, making post-mortem debugging significantly easier.

You make the point that if your software is ready for release, you should have done all your debugging by then. While that's certainly true, there are a couple of important points to keep in mind:

1. You should also test and debug your application (before you release it) using the "Release" build. That's because turning optimizations on (they are disabled by default under the "Debug" configuration) can sometimes cause subtle bugs to appear that you wouldn't otherwise catch. When you're doing this debugging, you'll want the PDB symbols.

2. Customers frequently report edge cases and bugs that only crop up under "ideal" conditions. These are things that are almost impossible to reproduce in the lab because they rely on some whacky configuration of that user's machine. If they're particularly helpful customers, they'll report the exception that was thrown and provide you with a stack trace. Or they'll even let you borrow their machine to debug your software remotely. In either of those cases, you'll want the PDB files to assist you.

3. Profiling should always be done on "Release" builds with optimizations enabled. And once again, the PDB files come in handy, because they allow the assembly instructions being profiled to be mapped back to the source code that you actually wrote.

You can't go back and generate the PDB files after the compile.^* If you don't create them during the build, you've lost your opportunity. It doesn't hurt anything to create them. If you don't want to distribute them, you can simply omit them from your binaries. But if you later decide you want them, you're out of luck. Better to always generate them and archive a copy, just in case you ever need them.

If you really want to turn them off, that's always an option. In your project's Properties window, set the "Debug Info" option to "none" for any configuration you want to change.

Do note, however, that the "Debug" and "Release" configurations do by default use different settings for emitting debug information. You will want to keep this setting. The "Debug Info" option is set to "full" for a Debug build, which means that in addition to a PDB file, debugging symbol information is embedded into the assembly. You also get symbols that support cool features like edit-and-continue. In Release mode, the "pdb-only" option is selected, which, like it sounds, includes only the PDB file, without affecting the content of the assembly. So it's not quite as simple as the mere presence or absence of PDB files in your /bin directory. But assuming you use the "pdb-only" option, the PDB file's presence will in no way affect the run-time performance of your code.

_{^* As Marc Sherman points out in a comment, as long as your source code has not changed (or you can retrieve the original code from a version-control system), you can rebuild it and generate a matching PDB file. At least, usually. This works well most of the time, but the compiler is not guaranteed to generate identical binaries each time you compile the same code, so there may be subtle differences. Worse, if you have made any upgrades to your toolchain in the meantime (like applying a service pack for Visual Studio), the PDBs are even less likely to match. To guarantee the reliable generation of ex postfacto PDB files, you would need to archive not only the source code in your version-control system, but also the binaries for your entire build toolchain to ensure that you could precisely recreate the configuration of your build environment. It goes without saying that it is much easier to simply create and archive the PDB files.}

Solution 2

PDB can be generated for Release as well as for Debug. This is set at (in VS2010 but in VS2005 must be similar):

Project → Properties → Build → Advanced → Debug Info

Just change it to None.

Solution 3

Without the .pdb files it is virtually imposible to step through the production code; you have to rely on other tools which can be costly and time consuming. I understand you can use tracing or windbg for instance but it really depends on what you want to achieve. In certain scenarios you just want to step through the remote code (no errors or exceptions) using the production data to observe particular behaviour, and this is where .pdb files come handy. Without them running the debugger on that code is impossible.

Solution 4

Why are you so sure you will not debug release builds? Sometimes (hopefully rarely but happens) you may get a defect report from a customer that is not reproducible in the debug version for some reason (different timings, small different behaviour or whatever). If that issue appears to be reproducible in the release build you'll be happy to have the matching pdb.

Solution 5

Also, you can utilize crash dumps to debug your software. The customer sends it to you and then you can use it to identify the exact version of your source - and Visual Studio will even pull the right set of debugging symbols (and source if you're set up correctly) using the crash dump. See Microsoft's documentation on Symbol Stores.

View more solutions

Comments

[mistertodd]

Why generate pdb in realease? So when a crash report comes in from the wild you have information to debug it. The other value is that customers can debug it when the original author won't.

[m.edmondson]

But why would you do that? If your software is ready for release then you should've done all your debugging by then

[Aliostad]

Because you can debug the production issues. Once we had to do it.

[m.edmondson]

How do you do this? Is there some kind of tool that lets you remotely debug?

[Steven]

Advantage of heading PDBs for production code is that .NET will use these files when throwing exceptions. It generates stack traces with file names and line numbers, which is often very handy!

[m.edmondson]

So if I don't have them on the server, there won't be any stack trace or exception info?

[Cody Gray]

@m.edmondson: Yes, that's correct. You'll still be informed what the thrown exception was (like FileNotFoundException), but you won't be able to see a stack trace. That makes it very difficult to pin down exactly which line of code caused the exception to be thrown.

[Marc Sherman]

@m.edmondson Get access to the remote machine using RDP, Webex, etc. and install windbg there. Set up your symbols path and bam, you're golden!

[Marc Sherman]

"You can't generate the PDB files after the compile." - If your source code hasn't changed then you can rebuild to generate a usable PDB after the fact. By default, windbg won't load this PDB but you can force it to load by specifying the /i option like this .reload /i foo.dll. That will load foo.pdb even if foo.pdb was created after releasing foo.dll.

[marknuzz]

A link to a more detailed guide would have been more helpful. This one-line how-to might lead people (like myself) on the wrong track. Most .NET devs will know nothing about Windbg for example.

[Matthew]

@m.edmondson - Some editions of Visual Studio have the ability to perform remote debugging. From the debug menu you "attach to process" on the remote machine.

[RBT]

@m.edmondson Just to add if you are looking for a tool to remotely debug one of the issues in your production boxes then windows SDK comes with a very famous tool called WinDbg which supports remote debugging. Please have a look at the below mentioned link. Hope this helps! msdn.microsoft.com/en-in/library/windows/hardware/…

[Resource]

The logging you use to capture production exceptions would benefit from having info re stack trace, line numbers etc.

[Kaveh Hadjari]

Is it such a good idea to remote debug a production application instance? Won't it break parallel execution of threads and force them to run in serial while debugging?

[Punit Vora]

@Steven: Thank you so much. I have been struggling for days about why my testing servers do not include line numbers in stack traces while the same code in dev produces exceptions with stack traces having line numbers and file names! That explains it!

[Cody Gray]

@the In the footnote, I linked to an article explaining that "the C# compiler by design never produces the same binary twice. The C# compiler embeds a freshly generated GUID in every assembly, every time you run it, thereby ensuring that no two assemblies are ever bit-for-bit identical." That explains why it has a different hash, and therefore a different PDB file. This is fixable with a hex editor, but not user-friendly. And also outside of this answer's scope.

[Mariusz Jamro]

This will delete ALL *.xml files, be careful with that.

[K Smith]

There is a new feature in Roslyn called deterministic builds. "The /deterministic flag causes the compiler to emit the exact same EXE / DLL, byte for byte, when given the same inputs." What this means is a project origionally compiled with this flag, can be recompiled to the exact same binary, as long as the code you are compiling is the same. A longer explanation can be found at Deterministic builds in Roslyn

[TOP KEK]

Many comment here are just misleading. You will be able to see full stack trace with method names from metadata. Unless you obfuscate it, the only difference with/without .pdb files is existence of source file names and line numbers in the stacktrace.