It seems like there are a plethora of methods for dialing in and checking out what's going on on a client's PC. But they seem to boil down to just 2. Dialing in and checking it out with VNC and Remote Desktop.

VNC seems abysmal with more graphics laden OS's and it sometimes is too much to ask to get a access to a terminal server (especially when the client doesn't have one).

What other methods are out there for connecting with clients to diagnose and fix bugs they they can reproduce, but may not necessarily be able to adequately describe over the phone.

Alternatives to VNC and Remote Desktop are appreciated, but really looking for a better way to do it than just to dial in and check it out - or the most effective way to use VNc and Remote Desktop.

  • 1
    I think this would be a better fit on SuperUser. – Walter Nov 5 '10 at 19:23
  • Like GoToMeetig? – JeffO Nov 5 '10 at 19:30
  • Not really asking for program suggestions, just asking for methods. For instance, if you had chosen to use GoToMeeting (or GoToMyPC) then how do you make it so you can use it for 500 clients. Do they all need to install the Server part of the program? Is that possible for a small business to afford? – Peter Turner Nov 5 '10 at 19:32

We have had good success teaching end users to respond to unhandled exceptions (which are thankfully rare, but which plagued one installation because of networking issues) with these steps (Windows only)

  1. press Shift+PrntScrn
  2. Open Word
  3. press Ctrl+V
  4. Return to the application and click the More Info button
  5. Click in all the words that don't make any sense, and press Ctrl+A Ctrl+C
  6. Return to Word
  7. Click below the picture and press Ctrl+V
  8. Save the file and email it to me.

This lets you see the exception, what they were doing in the background, what data they were looking at (employee id or store id or whatever) and other useful information. I have debugged a lot of things after the fact armed with these screenshots and the stack trace.

The big difference between this and GoToMeeting, WebEx etc (which we use with these clients for demos and training) is that they don't need to repro the bug on demand. When they are working away and the bad thing happens, they follow these steps and we make it all better. (Sometimes by calling their IT rather than changing our code, but honestly the end users don't care.) The impact on them is minimal.

If I needed to, I might also teach them Problem Steps Recorder on Windows 7 which is way cool if you've never used it. But the screenshot and stack track approach carries a LOT of information.

  • Nice, straightforward easy-to-follow instructions. Clearly this has been a successful strategy. – JBRWilkinson Nov 5 '10 at 23:54

Remote Control

We have thousands of computers connected to http://www.logmein.com/. It is absolutely free, but the paid-for upgrades, like a management dashboard to be able to roll out updates to all your machines, are excellent and pay for themselves over time.

We've found the performance to be excellent - very little hit on the remote machine until you connect to it and even then, the draw is fairly low. We have used it to remotely view full-screen MPEG movies playing in large digital out-of-home displays and to troubleshoot touch-screen apps in supermarkets and shopping malls.

It runs on Windows and Mac and can be controlled from Window, Mac or a smart phone. It is a background service, so does not get in the way of the user but can be configured to ask their permission, etc

I highly recommend it.

If you want to just walk one customer through an issue, consider Adobe Acrobat Connect which uses Adobe Flash on both your and their computers to do full-screen remote viewing. You can do up to three-way viewing with the free version.

Other Techniques

Here's a list of some of the other items we use in conjunction with Remote Control to work out what has been going wrong:

  • All the software we put onto the remote machines logs activity to C:\Logs or similar, rotating the logs every 28 days. Make sure the logs are named by date and have time stamps for output. When guiding the customer through a problem, note the time (and timezone!).
  • An agent service on the remote machines checks that the main application processes are running, not leaking, not hung and not crashed. It restarts bad-behaving processes after sending notification (see below).
  • We have agent scripts that can grep these logs for nasty-looking errors and SMTP them to the development team. Obviously, we get Inbox-full pain when we ship buggy code, but its' useful.
  • Not all customer environments are happy with automated outgoing SMTP (looks like spamware) so we use a HTTP web service to upload the things we need.
  • If bandwidth is good, upload a ZIP of the days logs overnight every night until the machine is healthy.
  • If bandwidth is not so good, cherry-pick what you upload, or upload a grep of logs.
  • Keep crash dumps (upload if possible) for diagnosis. You need to have excellent release discipline to ensure you have the exact binary for the particular crash.
  • If you only have outgoing connections and you need to talk to the remote computers some times, consider using the Hamachi VPN service - it's slow, but free and works.
  • Microsoft has a tool named 'collector' which will enumerate all the installed software on a machine, a bit like 'Add/Remove Programs' window. This is invaluable for finding differences between client machines.
  • On Windows, you can automate the Windows Installer engine to interrogate what is installed in terms of products, patches, service packs, etc.

