Why I prefer debugging in a terminal server session

In my previous post concerning my copious amounts of applications that I normally have running I offhand mentioned “There are actually other reasons I TS into the same machine. Specifically, it makes debugging some things _much_ easier. I can go into more details if you’ like” to which i got a few responses back that people were actually interested in hearing about.  I’m sorry to say that it’s nothing too incredible or life shattering.  You won’t find debugging to be totally revolutionized, however, you might find it easier in a specific case.

In particular I’m referring to debugging events that happen based on UI interactions.  I’ll start with a small (contrived) example.  Sy I’m trying to debug the generate method stub function feature that we added for whidbey:

It starts by showing you a tickler:

Tickle me hellmo!

and then when you invoke the tickler (mouse or keyboard) you get:

Let there be light!

Now, say I’m trying to debug what’s going to happen when I click on that option.  I’ve got a few breakpoints set and I hover over the tickler.  The act of doing that causes one of the break points to get hit.  Ugh.  So I continue, but now the pop up never appeared.  This is because focus left the application and went to the debugger.  This is an example of a problem that you can have while debugging things that are related to application focus.  Say your application loses focus it commits or validates something (i.e. the item you just typed into a text box), but you don’t want that to happen because you’re debugging something else, then this can be incredibly useful.  In a TS session you can have an appliation have focus and changing focus in the main session won’t affect the focus in the TS session.

The second thing that’s helped out by having it be in a TS session is when you’re debugging and you don’t want paint calls to affect the debugging state.  If you have only one screen (Scary I know!) and your debugger overlaps the thing you’re debugging, then when you hit a breakpoint the debugger will pop up hiding some of the program.  When you switch back, those regions will have been invalidated and will be forced to redraw.  If those redraw commands cause state to change or code to execute, then you could hit anothe breakpoint and all in all the debugging experience sucks.  For example, in the C# editor redrawinf lines will call into our code colorizer, which will cause semantic analysis to occur, which can end up hitting a whole lot of code.  In a TS session windows from the main screen don’t invalidate windows in the session, so you won’t run into these problems.

So, if you’ve ever run into these issues and have been highly frustrated by them, I recommend switching to a TS based approach.  I use it for 100% of the debugging I do because it has these advantages with no drawbacks that I’ve ever seen.

Edit: YMMV.  It’s ideal for me, but may not be suitable for all debugging tasks.

Comments (8)

  1. Dr Pizza says:

    "I use it for 100% of the debugging I do because it has these advantages with no drawbacks that I’ve ever seen."

    It’s a bit slower and is not much cop for D3D or OGL debugging.

  2. Dr.Pizza: Gotcha. Edited main post.

  3. Eric Newton says:

    I assume you’re talking about debugging UI issues with Windows Forms apps?

    I cant see any reason to do this for asp and normal issues with Forms apps…

  4. neo says:

    you do debugging? I thought you use TDD and don’t need debugger. :p

  5. I don’t debug in C# or OCaml. But I do in C++. More related to the lack of test infrastructure with the current code base unfortunately 🙁

  6. Dr Pizza says:

    "I don’t debug in C# or OCaml."

    Maybe this is why you have problems with the idea of bug-free code.

    "using a debugger" is a subset of "debugging".

  7. AT says:

    RS232/Firewire/Network debugging using two PC is the only correct debugging.

    TS debugging has a lot of side effects. Even more – not all programs currently available on market works well in TS. For example Office 2000 require special installation transform patch to work with Windows 2000 Terminal services correctly. Why?


    TS are cool. But it does not solve all problems. I’ve regularly used two PC for debugging (and sometimes additional servers as work-load generators).

    Even for Java n-tier application!! Sounds like a non-sense, but it was really cool to find somebody store file in client PC temporary folder, transmit filename over network connection (EJB) and try to read file from same location on server. All of this is because of single-machine debugging 😉

    Do not rely on software too much if you can easily buy additional hardware.

  8. AT says:


    Even Microsoft Windows 2000 Terminal Server used the same trick with files.

    Clipboard was shared with Terminal Server and client PC.

    But if you copy file to clipboard on client PC you will be unable to paste it on server.

    Clipboard simply copied file location, not a file.

    Thanks God, Microsoft fixed this in Server 2003 and added \tsclient client disk sharing. My bug report was possibly one of bug reports that make this happen.

    Are single mashine debugging common in Microsoft ?