CPU usage max'd out in ".NET SystemEvents" thread

A

Adam Benson

Hi,

We have an app which, every now and then, has very high CPU usage.
Profiling under perfmon shows it to be thread #3 which is running at >=95%.

I took a process dump and looked at thread #3 in WinDbg and it's a thread
called ".NET SystemEvents"
The stack trace looks like this :

0:003> !ClrStack -all

Thread 3

ESP EIP

ESP/REG Object Name

0x08a3fc6c 0x7b240ce2 [DEFAULT] [hasThis] Void
Microsoft.Win32.SystemEvents.WindowThreadProc()

EDI 0x08a3fcc8 ESI 0x00000001 EBX 0x00000000 EDX 0x0000000a ECX
0x00000000

EAX 0x00000000 EBP 0x08a3fcd8 ESP 0x08a3fc6c EIP 0x7b240ce2

ESP/REG Object Name

0x8a3fc78 0x652daf4 Microsoft.Win32.SystemEvents

0x8a3fd64 0x79b7d2c8 System.Array

0x8a3fd68 0x79b7d2c8 System.Array

0x8a3fe14 0x79b7d2c8 System.Array

0x8a3fe18 0x79b7d2c8 System.Array

0x08a3fed8 0x791da717 [FRAME: GCFrame]


and sometimes looks like this (I took a few snapshots) :

Thread 3

ESP EIP

0x08a3fc4c 0x01d9ac94 [FRAME: NDirectMethodFrameStandalone] [DEFAULT]
Boolean Microsoft.Win32.UnsafeNativeMethods.PeekMessage(ByRef ValueClass
MSG,ValueClass System.Runtime.InteropServices.HandleRef,I4,I4,I4)

ESP/REG Object Name

0x08a3fc64 0x7b240cdd [DEFAULT] [hasThis] Void
Microsoft.Win32.SystemEvents.WindowThreadProc()

EDI 0x08a3fcc8 ESI 0x00000001 EBX 0x00000000 EDX 0x00000008 ECX
0x00000000

EAX 0x00000000 EBP 0x08a3fcd8 ESP 0x08a3fc64 EIP 0x7b240cdd

ESP/REG Object Name

0x8a3fc78 0x652daf4 Microsoft.Win32.SystemEvents

0x8a3fd64 0x79b7d2c8 System.Array

0x8a3fd68 0x79b7d2c8 System.Array

0x8a3fe14 0x79b7d2c8 System.Array

0x8a3fe18 0x79b7d2c8 System.Array

0x08a3fed8 0x791da717 [FRAME: GCFrame]


Can anyone suggest what's going on? When the app is restarted it behaves
normally - i.e. consumes virtual 0% CPU.

TVMIA,

- Adam.

==============================
(e-mail address removed)
 
W

Willy Denoyette [MVP]

Adam Benson said:
Hi,

We have an app which, every now and then, has very high CPU usage.
Profiling under perfmon shows it to be thread #3 which is running at
=95%.
Click to expand...

I took a process dump and looked at thread #3 in WinDbg and it's a thread
called ".NET SystemEvents"
The stack trace looks like this :

0:003> !ClrStack -all

Thread 3

ESP EIP

ESP/REG Object Name

0x08a3fc6c 0x7b240ce2 [DEFAULT] [hasThis] Void
Microsoft.Win32.SystemEvents.WindowThreadProc()

EDI 0x08a3fcc8 ESI 0x00000001 EBX 0x00000000 EDX 0x0000000a ECX
0x00000000

EAX 0x00000000 EBP 0x08a3fcd8 ESP 0x08a3fc6c EIP 0x7b240ce2

ESP/REG Object Name

0x8a3fc78 0x652daf4 Microsoft.Win32.SystemEvents

0x8a3fd64 0x79b7d2c8 System.Array

0x8a3fd68 0x79b7d2c8 System.Array

0x8a3fe14 0x79b7d2c8 System.Array

0x8a3fe18 0x79b7d2c8 System.Array

0x08a3fed8 0x791da717 [FRAME: GCFrame]


and sometimes looks like this (I took a few snapshots) :

Thread 3

ESP EIP

0x08a3fc4c 0x01d9ac94 [FRAME: NDirectMethodFrameStandalone] [DEFAULT]
Boolean Microsoft.Win32.UnsafeNativeMethods.PeekMessage(ByRef ValueClass
MSG,ValueClass System.Runtime.InteropServices.HandleRef,I4,I4,I4)

ESP/REG Object Name

0x08a3fc64 0x7b240cdd [DEFAULT] [hasThis] Void
Microsoft.Win32.SystemEvents.WindowThreadProc()

EDI 0x08a3fcc8 ESI 0x00000001 EBX 0x00000000 EDX 0x00000008 ECX
0x00000000

EAX 0x00000000 EBP 0x08a3fcd8 ESP 0x08a3fc64 EIP 0x7b240cdd

ESP/REG Object Name

0x8a3fc78 0x652daf4 Microsoft.Win32.SystemEvents

0x8a3fd64 0x79b7d2c8 System.Array

0x8a3fd68 0x79b7d2c8 System.Array

0x8a3fe14 0x79b7d2c8 System.Array

0x8a3fe18 0x79b7d2c8 System.Array

0x08a3fed8 0x791da717 [FRAME: GCFrame]


Can anyone suggest what's going on? When the app is restarted it behaves
normally - i.e. consumes virtual 0% CPU.

TVMIA,

- Adam.

==============================
(e-mail address removed)
Click to expand...


It looks like you are creating/handling windows on another thread than the
main thread (thread 3). That could be because you are calling into COM on
this thread, or that you are creating Windows forms on this thread, or you
are calling DoEvents or ....
Anyway there is a message loop running in thread 3.
It's really hard to tell what's really happening here without some detailed
context or without seeing some code.

Willy.
 
A

Adam Benson

It's really hard to tell what's really happening here without some
detailed context or without seeing some code.
Click to expand...

Well in that thread none of our code is running, which is what was puzzling
me so much.

But your comments have given me a place to start looking - some of our
programmers, especially the juniors, are not that careful about only doing
UI work on the UI thread. I don't think there are any COM objects in that
particular app so I guess we'll have to comb it for windows, UI work outside
of thread 0. Sound like a reasonable plan of attack?

Thanks,

Adam.
==========
 
W

Willy Denoyette [MVP]

Adam Benson said:
Well in that thread none of our code is running, which is what was
puzzling me so much.

But your comments have given me a place to start looking - some of our
programmers, especially the juniors, are not that careful about only doing
UI work on the UI thread. I don't think there are any COM objects in that
particular app so I guess we'll have to comb it for windows, UI work
outside of thread 0. Sound like a reasonable plan of attack?

Thanks,

Adam.
==========
Click to expand...
I would not exclude COM, some components in the framework are just wrapping
some underlying COM components, I'm afraid this is the case here because the
thread seems to run an event handler for windows events.

Willy.
 
A

Adam Benson

I think we got it - started looking at where that thread came from.

It was created when the app's main form was created and the first textbox
was created.
The cause - our main method was missing the [STAThread] attribute.

Hopefully, this will fix the issue.

====
Adam.
 
Top