Reduce The Burden Of Tech Support For Your Windows Applications

In a perfect world, applications would run without issues and you could completely forgo a help desk or technical support. Sadly, that’s not the case so the best you can do is make sure both you, and your customers, have the tools at hand to diagnose problems and generate debug information.

Image: Wonderlane / Flickr, licensed under Creative Commons 2.0

To the right is the diagnostics tool we provide with our game, Zafehouse: Diaries. It’s written in C#, has a straightforward interface and is essentially bullet-proof. Admittedly, it could be more user-friendly, but it does precisely what we need it to do — help customers without our intervention and when we do need to get involved, it streamlines the boilerplate back-and-forth you go through when providing technical support.

The tool gives us a way to add in compatibility fixes, information-gathering methods and other helpful functions without having to update the game itself. It also means if the game won’t run at all, the user still has a way of trying out workarounds and generating debug data. It’s quite common these days for games to come with external launchers or configuration tools to provide a similar type of support for the main application. Heck, games based on the Doom 3 engine come with a safe-mode that runs the game at the lowest graphics settings!

Hopefully, though, you shouldn’t need to go to these extremes. You can however easily reduce the burden on your customers when it does come time to resolve a problem. Here’s a list of troubleshooting tools we’ve found useful with Zafehouse (or plan to include in the future):

1. Generate file hashes: Sometimes files become corrupted, be it from a dodgy hard drive or aborted download. Fortunately, you can avoid a lot of hassle by allowing customers to quickly generate a list of hashes for all the critical files in your application. Then, it’s a simple matter of comparing hashes to known working versions and replacing the damaged file.
2. Automate complex troubleshooting processes: Probably the least enjoyable activity of troubleshooting is guiding someone through a series of steps that could easily be automated with a batch file, script of custom utility. It’s possible to predict ahead of time the problems an application might have, the minimum system requirements and the frameworks or runtimes it requires. You can then create a user-friendly tool that checks for these requirements and compiles a report, ready to be emailed or, if you want to get even more hands-off, sends it to you automatically. Our tool, for instance, makes a command line call to Microsoft’s DirectX control panel to output a system diagnostic as a text file. While this isn’t a hard thing for a user to do manually, it’s one less process we have to describe and it centralises all our troubleshooting options.
3. Provide workarounds for common problems: Sometimes, it’s not always possible to find the root cause of a bug or quirk, but you might have a workaround that does help, but at the expense of performance or compatibility with other configurations. Ideally, you’d have detection code to activate these workarounds without user interaction, but if the conditions that create the problem aren’t predictable, you should give users the ability to turn these workarounds on if needed.
4. Including a debug build: You should always distribute a release build of your application when it’s deployed, but you might consider adding the debug build in there as well. With .NET, the release builds do not include debug symbols, so while error messages will usually supply a method name, they won’t be accompanied by a line number. This can make it hard to find out exactly where a problem is occurring, especially if it’s a rare one. Running the debug build doesn’t need to be obvious — provide it as a command line option or include it in a separate tool so it’s only visible when necessary.