Re: CPU Racing w/ Idle App
From: JD (jdonnici_at_yah-REMOVE-THIS-oo.com)
Date: 07/29/04
- Next message: Jon Skeet [C# MVP]: "Re: Is this kind of practice accepted"
- Previous message: Alvin Bruney [MVP]: "Re: Is this kind of practice accepted"
- Maybe in reply to: JD: "CPU Racing w/ Idle App"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 29 Jul 2004 10:12:38 -0600
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" <fd123456@hotmail.com> wrote in message
news:c8d02ef8.0407290047.22e84fe4@posting.google.com...
> 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" <jdonnici@yah-REMOVE-THIS-oo.com> wrote in message
news:<O59vyWCdEHA.3944@tk2msftngp13.phx.gbl>...
> > (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?
- Next message: Jon Skeet [C# MVP]: "Re: Is this kind of practice accepted"
- Previous message: Alvin Bruney [MVP]: "Re: Is this kind of practice accepted"
- Maybe in reply to: JD: "CPU Racing w/ Idle App"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
