Tools of the Trade: Part II – The Repro
In this series of posts, we’re going to take a look at some of the tools we at Microsoft Developer Support -- Database commonly use, how to use them, and the types of issues they can be used to resolve.
This post might seem like a bit of a stretch. For one thing, it’s not about a SQL related tool. That’s not such a big deal – there are plenty of tools that we use that have applications beyond SQL. You can expect more posts in this series about tools that have applications far beyond troubleshooting databases and database connectivity.
However, this isn’t about a specific, pre-existing tool either. Call it a meta-tool, I guess. Pseudo-tool. Something along those lines. One way or the other, even if it isn’t already built for you, a reproduction can be one of the most invaluable and time-saving tools you’ll use to troubleshoot your most difficult issues.
The Repro
In the Product Support Services world at Microsoft, we refer to a simplified, stripped down series of steps that lead to a specific behavior as a Repro. This may simply be a step-by-step to recreate an error, or a simple application that recreates an unusual behavior. When we are working on an issue that is buried in a hulking, production application, we often like to tackle it is by attempting to recreate the issue outside of the in vivo environment. There are a lot of benefits to investing some time in developing a Repro.
It’s probably pretty obvious why you would not want to troubleshoot in a production environment. I personally like to avoid debugging anything that generates revenue – it just seems to ease the tension. There’s more to it, though – not only do you avoid tinkering with your company’s livelihood, a Repro also gives you the advantage of portability. Whatever technology you’re working with, it is much, much easier to get the assistance of Subject Matter Experts if you can actually send them something to play with.
Another big benefit of the Repro is that it helps you to focus on the issue. This is particularly helpful when you need to use other tools to analyze the behavior with which you’re dealing. Whatever kind of tracing you’re doing, you are bound to pick-up extraneous information if you’re running the trace on a production application. Unless you’re very fond of wading through gigantic logs looking for clues, a Repro really helps to avoid getting lost in superfluous data.
Finally, a repro can save you a huge amount of time. It can get so irritating having to click through the same series of screens and options, over and over again, as you troubleshoot an issue in a full-scale application. Being able to make a change to code or the environment, and quickly test dramatically improves the speed of the troubleshooting process. It also has the added benefit of keeping debugging from getting boring.
That’s my case for investing the time in creating a Repro. The next question is: what is the best way to build a Repro? Well, that’s going to depend greatly on the issue and the environment.
One thing that I like to do is work from the inside out. In other words, if I know that a specific line of code is throwing an exception, I’ll create an application with the smallest amount of code I can use to execute that line. If that doesn’t reproduce the behavior, I’ll add more code from the application around it, building up the Repro until it gets the behavior I’m looking for.
Another thing that I’ve found is important is to make sure that I attempt my Repro in an environment that’s as similar to production as possible. I do not recommend attempting to reproduce an issue occurring in a data-access application running on Windows Server 2003 on your grandma’s Mac. It’ll be much easier to create a repro on something that’s as close to the original scenario as possible and then move it to other environments to see if the behavior is any different.
One of the Technical Leads on our team has a good tip for reproducing issues that occur intermittently. For example, say you find that every-so-often your application gets an error when attempting to connect to a data-store. In this situation, it’s probably worth a try to take the connection you’re trying to make and wrap it in a tight loop. It’ll be much easier to launch this and catch the failure than it will be to keep running and re-running a small repro that makes the connection a single time and exits. If you are troubleshooting an issue occurring in a web-application, you may try a tool like Application Center Test to execute your repro many times simultaneously (see: this link for a discussion of using ACT).
Finally, I really recommend carefully documenting your repro. Again, it makes it much easier to get the help of others, and it will also prevent you from forgetting what you had done on Friday after a long weekend. Even if you really cannot find a way to reproduce the issue in a stripped down environment, documenting the steps an end-user takes when the issue occurs can be valuable for helping to clarify the problem statement and focus your efforts.
Posted By: Justin Trobec