8

Some weird bugs occur in production with our home-made application written in C# with the framework 3.5. The application is logless (I know...) and the crashes don't give us usable information even in the event viewer. Further more, the error handling is poor when it exists.

Checkout the code and hunt the problem in a dev environment is not the solution as we don't know what the problem is.

We'd like to "debug" the application in the production environment. We're dreaming about something like using a tool with the feature of Visual Studio Debugger and ILSpy. That's, making step by step execution with deassembled code.

Well, what are the solutions when we don't have logs or error handling to debug an application in production?

ΩmegaMan
  • 29,542
  • 12
  • 100
  • 122
JiBéDoublevé
  • 4,124
  • 4
  • 36
  • 57
  • 3
    Adding logging to the very same version and re-deploying it isn't an option? – Marcel N. Jun 26 '12 at 14:03
  • What sort of application is it? ASP.NET, windows service, deployed desktop application, something else? – MNGwinn Jun 26 '12 at 14:04
  • 2
    As I remember Visual Studio can perform debugging on a remote machine - just start the debugging service on the PROD server, and deploy 'DEBUG' compiled code... Nasty enough, but more than nothing... – Tisho Jun 26 '12 at 14:04
  • 1
    @tisho: great feature, but when a debugger is attached and code is pause at a breakpoint, the application won't respond anymore. This can be considered as an interuption of service. – Steve B Jun 26 '12 at 14:06
  • Of course it is a nasty hack, as I said. But you can start a new instance(site, service), and to debug it separately. It is still on the remote server. The problem is if the problem occurs after a high load - you can't easily simulate a high load on a non-public instance.. Just ideas... – Tisho Jun 26 '12 at 14:09
  • Do you have debug symbol files for the exact version of the code deployed to production? – Chris Dickson Jun 26 '12 at 14:13
  • @JiBéDoublevé: A lot of folks are offering you advice here, but I don't see you responding to any of it. So what about the coon's question. Is it not possible to add a try/catch clause at the top level of the application in which you log the exception information and stack trace? Since it is in-house, you have the source code, right? Then why not deploy this slightly modified version that collects data for you while you do not have to watch it all the time? Putting it at the top level of the application, maybe around app.run(), you have one place where you mod code, so backing out is easy – philologon Jun 28 '12 at 16:39
  • To answer your questions: Redeploy the application is not an option (politic decision), change the code is not an option (politic decision). This is a winform application deployed without debug symbols. The application is deployed with ClickOnce. – JiBéDoublevé Jun 29 '12 at 08:57
  • http://stackoverflow.com/questions/3015429/what-is-the-procedure-for-debugging-a-production-only-error – 0lukasz0 Jun 27 '13 at 10:44

1 Answers1

10

See How to: Setup Remote Debugging

Edit: After seeing some of the responses to the main response, my suggestion continues with

  • Add more Try/Catch Blocks to the code.
  • Put in more check for null variables and lists
  • Put in more error handling. Do a divide and conquer strategy for this situation. Determine where the errors reside and start putting in error handling, logging and general plumbing to facilitate better code.

If you do those items the problem in question will be resolved; for you now have the tools to track down the error(s).

ΩmegaMan
  • 29,542
  • 12
  • 100
  • 122