CPU Racing w/ Idle App

[JD]

(longish message, but I appreciate ANY insight)

We have a .NET 1.1 Winforms application that recently started to exhibit
some odd behavior. Specifically, after sitting idle for a while (> 30
minutes), the user's CPU starts getting hammered. Here's some background
info:

First, it's a desktop app that connects to a SQL Server 2000 instance to
query some read-only data. Sometimes that SQL Server instance is on the same
machine (Personal Edition), while other times it's on a true server
(Standard Edition). We use a number of 3rd party components, including
DeveloperExpress for grids/trees, Syncfusion for menus/toolbars, and ChartFX
for charting. In some windows, the user sees a map which comes from
MapInfo's Mapx control (an ActiveX control we talk to via Interop).

The app itself uses a plugin architecture -- at startup, the app's framework
checks a components directory for assemblies. It them checks those
assemblies to see if they contain any plugins and, if so, enables them
within the application. In terms of the overall solution, the app has a very
small .exe that serves as a launch point (contains maybe 30 lines of code)
and then a number of class libraries that make up the app framework, common
UI elements, and so on.

The issue with the CPU racing has only recently been noticed, but we're not
sure if that's because it was recently introducts by a maintenance release
of some component (DevExpress, SyncFusion, and ChartFX have all been updated
within the last couple of months)... or if it's just that the "sitting idle
for a while" issue hasn't been the case before. FWIW, it's been reported on
WinXP Pro machines that are fully updated. These machines also recently got
upgrades to Office 2003.

At any rate, when it was last reported on an internal machine I used both
Performance Monitor Process Explorer (from sysinternals.com) to look at it.
Here's what I found:

1. The amount of memory used by the app doesn't change while the CPU is
hammered. In fact, minimizing the app reduces its footprint substantially
which seems to indicate that the GC runs just fine.
2. The I/O reads and writes aren't changing for the app while the CPU is
hammered. There's no disk activity.
3. The number of threads in use by the app doesn't change while the CPU is
hammered.
4. The number of exceptions thrown within the app doesn't change while the
CPU is hammered.

In other words, it doesn't appea the app is "doing" anything... in Process
Explorer, I was able to look at the individual threads and here's what I
saw:

(CPU %) - CSwitch Delta -- Start Address
-------------------------------------------------------------------
(95) - 133 -- mscorwks.dll!ReleaseFusionInterfaces+0x3fad9
(0) - 0 -- mscoree.dll!CorExeMain
(0) - 0 -- mscorwks.dll!CoInitializeCor+0x64a5
(0) - 0 -- mscorwks.dll!CoInitializeCor0x1780
(0) - 0 -- mscorwks.dll!ReleaseFusionInterfaces+0x44d93
(0) - 2 -- mscorwks.dll!ReleaseFusionInterfaces+0x447aa
(0) - 0 -- KERNEL32.dll!RegisterWaitForInputIdle+0x4a
(0) - 0 -- mscorwks.dll!ReleaseFusionInterfaces+0x43ae6

As you can see that first thread is the one that's running rampant.
Unfortunately, Google searches for "ReleaseFusionInterfaces" didn't turn up
anything. If I hightlight that first thread in Process Explorer, I get these
details about it:

ID: 1756
State: Ready
Kernel Time: 0:00:41.039
User Time: 0:29:47.900
Context Switches: 341,512
Base Priority: 8
Dynamic Priority: 8

At this point, I'm just hoping for a clue or some insight from someone who
knows more of the CLR guts than I do. I don't know where to look or what
other things I can do when it happens to find another clue.

Any ideas?

 

[fd123456]

Hi JD,

This might be a stupid suggestion, but you stated that you're using a
component from SyncFusion... Aren't ReleaseFusionInterfaces some sort
of interfaces for the release version of SyncFusion? Can you try to
launch your app without this component?

Michel

 

[JD]

Hi Michel,

First, thanks for the reply.

Second, I don't think that ReleaseFusionInterfaces is actually related to
the Syncfusion stuff. I could be wrong, but... The reason I say that is that
it's referenced through "mscorwks.dll", which is the .NET framework's "core"
assembly for workstation machines.

I also know that "Fusion" is the name given to the engine responsible for
loading and binding assemblies in an app domain. There's a tool in the .NET
SDK call "Fusion Log Viewer" (fuslogvw.exe) that lets you log and view the
details of assembly loading.

Anyway, thanks again for the reply!

JD

 

[russ]

When this happens, attach cordbg to the app. From process explorer figure
out the threadid, then load that thread in cordbg. Look at where it is
executing. You can stop/start the app several times and keep checking on
that thread to see where it is executing. That might give you some insight.

Or you can install the "remote" debugging tools on the workstation in
question. Go to visual studio and attach to the process on a remote machine.
Then you should be able to look at the Threads window in visual studio and
see exactly where the thread in question is executing. Set a breakpoint
inside that method, then hit F5. Now you can step through and see what is
going on.

-- russ