Using a gmail account as a production bug tracking server | Patrick Smacchia


I’d like to share here an idea I implemented 2 years ago in NDepend and that has proven being pretty powerful and useful: Using a gmail account as a production bug tracking server !

By production bug tracking server, I mean a product that can log through the web information relative to bugs that happen on clients machines, during production execution.

By surfing the web, you’ll certainly find OSS or commercial production bug server products. One of the most popular product is certainly FogBugz. But whatever the product you’ll choose, it will necessarily come at the cost of investing time to understand how it works, to configure it, maybe to pay for it and to host it somehow.

Before investing resources in such product, I wanted to implement quickly this idea of using a gmail account as a production bug tracking server. After all gmail is an extremely powerful product, I already know well how to use it and, by imagining that a bug occurence = an email, it is actually adapted to host bugs tracking.

The only work I had to do was the burden of transforming an unhandled exception into an email! Basically the NDepend bug tracking gmail account looks like that:

Each email represents an unhandled exception, and the email subject is what I call the exception hash that identifies the bug through: the NDepend version, a 4bytes hashcode made from the exception stacktrace and the exception type. With this hashcode and the gmail search capabilities, I can readily know how many times a bug occured and its frequency.

For each unhanded exception, the bug tracking system logs all relevant information including: The exception handler context short description (did it happened in NDepend addin for VisualStudio 2010? while starting VisualNDepend.exe? while running an in-process Analysis?…), the .NET Fx version, the OS version, the processor architecture (x86, x64). But also the stack trace (obfuscated) and other information about the exception, including eventually the InnerException information, and all assemblies loaded in the current AppDomain with their versions. Actually I don’t log the OS/.NETFx/VisualStudio languages because this information is given in the Exception.Message and so far, we didn’t stumbled on many language specific bugs (although we had a few, especially because of Japanese installations).

The added value of using gmail, comes from its great capabilities to search in mails. It is really easy to identify if a bug occurs only in a certain context (like only on x64 machine or only in VS2010 when the VS2010 extension XYZ is loaded).

Another cool gmail capabilities is to create rules to do actions on incoming emails. It is pretty easy to create a rule to skip inbox for fixed bugs. In certain situation, it is also great to create some email tag like Bug XYZ reproduced. The bugs are of course identified from part of its content, like the exception hash described above.

With such bug tracking system, NDepend stability is now lower than 1 unhandled exception every 3.000 runs (the number of runs is logged differently through the licensing process). Of course we are not stupidly cheating and we let all exceptions bubble up.  This number is pretty cool if you take account that most remaining unhandled exceptions come from Visual Studio addin API (everyone that had to develop a VS addin understand what I am talking about!).


If you are currently using a bug tracking product, I’d be curious to hear about killer features you’d miss by using such a gmail system. I can imagine Integration with Source Control server or Stacktrace de-obfuscated automatically. What else?