Sunday, August 29, 2004 11:26 PM
by
jonathanh
Debugging SP2 on the Tablet PC - managed code, tabtip.exe, and procexp
If you've got a Tablet PC and you're running SP2 (and you should be!) you might have noticed a couple of processes hanging around called TabTip.exe and TCServer.exe. And right after noticing them, you probably wondered why they seemed to be taking up so much memory.
Luckily, autoruns is not the only cool tool from those fine folks at Sysinternals. They've also produced the must-have procexp: it's a better task manager than Task Manager, and is great for these kinds of "what the heck is that process doing" moments. In particular, you can tell procexp to use highlighting to call attention to services, jobs, your own processes, or (as in this case) .NET processes:

Yup, that's right, TCServer and TabTip are both written in managed code - after all, the Tablet PC edition of Windows XP was the first to ship with the .NET CLR, so why not use it? :-) Now we can use another neat feature of procexp: right-click on the TabTip process, bring up its property window, and scroll across to the .NET tab. Managed processes define many counters to keep track of their own performance, and procexp lets you see them all. Here are some of the .NET memory counters for that process:

Now we can see why TabTip seems to be taking up so much memory: even though it's got just 0.5 MB of heap data and 1.5 MB of total data, the CLR has reserved 32 MB of virtual memory for it, "just in case". For users accustomed to unmanaged apps that do their own memory management, this "greedy" memory behavior of the CLR can come as a surprise, but for garbage-collected applications it makes sense. After all, if the machine has sufficient memory, why bother spending the time to collect objects that are no longer used?
As the Windows world moves towards .NET, we'll probably have to spend a lot more time explaining this to customers. In the meantime, procexp is a great tool for looking into the guts of your .NET applications.
Update: AT caught a mistake, now fixed. Also, this diagram from Rico Mariani's excellent introductory article on "Garbage Collector Basics and Performance Hints" shows the difference between allocated, committed, and reserved space very nicely:
