Use Windows 2003 Server and remote desktops for debugging

When debugging a process, you are often examining the context of a process at a breakpoint. When done, you resume the suspended process. However, just the act of resuming causes various events to fire that may not have fired when not debugging. These include such things as timers (WM_TIME`R), Application activation/Deactivation (WM_ACTIVATE) and paint (WM_PAINT) messages, causing different application behavior than that being examined.


(In VFP, if you don’t want to debug timer events, change Tools->Options->Debug->Display Timer Events.)


Using Windows Server 2003 and remote desktop can help minimize this intrusiveness. I run W2k3 server on a Virtual PC. I like to use Alt-Tab to switch between applications, but once VPC is active, Alt-Tab switches between applications inside that VPC, and you can’t alt-tab to an application on the host machine.

W2k3 allows you to have 2 remote desktop sessions. I use one for running the debugger and one for the debuggee  usually on 2 separate side by side physical machines). The debugger is setup to Attach (for VS2003: Solution Properties->Configuration Properties->Debugging) so when I start debugging (F5) it attaches to the process running in the other remote desktop. When a breakpoint or resume occurs, no paint or activate/deactivate messages are sent or processed. With separate physical machines for each RD the debugger and the debugee are both always the active application, so they always have keyboard focus and no Activate/Deactivate messages interfere. Things like intellisense dropdowns stay visible.


I use a shortcut that starts Remote Desktop (save current settings to point to the right machine) so I can easily start a session. Sometimes I like to cut/paste from one machine to another. Simple: just close the RD on the other machine (Alt-space-C space), start the another  RDs on the machine with clipboard, paste whatever you want, then close the RD (don’t log off, just close) and open the RD on the other physical machine and you’re exactly where you were.


If you’re RD is not full-screen, then Alt-Tab cycles through host machine processes, including the RD. When in the RD, Alt-PgUp and Alt-PgDn do the same as Alt-Tab, Alt-Shift-Tab within the RD. Use ctrl-alt-break to go to full-screen.


Here’s another advantage to using VPC. On a normal machine, if you’re at a breakpoint and the debuggee has called OpenClipboard or has some other system resource locked, then some applications may not work properly until the breakpoint is resumed. Using VPC for the debuggee eliminates that problem.



Comments (5)

  1. Niclas Lindgren says:

    Why not just use the remote debugging features of visual studio, or whatever debugger you are using.

    Simply install the remote debugger in the VPC and connect to it from your host machine. A very good way to do kernel debugging too if you are not dependent on some specific hardware.

  2. Calvin_Hsia says:

    Yes, using remote debugging is useful. However I neglected to mention that I’m talking about using a particular installation of VS (which gets updated periodically) to debug that same version of VS, and the remote debugging components must exactly match that version. Rather than building or installing my own copies of VS (one local, one remote), I use a pre-built VPC that has that build of VS, and I only need to build the components I’m working on.

  3. It takes a lot of work to create the blog posts and code samples that I put in my blog, and I was curious…