Remote debugging - when you are not all there
There are three common types of remote debugging that I plan to ramble on about.
The first is when you do a kernel debug using CDB or WinDbg of another system via a serial or parallel link. Essentially, you are making you nice shiny PC in to a dumb terminal. This is really the only way to do a live debug of a kernel mode problem using our technology. SoftIce seems to be able to do a lot more on a single box although I am sure that they must affect the system behaviour a little. It is still a very fine trick if you can do it. There are also bits of hardware that allow you to do some more debugging in Kernel mode that you would expect to do on a single machine but we don’t generally use any of those. We use 2 PCs and some electric string. It must work though as we have produced operating system after operating system this way.
The second is user mode remote debugging. You can do this in the Visual Studio IDE and you have to do it when debugging a live ASPX application. By the way, I would strongly recommend that you do your utmost to avoid ever having to debug anything on a live server. It isn’t much fun. The least fun bit of the process is when the system administrators get a little unhappy that you have stalled their line of business server for 4 hours while you stepped through a critical routine. In my experience, they get a little excitable at this point. Anyway, debugging remotely from the IDE is documented on https://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsdebug/html/vcurfprogramsdialogbox.asp among other places. It is pretty cool.
WinDbg and CDB can also do this of course though it is a command line operation as you would expect. Check out the .Server command. This is much more flexible as you can debug via pipes or TCP using security certificates if required. You also control the port that TCP uses which you will of course need to do if you are going through a firewall. You connect at the other end from the File| Connect to Remote Session menu option. We use this a great deal internally when we want a colleague to give us a second opinion.
The third is an approach which we use when the system is really remote. Often, a customer will report a behaviour that we can’t reproduce in house. This has become more and more common as systems have become more complex. When I started doing this job, the customer could typically send his application in on a floppy disk. A typical scenario now requires multiple high end systems including third party components such as Oracle databases or an AS400 server. It is a little tricky to fit one of those in to an envelope. Sometimes we travel to a customer’s site and look at a problem there but I personally try to avoid that because it generally causes upset when I show up with my knuckles dragging on the floor, drooling quietly. No matter how often I explain that I always look this way, they will insist on calling a doctor... or in some cases, a vet. Anyway, to avoid travelling and time in quarantine, we can remotely control your machine. This is not actually a new thing but it hasn’t been used as commonly as you might imagine in a support context. There were tools such as PC anywhere that allowed you to remotely control a PC via a modem but that required your customer to have that software and a modem – and at one time, that was pretty rare. Later on, services such as WebEx appeared and we used those with considerable success. We now have our own solution in the form of Microsoft Office Live Meeting. It might not immediately seem obvious that this is a debugging tool since it is designed for presentations. However, you can share your desktop if you want to – and that means that you can use the system of a willing participant half a world away. The prices might seem a little daunting though at $750 a month for a 10 seat license. It is not as black as all that though. There is a pay as you go option that costs 35 cents a minute per participant but you don’t get the application sharing with that so it isn’t any use for debugging.
So, is there a cheaper option? Actually, yes! How does free work for you? I have debugged over both Netmeeting and MSN messenger and not hit any problems at all. You might have to fiddle with UDP proxies but it can and does work. You can use the applications to reproduce a problem or run your debugger of choice. WinDbg is also free, naturally.
So, as the old WW2 posters used to say: “Is your journey really necessary?” I would strongly advise you to try some remote troubleshooting before you hop in a car or on a plane. It saves hours and a great deal of money.
For my next post, I will be bringing you exceptions... but hopefully not too many.
Signing off.
Mark