"Works on my machine" - How to fix non-reproducible bugs?

Answer 1

unit testing

Answer 2

Its very complicated issue . I was thinking writing some procedure for this . I just made some procedure for this non-reproducible bug . it might be helpful

When the Bug accorded .. There are several factors it might to occur.

I am Sure all bugs are reproducible . I always keep eye for these kind of issues..

1. Get the System Information
2. what other process the customer did before that.
3. Time period it occurs . its rare or frequent
4. its next action happened after the issue ( its always same or different )
5. Find the factors for this bug ( as developer )
6. Find the exact position where this issue happened .
7. Find ALL THE SYSTEM Factors on that time
8. check all memory leaks or user error issue or wrong condition in code
9. List out all facotrs to may cause this issue.
10. How the each factors are affected this and wat are the data is holding those factors
11. Check memeory issues happened
12. check the customer have the current update code like yours
13. check all log from atleast 1 month and find any upnormal operation happened . keep on note

Answer 3

The easiest way is always to see the customer in action (assuming that its readily reproducible by the customer). Oftentimes, problems arise due to issues with the customer's computer environment, conflicts with other programs, etc - these are details which you will not be able to catch on your dev rig. So a site visit might be useful; but if that's not convenient, tools like RealVNC might help as well in letting you see the customer 'do their thing'.

(watching the customer in action also allows you to catch them out in any WTF moments that they might have)

Now, if the problem is intermittent, then things get somewhat more complicated. The best way to get around this problem would be to log useful information in places where you guess problems could occur and perhaps use a tool like Splunk to index the log files during analysis. A diagnostic build (i.e. with extra logging) might be useful in this case.

Answer 4

Extensive logging usually helps.

Answer 5

I'm just in the middle of implementing an automated error reporting system that sends back to me information (currently via email although you could use a webservice) from any exception encountered by the app.

That way I get (nearly) all the information that I would do if I was sitting in front of VS2008 and it really helps me to work out what the problem is.

The customers are also usually (sorta) impressed that I know about their problem as soon as they encounter it!

Also, if you use the Application.ThreadException error handler you can send back info on unexpected exceptions too!

Answer 6

We use all the methods you mention progressively starting with the easiest and proceeding to the harder.

However you forget that sometimes hardware is at fault. For example, memory could be malfunctioning and some computation-intensive code will behave strangely throwing exceptions with weird diagnostics. Of cource, it works on your machine, since you don't have faulty hardware.

Experience is needed to identify such errors and insist that customer tries to install the program on another machine or does hardware check. One thing that helps greatly is good error handling - when your code throws an exception it should provide details, not just indicate that something is bad. With good error indication it's easier to identify such suspicious issues related to faulty hardware.

Answer 7

One technique I've found useful is building an application with an integrated "diagnostic" mode (enabled by a command line switch when you launch the app). That certainly avoids the need to create custom builds with additional logging.

Otherwise, it sounds like what you're doing is as good an approach as any.

Answer 8

Copilot (assuming customer is somewhere cold and rainy :)

Answer 9

I don't have this problem very often, but if I did, I would use a screen sharing or recorded application to watch the user in action without having to go there (unless, as you said, it's warm and sunny and the company pays the trip).

Answer 10

I have recently been investigating such an issue myself. Over the course of my carrier I have learnt that, while computer systems may be complex, they are predictable so have faith that you can find the problem. My approach to these kinds of issues two fold:

1) Gather as much detailed information as possible from the customer about their failure and analyse it meticulously for patterns. Gather multiple sets of data for multiple failure occurrences to build up a clearer picture.

2) Try and reproduce the failure in house. Continue to make your system more and more similar to the customers system until you can reproduce it, the system is identical or it becomes impractical to make it more similar.

While doing this consider:

1)What differences exist between this system and other working systems.

2)What has recently changed in your product or the customers configuration that has caused the problem to start occurring.

Regards

Answer 11

The usual procedure for this is to expect something like this will happen and add a ton of logging information. Of course you don't enable it from the beginning, but only when this happens.

Usually customers don't like to have to install a new version or some diagnostic tools. It is not their job to do your debugging. And visiting a client for cases like these is rarely an option. You must involve the client as little as possible. Changing a switch and sending you a log file is OK - anything more than this is too much.

I like the alternative of thinking the problem at the bath. I will start from trying to find out the differences between my machine and the client's configuration.

Answer 12

Depending on the issue you could get WinDbg dumps, they normally give a pretty good idea of what is going on. We have diagnosed quite a few problems that weren't crashed from minidumps.

For .Net apps we also was Trace.Writeline then we can get the user to fire up DbgView and send us the output.

Answer 13

One of the attributes of good debuggers, I think is that they always have a lot of weapons in their toolkit. They never seem to get "stuck" for too long and there is always something else for them to try. Some of the things I've been known to do:

1. ask for memory dumps
2. install a remote debugger on a client machine
3. add tracing code to builds
4. add logging code for debugging purposes
5. add performance counters
6. add configuration parameters to various bits of suspicious code so I can turn on and off features
7. rewrite and refactor suspicious code
8. try to replicate the issue locally on a different OS or machine
9. use debugging tools such as application verifier
10. use 3rd party load generation tools
11. write simulation tools in-house for load generation when the above failed
12. use tools like Glowcode to analyse memory leaks and performance issues
13. reinstall the client machine from scratch
14. get registry dumps and apply them locally
15. use registry and file watcher tools

Eventually, I find the bug just gives up out of some kind of awe at my persistence. Or the client realises that it's probably a machine or client side install or configuration issue.

Answer 14

Just a short anecdote (hence 'community wiki'): Last week I thought it was a clever idea in a Django app to import the module pprint for pretty printing Python data only if DEBUG was True:

if settings.DEBUG:
    from pprint import pprint

Then I used here and there the pprint command as debugging statement:

pprint(somevar) # show somevar on the console

After finishing the work, I tested the app with setting DEBUG=False. You can guess what happened: The site broke with HTTP500 errors all over the place, and I did not know why, because there is no traceback if DEBUG is False. I was puzzled that the errors disappeared magically, if I switched back to debug mode.

It took me 1-2 hours of putting print statements all over the code to find that the code crashes at exactly the above pprint() line. Then it took me another half an hour to convince myself to stop banging my head on the table.

Now comes the moral of the story:

1. Not every thing that looks like a clever idea in the first view is such savvy in the end.

2. An important point to look at for debugging these errors are all configuration options and platform switches your code by itself makes. This can be quite a lot more than just some user preferences. Document good, if you make an assumption about the user's platform (e.g., if you test for Win/Mac/Linux only, will your code crash on BSD or Solaris?)

Cheers,

Answer 15

However tough a non-reproducible problem is - we can still have a structured and strategic approach to solve them - and I can say through experience that it requires out of box thinking in 50% of the cases. Generally speaking, one can categorize the problems into different types which helps to identify what tool to be used. For example if you have a non-reproducible application crash issue or a memory issue you can use profilers and nail down the issue caused in the particular functionality.

Also, one of the most important approach is inforamation rich logging. I also use a lot of enums to describe the state of the process depending on the scenario in question. for exampe, I used like Initiated, Triggered, Running, Waiting Repaired etc to describe the schedules states and saved them to DB at different stages.

Answer 16

I think one of the most important things is the ability to ask sensible questions around what the customer has reported... More often than not they're not mentioning something that they don't see as relevant, but is actually key.

Telepathy would also be useful...

Answer 17

As a software engineer doing webstuff (booking/shop/member systems etc) the most important thing for us is to get as much information from the customer as possible.

Going from

it's broke!

to

it's broke! & here are screenshots of every option I picked whilst generating this particular report

reduces the amount of time it takes us to reproduce and fix an issue no end.

It may be obvious, but it takes a fair amount of chasing to get this kind of information from our customers sometimes! But it's worth it just for those moments you find they're not actually doing what they say they are.

Answer 18

I had these problems also. My solution was to add lots of logging and give the customer a debug build with all the possible debug information. Then make sure dr Watson (it was on Windows NT) created a memory dump with enough information. After loading the memory dump in the debugger I could find out where and why it crashed.

EDIT: Oh, this obviously only works if the application terminates violently...

Answer 19

We've had good success using EurekaLog with it posting directly to FogBugz. This gets us a bug report containing a call stack, along with related system info (other processes running, memory, network details etc) and a screen shot. Occasionally customers enter further info too, which is helpful. It's certainly, in most cases, made it much easier and quicker to fix bugs.

Answer 20

Not mentioned yet, but "directed code review" is one good solution, especially if you didn't do a proper review (at least 1 hour per 100 lines of code) before release.

I have also seen impressive demos of AppSight Suite, which is basically an advanced environment monitoring and logging tool. It allows the customer to record what happens on his machine in an extensive but fairly compact log file which you can then replay.

Answer 21

As many have mentioned, extensive logging, and asking the client for the log files when something goes wrong. In addition, as I worked more with web apps, I'll also provide detailed, but succinct deployment documentation (e.g., deployment steps, environmental resources that need to be set up etc).

Here are common problems I've seen that lead to the types of problem you are describing:

1. Environment not set up properly (e.g., missing environment variables, data sources etc).
2. Application not fully deployed (e.g., database schema not deployed).
3. Difference in operating system configuration (default character encoding being the most common culprit for me).

Most of the time, these issues can be identified through the log content.

Answer 22

I think following the trail of the actions user took can lead us to the reasons of failure or selective failures. But most of the times users are at loss to precisely describe the interactions with the applications, the automatic screenshot taking (if it is desktop app. for .net app you can check Jeff's UnhandledExceptionHandler). Logging all the important action which change state of the objects can also help us in understanding it.

Answer 23

You can use tools like Microsoft SharedView or TeamViewer to connect to remote PC and inspect problem directly on site. Of course, you'll need cooperation with customer.