I've been in a situation when there is nobody to even describe you what happened: ATM's (cash machines) running Windows. The best way of diagnosing problems for us was very, very detailed logging. One way is shipping two versions of the binary, one of which is with logging enabled. You switch the binaries when needed. For environments like C# and Java I believe there are tools that can provide non-intrusive function call journalling (i.e. you don't need to modify the code).

  • Switching the binaries is an awesome idea and it would fit in very will with the way we distribute our app. – Peter Turner Nov 5 '10 at 19:40
  • 1
    Java use reloadable logging configuration files. – user1249 Nov 5 '10 at 20:03
  • Why use two binaries? Surely the switch is something like a registry key which you check on startup and either write to the log or not. If you have two different binaries, you risk behavioural differences between them due to different optimiser decisions, etc. – JBRWilkinson Nov 5 '10 at 23:48
  • @JBRWilkinson: depends on the language/environment: in C/C++ call journalling would have a huge performance overhead even if no actual writing goes to the log files. In managed environments e.g. .NET the overhead is there anyway so you probably won't see a big diffrence, and that's where you are right: just change a config option. Also, if you are careful enough you'd ship two fully optimized versions with just logging enabled in one of them. – mojuba Nov 5 '10 at 23:55

Team Viewer is nice for the informal, occasional support call without having to poke firewall holes etc. http://www.teamviewer.com/

A mechanism which can send you the latest logs in case of problems (either automatically when an exception happens, or manually when the user press a button) is really nice. This can be done as email, over Instant Messenger (like jabber or msn) or an upload site e.g. at Google Application Engine.

I do Java, and the single most important thing to get is the Exception stack trace from the point of failure, and the second most important to get the arguments passed on the way down in the stack trace (but that requires careful programming with try-catch around all methods).

  • We've had great success with team viewer. It works on any modern OS and it is very easy for the client to start / manage. – Tim Post Nov 6 '10 at 4:05

If they're running Windows, depending what you're looking for (when I deal with thick-client [desktop] applications) I generally have them send me system information which Microsoft makes super easy. This is only useful for getting the system information, client configurations, registry settings, et al.

Windows XP/Windows 7:

  1. Start > Run > msinfo32 (or msinfo32.exe)
  2. File > Save As (This will save it as a .nfo> so you can view it using the same viewer on your system) or File > Export (Text) which is not so easily readable

This allows you to take a lot of things into account that generally everyone forgets to mention (like environment variables).


The later versions of vnc have some options to correct many of the conflicts with excessive fancy render features.

On the other hand, I have not had to do that in a long time as I have been doing web development, so some good logging and an htmlfilter that can intercept the html sent to the client is usually all I need.


We use webex for this purpse; we start the meeting, make them presenter and then they can share the desktop. Haven't had any problems with it.

There was another program that a customer insisted on using one time that had lots of problems with "special" characters being typed - like slash. I want to say gotomeeting, but don't quote me on it.

  • Although Webex does do the job, I've found that it's very slow to get going and then nags you to sign up - even though you already have an account. – JBRWilkinson Nov 5 '10 at 23:50

I have developed my own diagnostic logic and form:

  1. Press CTRL-ALT-F12. This will open a diagnostic window containing the screenshot of the screen you were in, detailed log files, application state, computer info.

  2. If you have access to the internet, click on the "Send" button. The content of what you see will be sent to us directly

  3. If you don't have access to the internet, click save as and send us the file by email

If the above doesn't work, I use either TeamViewer (nothing to install and pass trought firewalls) or LogMeIn (must be installed, but works fine in controlled environment)

Not the answer you're looking for? Browse other questions tagged or ask your own question.