1. It’s a best practice as well to do defensive checking of configuration parameters as early as possible in the application life cycle, preferably during start-up. You can throw some more informative exceptions about the problems, which then usually can be solved first-hand (ASP.Net has the very nice ConfigurationException with line-precise error reporting). Without checking the application breaks at odd places at odd moments, which causes more stress and sometimes creates a lack of trust in the stability of the application.

    Most end-users are very intimidated by stack traces, and think the web site is severely broken because of all the weird text on-screen. You can solve this by simply not showing the stack trace in the error page, just log it instead. Of course, you can then still log with full debugging information unless performance requirements demand otherwise. 🙂


  2. I noticed that Visual Studio 2005 generates the .PDB files by default for the Release build!


  3. Peterhe is right that you should try to avoid configuration errors from popping up at random while using the application, but that of course is true for any unexpected exception. The problem with unexpected exceptions is; well, you did not expect them. And if something happens that you did not expect your application is indeed severely broken!

    The point of course is not that this problem could have been avoided, but that you should maximize the amount of information available is a crash sitation without overwhelming the end user with technical details.


  4. We obfuscate(sp) our code for our release product and if a user reports a bug to us we are getting a stack trace and other goodies, however all the line numbers are zero. If we include the pdb and instruct the compiler to include debugging information, will we be allowing people to reverse engineer our code?

    If that is the case, can the pdb wbe analysed with a stack trace outside a runtime envornonment to work out the line number of the problem?


  5. In my post I wrote “unless you have good reasons to hide information about your source code from your end users..”. This is true for most of the projects I work on, but as I guess not for your project.

    I think the problem with the obfuscator is that it removes (among other things) all newlines from the sourcecode before it is passed to the compiler. When generating the pdb file, the compiler has no idea which original source line generated which IL instruction. To get the original source lines in the PDB file you would have to somehow get your obfuscator to keep the line numbers in tact (maybe this is an option somewhere?). The information in the PBD might help a bit to reverse enginere the code, it does contains a lot of information about your code.

    Without the BDP file there is no way I know of to get the source line information in the stack trace. Another option alltogether would be to customize the rendering of the stacktrace, and instead of printing the source line numbers, print the adress of the IL instruction. Maybe you can use Reflector on the Exception.ToString method to find out how you should do this. If a user submits this information, you should be able to map it back to the original sources. Don’t think it will be easey, but keep me posted if it works 🙂


  6. In VS 2005, there are two options other than NONE – FULL and PDB ONLY for ‘Generate Debug Info’.

    For the purposes that you have discussed in this article, which one is appropriate?


  7. Where can i set the “Generate Debugging Information” to true in VS2005?


  8. In VS2005 this setting is found in the project properties page (right click the project -> properties). On the build tab choose Advanced…

    The diffrence between FULL en PDB-Only is explained in the MSDN. (press F1 in the dailog) The default in VS 2005 for a release build is PDB only, for a Debug build it is Full. I have not tested it yet, but I think PDB only is enough for the purpose described above, this means that you can just leave the defaults as they are.


  9. #line can be used in the obfuscated code.  It does not have to give real line number and file name, you can have your secret map.


Comments are closed.