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

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(By Ref 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.

==============================
Ad*********@Omnibus.NOSPAMMYSPAMSPAM.co.uk

detailed context or without seeing some code.

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

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.
==========