User-Mode Debugging Internals

Alex Ionescu has posted some publications at his blog. I've only had an opportunity to go through the three-part series on Windows XP / 2003 User-Mode Debugging Internals, but I found them to be quite interesting and I hope to go through the rest of the publications which cover topics like Process Internals, VB File Format, NTFS ADS, and Subverting Windows 2003 SP1 Kernel Integrity Protection.

One thing (probably trivial) that I am curoius about in the User-Mode Debugging Internals papers is the analysis of NtDebugActiveProcess. Alex comments in his analysis in part 3 "Don't allow debugging the initial system process". The check for the initial system process is made, and STATUS_ACCESS_DENIED is returned if indeed it is the initial system process that is the subject of the debug attempt. I am curious as to why, prior to returning in this case, the process is not dereferenced (ObDereferenceObject(Process);)? Is it simply the nature of the system process that this is not required, though perhaps it might be considered good practice to call ObDereferenceObject(Process) in this case? Or is there some other reason?

Does anyone have any thoughts on the above?



The Joy of Tagging (or Labeling)

OK... I admit it. I'm jumping on the whole "tagging" thing (or as Blogger likes to call it, "Labels") a bit late. Shortly after converting to the "new" Blogger, I made a rather unconscious decision to ignore the field that allows for tagging new items. So there are many posts that were made with the new blogger that don't have tags. I plan on tagging a few at a time, but with 140+ posts, this could take a bit of time.



Part 2: Background - What's using my CPU?

Previously (Part 1: Introduction - What's using my CPU?), I kicked off what I expect to be a multi-part series on determining what is causing excessive CPU consumption, outside of the normal "which process has the highest value in the CPU column in Task Manager".

Before I get into things, a little bit of background may prove useful or mildly entertaining. Over on "Sysinternals Forums", there were recently two similar problems that both involved excessive CPU utilization that was not attributable to a specific process. I became involved in both problems and attempted to use similar techniques to get additional information with the hopes of ultimately being able to pinpoint the problem. What may make this mildly entertaining is that in both cases, there was limited or no success in detetmining the cause of or solution to the problem. In the end, one problem was resolved by disabling the floppy disk controller, and the other problem appears to be as of yet unresolved. (In the latter case, the poster did admit that the system was experiencing hardware problems - the chipset fan was dying and there were diagnostic beep codes during / after POST. These hardware problems could be related to the problem.) Despite the lack of success in determining the cause of the problems I do feel that I learned a bit about this type of problem and gained some insight into the use of some tools that can come in handy in this situation.

In the two cases, the problem consisted of the CPU spending a lot of time servicing interrupts and deferred procedure calls (DPCs). What are interrupts and DPCs? "Windows Internals, Chapter 3 - System Mechanisms" says:

Interrupts ... are operating system conditions that divert the processor to code outside the normal flow of control. An interrupt is an asynchronous event (one that can occur at any time) that is unrelated to what the processor is executing. Interrupts are generated primarily by I/O devices, processor clocks, or timers.
A deferred procedure call (DPC) is a function that performs a system task—a task that is less time-critical than the current one. The functions are called deferred because they might not execute immediately.
It is interesting to note that one may have a problem with excessive CPU use but may not be able determine it by using Windows' Task Manager. This is because for whatever reason, Task Manager adds time the CPU spends servicing interrupts and DPCs to the "System Idle Process". Microsoft's / Sysinternals' Process Explorer includes separate "artificial" processes for interrupts and DPCs so that one can see how much time the CPU spends dealing with each. Per Process Explorer's help file, "high CPU consumption by these activities can indicate a hardware problem or device driver bug".

Another thing that could be consuming CPU is the SYSTEM process. The process of determining what system thread is consuming the CPU is similar to determining what thread in a user-mode process is utilizing the CPU. However, excessive CPU utilization by the SYSTEM process might be a little more serious as it is an indication that some driver is possibly running rampant.

Next time, I plan to introduce some tools that can be useful in exploring DPC and interrupt activity on a system, as well as discussing how to determine what driver might be inolved with excessive CPU utilization in the SYSTEM process.