DebugInfo

When deciding whether to ask an outside expert to help with debugging a problem, one reason for initial hesitation is that the source code of the application might need to be sent out of the company's boundaries.

In reality, there is usually no need to worry about it, because, may be surprisingly, source code is rarely needed for effective debugging. In most cases in my practice, source code was not required to find the reason of the problem (such as application crash, hang, unexplained increase in memory usage, etc.).

There are usually only two cases when source code is really needed:

1) Logical error in the application, though it's very rare when I am asked to debug something like that, because in-house specialists usually know the application's logic much better and have no problems finding logical bugs, and also because the knowledge of the low level internals (like .NET runtime internals, Win32 internals, etc.) is rarely needed to resolve such cases.

2) A stubborn developer that refuses to accept that the bug is somewhere in FunctionX of the module he is responsible for. In this case, the source code of the file in question might be needed to actually point the finger to the exact source line and statement where the problem originates from.

And, of course, the source code of .NET applications can be analyzed with Reflector, which is often even better than looking at the real source code because the code produced by Reflector is usually very clean, and the real code is, well, not always that clean (though of course I had a chance to work with great teams that produced very clean and easy to read code).