What do you do?
-
The problem with the last part of that advice is that the practice of "sacrificing" denotes the giving up of something of value :~
-
I'm only looking for general advice with this question, that's why I posted it in the lounge. Please accept my groveling apologies if this is not appropriate for the lounge. When your app is having mysterious crashes on the client's machine, and you cannot replicate them on your development machine, what on Earth is there to do about it? Assuming it's not an option to install Visual Studio onto the client machine, and the fact that the crashes are random and infrequent enough to make a remote debug session impractical, what strategy can be employed?
-------------------------------- "All that is necessary for the forces of evil to win in the world is for enough good men to do nothing" -- Edmund Burke
* Limit network connections (try one socket only) * Limit process threads (try with one, not with forty) * Limit multiprocessor execution (set affinity for cpu 0) * Run with your own DLLs, not customer's (already suggested) * Verify DLLS using Sysinternals ProcessExplorer * OutputDebugString printf's even from services * Use those minidumps * Assert with wild abandon * Divide and conquer - disable parts run the rest * Code review with trusted peer * Follow Robbins' advice in Debugging MS .NET 2.0 Applications That's what I do. :)
