How can I log and retrieve error messages from a client-side desktop app?

Question

Update: The service-based answers below are most likely the way to go, I am also curious to see if there are any out-the-box solutions anyone has tried in the field.

---

Our system uses a client-server architecture, and with more clients using it I'm thinking of better ways to log client application errors, and get them sent to us.

Currently we just show a simple error message, with a button that preps an email (with the default system email client) and the clients send this on to our support address. This contains extra info like the stack trace.

We also tried saving errors to a network share in the company, but I'm not too keen on that archaic solution either.

Now there are only two businesses that refer to clients as users, and I'm sure some of ours support both lifestyles, as they just ignore the email button, and sends a full screen-shot wrapped nicely in a word document.

Some factors I'm thinking of include

• A solution to log errors, like the contrived one above,
• A robust solution; Logging to a SQL database won't work; if that fails too, then what?
• Is at least semi-automated, preferably to the point where the logs reach my side.
• It copes with load, our client base is growing and the current solution, and our inboxes, won't hold up.
• Minimise installing extra 3rd party components on clients, I want to keep the SPOF to a min.

I'd love to hear about any experience or suggestions you have on how I can implement such a solution.

System Details

It's a Microsoft .Net 2 based system with a SQL backend. Some users work remotely over the net, so network shares aren't always available (unless they VPN, which is awesomely slow at any rate). We have users across different companies, their DB's are hosted on-site. We have remote access to 90% of them.

Answer 1

At my last organisation, we had a similar window for when uncaught/unexpected exceptions occurred. It had a "send to support team" button which submitted an error report (including full exception details) to a web-service (our clients were spread over 200 locations with no access to the SQL database directly.)

That web-service then wrote the exception details to a database, as well as e-mailed the support team with the details and the report ID. It also linked the report to the part of the application that caused the exception - such as the customer account if the exception was thrown from a customer information screen.

If it was a problem that would have prevented either the transmission to the web-service, or the write to the database, the user received a message on-screen informing them to leave the message on-screen and contact the Support Desk.

If they did do (which did happen occasionally but not as much as we'd have liked) the support team could dial on to the PC (providing their network was up and running) using a VNC-like client, and press F12 on the dialog box to reveal the full exception details. They could then copy/paste that and e-mail it directly to us developers.

Of course if the network at the remote site had failed, they'd have much worse problems than the exception report not sending - they wouldn't be able to trade...!

Answer 2

Given this scenario, I would strongly consider the one thing your users probably have in common: port 80.

If you were to stand up a WCF service on a publicly accessible website, your application could take a snapshot of itself and push an encrypted bundle up to that service whenever there is an exception.