Partager via

Use Windows 2003 Server and remote desktops for debugging

  • Article

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

  • Anonymous
    August 14, 2005
    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.

  • Anonymous
    August 15, 2005
    The comment has been removed

  • Anonymous
    July 20, 2006
    It takes a lot of work to create the blog posts and code samples that I put in my blog, and I was curious...

  • Anonymous
    May 31, 2009
    PingBack from http://outdoorceilingfansite.info/story.php?id=5108

  • Anonymous
    May 31, 2009
    PingBack from http://outdoorceilingfansite.info/story.php?id=22744