I took over a case from my colleague Carlo the other day. Carlo has already blogged about it in some detail so I won't go over the detail again. We both spent quite a bit of time solving it so I tried to reflect afterward on why it took us the time it did and how we could have approached it differently.
Get to see the problem - you cannot beat seeing the problem demonstrated before your own eyes. If a picture is worth 1000 words then seeing the real thing in real time is worth 1000 pictures. Here at Microsoft support we use a home grown tool called EasyAssist which is a slimmed down version of Live Meeting. But there are lots of other remote desktop viewing tools available on the market (including Live Meeting itself) so there should be no reason to not see the problem for yourself. (Well, ok, the server could be in some bunker in Lapland disonnected from the rest of the world but Hey! I've heared Lapland is nice this time of year). In this case just seeing what was going on made the whole set up of the customer's systems easier to follow.
If the problem is hard, break it in two - if the chunk of toffee is too large to fit in your mouth all at once you break it in two, right? (my colleague in the UK will vouch for the fact I've been practising that one this week 🙂 ). So if you have a hard problem make sure you think about how you can sensibly break it in two. In this case the customer had a problem with remote managed debugging. What finally gave us in the break through in the end was to us the CorDbg managed debugger from the .NET 1.1 SDK to test whether managed debugging worked at all on the server - without having to install Visual Studio. [putting CorDbg on a machine is easy. you don't need to install the whole SDK, just copy cordbg.exe, msdis140.dll, msvcp71.dll and msvcr71.dll and place together in a handy directory. CorDbg is essentially a thin wrapper around the CLR debugging APIs and if that doesn't work you know something bad is up. To read more about CorDbg check out Mike Stall's blog.]
If the problem looks familar, don't assume it is - working in support, we often see the same problems crop up again and again. One of those is that in ASP.NET 1.1, strong named assemblies placed in the BIN folder spell trouble. I have seen no end of weird problems result from this and we don't support it. In this case the debugging problem only happened with certain assemblies and these happened to be strong named. Ahhah! So that must be the issue. So I worked through putting them in the GAC as well (no joy), trying a different key pair (no joy), new assembly, new key pair (no joy) and so on. In then end, on this occasion, the problem turned out to be nothing related to the fact it was strong named (even though it only seemed to happen with strong named assemblies).
Anyway, time to go debug something else...