tags:

views:

53

answers:

3

I'm stuck trying to debug a problem which only occurs on my machine. It doesn't exhibit on any of the other devs' systems, nor on our production test server. I've tried pretty much everything I can think of short of completely wiping my hard disk and starting from scratch, or sneaking into the office in the middle of the night to swap my computer with someone else's.

This brings to mind the titular question, then: short of those drastic measures, what do you do when trying to resolve issues that no one else has? I'm open to advice that's general or specific.

[Not sure if this should be CW or not.]

+3  A: 

Have you attached a debugger to the program to find the exact point of failure? That is what I would do first.

Sometimes third party software can be the root cause of these sorts of issues. Things like Anti-virus software install low-level filesystem and network drivers that can cause random intermittent failures. You can try killing all processes that aren't base OS services and your app.

Depending on your OS there are different tools that you can use to see what's going on under the covers. E.g. on Windows you can use Process Monitor to see what Registry keys it opens, what DLLs get loaded, etc. You can run this on your machine and on the success machines and compare to see if perhaps some required module is missing .

But seriously, use a debugger. That's what they are there for.

jeffamaphone
+1 on third party. I ran into a scenario one where only 1 user was having problems with an old web app. After some digging I found they had three browser toolbars installed, but only one visible. However, that didn't stop the other two toolbar's "pop up blocker" features from working and making things crazy.
Dillie-O
Yeah, IE toolbars typically have BHO components which get loaded unconditionally. If the app in question is a webbrowser plugin or webpage / webapp, you should restart IE in No-Addons mode (its buried in the Start menu) and just enable your app.
jeffamaphone
"Yes!" to attaching a debugger. I probably should have mentioned that "everything I can think of" includes using a debugger to step through the code. That's pretty much my first line of defense when things start going wrong.
Matt Ball
+1  A: 

In this situation, I would try to check out the code and cleanly rebuild it from a different directory to make sure that there are no miscellaneous files in your working directory that are causing a problem.

If you are doing work against a database, I would also try tearing down the database and reconstructing it, possibly using a dump from another developer's machine.

Check the versions of any external third party software - database version, OS version, even software patches.

Look at the configuration on someone else's machine who doesn't have the problem and compare.

Get another developer to sit at your workstation and try to reproduce the problem and also go to their workstation and try it. True story - a fellow developer had a bug that he could only reproduce on his machine...it turns out that he was doing something slightly different in the GUI that no one else was doing (tabbing to a button and then hitting enter, everyone else just hit enter). It never occurred to him that other people might just hit enter to submit, because that "didn't make sense" to him.

Ken Liu
+2  A: 

Two things:

I start with the obvious: What's different on your box? More memory? Odball PCI card? Different Microsoft APIs or service packs?

For oddball random software and/or OS crashes:

T.E.D.