(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?

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" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> (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?

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


"fd123456" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
news:<(E-Mail Removed)>...
> > (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?

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

"JD" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> (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?
>
>
>