Microsoft.Win32.SystemEvents.WindowThreadProc eating CPU

[Guest]

Recently, we upgraded a .NET Windows client application to use the 1.1 Framework, along with some other changes.

If we minimize the application, and let it sit idle, after an hour, the CPU utilization jumps from 0% to 100%, and continues to consume 100% indefinitely. Using the Windows task manager and Visual Studio .NET, I was able to isolate the problem to the ".NET SystemEvents" thread of the application. The location is "Microsoft.Win32.SystemEvents.WindowThreadProc".

We tested the old version of the application (using the 1.0 Framework), and the problem did not occur. Since we made other changes, the version of the framework might or might not be related to the problem.

Any idea what could be causing this? I found a similar post in January that nobody appeared to respond to (copied below).

--Jay

========================

From: "Brian Savage" <[email protected]>
Sender: "Brian Savage" <[email protected]>
Subject: Help! Microsoft.Win32.SystemEvents.WindowThreadProc eating CPU
Date: Tue, 6 Jan 2004 17:39:55 -0800
Lines: 25
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Newsreader: Microsoft CDO for Windows 2000
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
thread-index: AcPUvycjLrXAc1mGSKaCNvdGrU/hIg==
Newsgroups: microsoft.public.dotnet.framework.windowsforms
NNTP-Posting-Host: tk2msftngxa09.phx.gbl 10.40.1.161


I have a windows forms application that occasionally eats
100% of the hosts system's CPU indefintely. If I break
execution and selectively freeze threads, the culprit
seems to be the thread named ".NET System Events".

That thread is in a tight loop within
SystemEvents.WindowThreadProc. I don't understand the
disassembly, but it appears to be stuck completely within
that method as I step through it.

As I understand it, that thread is responsible for
calling events when system properties change. I have
hooked none of these events in my code, and like I said
the thread appears to be looping entirely within the
WindowThreadProc method.

This happens most often when coming back from a Fast User
Switch in XP or resuming from a suspended/hibernated
state.

What is going on?? How can I work around this? It's
noticed by customers and makes us look bad.

-Brian

 

[Wiktor Zychla]

If we minimize the application, and let it sit idle, after an hour, the
CPU utilization


does your application use more than one thread?

 

[Guest]

Yes it does. However, when the user isn't doing anything, we aren't
spawning new ones. We have a timer that goes off every
five minutes which continues to operate independent of the
".NET System Events" thread after it starts consuming the CPU.

 

[Wiktor Zychla]

Yes it does. However, when the user isn't doing anything, we aren't

spawning new ones. We have a timer that goes off every
five minutes which continues to operate independent of the
".NET System Events" thread after it starts consuming the CPU.

Make sure that all threads safely update visual components (via Invoke when
..InvokeRequired). That often helps in multitread issues. I've noticed that
such problems tend to occur more often when the application is minimized for
a long time, however, I cannot explain it.

Regards,
Wiktor Zychla