Visual Studio's Tacit Endorsement of MadLibs

Formatting strings can be a tricky job...

I'm sure there's a logical explanation, but still... It really {0} me off when {1} Visual Studio 2005 SP1 decided to throw this {2} my way.



Patch that Might Help with 0x8ddd0009 as well as high SVCHOST.EXE CPU Utilization?

In the past, I've written about both high CPU utilization by SVCHOST.EXE as well as the 0x8ddd0009 Windows Update / Microsoft Update error, so I thought I would mention this...

MS KB 932494 (When you use Automatic Updates to scan for updates or to apply updates to applications that use Windows Installer, you experience issues that involve the Svchost.exe process) references problems that are addressed by MS KB 916089 (FIX: When you run Windows Update to scan for updates that use Windows Installer, including Office updates, CPU utilization may reach 100 percent for prolonged periods) and MS KB 927891 (You receive an access violation when you try to install an update from Windows Update after you apply hotfix package 916089). However, even after applying the patch associated with 927891 (which replaces the patch associated with 916089), 932494 indicates that the following problems remain:

1) Certain 100 percent CPU issues are still present when you use the Svchost.exe process.
2) An access violation may occur in the Svchost.exe process.
I (as well as others) have speculated in the past that 916089 (and its succedent patches) can also help with the 0x8ddd0009 error message that one might receive from Windows Update / Microsoft Update.



Part 1: Introduction - What's using my CPU?

Recently, I have been involved in attempting to diagnose problems with excessive CPU utilization. Often times, this type of thing is relatively easy to identify - at least as far as pointing the finger at the thing that is consuming CPU cycles. Task Manager can be used for this - simply sort the "CPU" column in descending order and note the process that is at the top of the list. One can use a similar technique with Process Explorer.

In the past (here and here), I've given examples that demonstrate various techniques that can be used to try to determine what a process is doing when it is consuming so much CPU. Sometimes, you can do something about it - if you have the debugging symbols, perhaps there is something in the stack of the thread or threads in the process that is consuming the CPU that will lead you to some setting, feature, or configuration piece that can be manipulated so as to avoid the problem. Or perhaps just knowing the module name is enough information to identify the problem software - a recently installed add-in / plug-in, or a new utility, perhaps. Sometimes you are forced to work around the problem - you don't have any control over it and don't want to stop using the program, or have no choice but to keep using the program.

But what happens when the excessive CPU utilization is not attributable to a "standard" process? In the coming series of articles, I hope to explore some of the things that can be done to diagnose and troubleshoot this type of scenario. Stay tuned...



Seriously! The dog ate it!

I'll make this one brief...

Sorry for the lack of updates lately - I'm working on a number of other things and haven't found a lot of time to write. I have something kind of fun planned that may be a three or four parter but it will probably be a bit slow in coming. It will also be a learning experience for me, so that should be cool. I will post things as I finish them, but there may be revisions to the content when the later parts are posted. I hope to have the first one (introduction) up by the end of the coming weekend.

I appreciate your patience, understanding, and continued readership. Thank you.