devenv.exe 98% cpu usage?? Unit Test Runner?

I've been running into a situation where devenv.exe takes 98% CPU usage until I shut it down in task manager (I've let it run for several minutes and it never seems to finish whatever it's doing).

I can't create exact steps to reproduce but it always seems to be related to Unit Test Runner. Particularly after I debug some unit tests and finish debugging. Recently it happened once when switching from all tests tab to failed tests tab in unit test runner.

Anyone else experiencing this problem?

Sam

16 comments
Comment actions Permalink

I just hit this myself yesterday, when loading a solution. This was using
the latest EAP build (253) for VS2005. I had to kill VS2005 with task
manager and restart. Things worked the second time.


"Samuel Neff" <no_reply@jetbrains.com> wrote in message
news:4179376.1151675015731.JavaMail.itn@is.intellij.net...

I've been running into a situation where devenv.exe takes 98% CPU usage
until I shut it down in task manager (I've let it run for several minutes
and it never seems to finish whatever it's doing).

>

I can't create exact steps to reproduce but it always seems to be related
to Unit Test Runner. Particularly after I debug some unit tests and
finish debugging. Recently it happened once when switching from all tests
tab to failed tests tab in unit test runner.

>

Anyone else experiencing this problem?

>

Sam



0
Comment actions Permalink

I tried using NUnit GUI instead of Unit Test Runner and the problem still happened, however it seems still related to unit tests as it only happens when I'm working on unit test classes.

It's happened about 8 times today.. very frustrating.

Sam

0
Comment actions Permalink

Hello,

could you please attach a managed debugger (preferrably DbgClr) to the hung
devenv.exe process and capture stack
traces of all managed threads? Thanks in advance.


Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

I tried using NUnit GUI instead of Unit Test Runner and the problem
still happened, however it seems still related to unit tests as it
only happens when I'm working on unit test classes.

It's happened about 8 times today.. very frustrating.

Sam



0
Comment actions Permalink

May not be related, but I was experiencing the same high CPU use and VS2005 locking up.

As per your request, I attached DbgClr and found that whilst JetBrains was in the "hung" thread, the culprit at the head of the call stack was DevExpress DXCore, which I had installed quite a long time ago.

Uninstalling DXCore has made this problem go away for me.

I guess they just don't play nice together anymore...

0
Comment actions Permalink

Hello James,

yes, we've heard about the problem running side-by-side ReSharper 2.0 and
CodeRush (and probably other DevExpress's VS extensions)
but have not investigated it yet. We'll do that in the nearest future though.


Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

May not be related, but I was experiencing the same high CPU use and
VS2005 locking up.

As per your request, I attached DbgClr and found that whilst JetBrains
was in the "hung" thread, the culprit at the head of the call stack
was DevExpress DXCore, which I had installed quite a long time ago.

Uninstalling DXCore has made this problem go away for me.

I guess they just don't play nice together anymore...



0
Comment actions Permalink

Hey James,

Can you post or email me that call stack? markm at dev express dot com

If you had an older version of DXCore, I'm betting the problem is already
fixed with a more recent release. However I would like to see the stack
anyway so I can make sure we don't have any conflicts with Resharper.

TIA.

Best regards,

Mark Miller - Developer Express


0
Comment actions Permalink

Here's the stack trace I'm getting. I tried several times and it's very consistent:


> jetbrains.vsaddin.dll!JetBrains.VSAddin.TextControl.VSTextControl.UpdateCommandFilter() Line 694 C#
jetbrains.vsaddin.dll!JetBrains.VSAddin.TextControl.VSTextControl.MyCommandFilter.Exec(ref System.Guid pguidCmdGroup = {System.Guid}, uint nCmdID = 684, uint nCmdexecopt = 0, System.IntPtr pvaIn = 0, System.IntPtr pvaOut = 1240264) Line 600 C#
system.windows.forms.dll!System.Windows.Forms.NativeWindow.DefWndProc(ref System.Windows.Forms.Message m) + 0xde bytes
system.windows.forms.dll!System.Windows.Forms.NativeWindow.WndProc(ref System.Windows.Forms.Message m) + 0x6 bytes
jetbrains.vsaddin.dll!JetBrains.ReSharper.Shell.VSIntegration.VSShell.MyMainWindow.WndProc(ref System.Windows.Forms.Message m = {System.Windows.Forms.Message}) Line 135 + 0xc bytes C#
system.windows.forms.dll!System.Windows.Forms.NativeWindow.Callback(System.IntPtr hWnd, int msg, System.IntPtr wparam, System.IntPtr lparam) + 0x30 bytes
system.windows.forms.dll!System.Windows.Forms.NativeWindow.DefWndProc(ref System.Windows.Forms.Message m) + 0x11e bytes
system.windows.forms.dll!System.Windows.Forms.NativeWindow.WndProc(ref System.Windows.Forms.Message m) + 0x6 bytes
jetbrains.resharper.commoncontrols.dll!JetBrains.ReSharper.CommonControls.WindowListener.WndProc(ref System.Windows.Forms.Message m) Line 37 C#
system.windows.forms.dll!System.Windows.Forms.NativeWindow.Callback(System.IntPtr hWnd, int msg, System.IntPtr wparam, System.IntPtr lparam) + 0x30 bytes


I'm still using build 249 but will update to 254 today. If that has any effect I'll repost here.

0
Comment actions Permalink

Try right-clicking on the call stack - Show External Code. You may find a whole lot more above the JetBrains call...

0
Comment actions Permalink

When I do that it just changes



to

0
Comment actions Permalink

Here's stack traces for other threads..


]]> thread:



> system.dll!System.Net.Sockets.Socket.ReceiveFrom(byte[] buffer, int offset, int size, System.Net.Sockets.SocketFlags socketFlags, ref System.Net.EndPoint remoteEP) + 0x14b bytes
system.dll!System.Net.Sockets.UdpClient.Receive(ref System.Net.IPEndPoint remoteEP) + 0x54 bytes
jetbrains.resharper.shell.dll!JetBrains.ReSharper.Shell.SocketManager.PortListenerThread.Run() Line 131 + 0xe bytes C#


CacheUpdate thread:


> system.dll!System.Net.Sockets.Socket.ReceiveFrom(byte[] buffer, int offset, int size, System.Net.Sockets.SocketFlags socketFlags, ref System.Net.EndPoint remoteEP) + 0x14b bytes
system.dll!System.Net.Sockets.UdpClient.Receive(ref System.Net.IPEndPoint remoteEP) + 0x54 bytes
jetbrains.resharper.shell.dll!JetBrains.ReSharper.Shell.SocketManager.PortListenerThread.Run() Line 131 + 0xe bytes C#


JetBrains.ReSharper.AnimatedBitmapPainter thread




> mscorlib.dll!System.Threading.WaitHandle.WaitOne() + 0x57 bytes
system.windows.forms.dll!System.Windows.Forms.Control.MarshaledInvoke(System.Windows.Forms.Control caller, System.Delegate method, object[] args, bool synchronous) + 0x364 bytes
system.windows.forms.dll!System.Windows.Forms.Control.Invoke(System.Delegate method, object[] args) + 0x21 bytes
system.windows.forms.dll!System.Windows.Forms.Control.Invoke(System.Delegate method) + 0xa bytes
jetbrains.resharper.unittestsupport.dll!JetBrains.ReSharper.UnitTestSupport.UI.AnimatedBitmapPainter.AnimatorThreadProc() Line 60 + 0x11 bytes C#

0
Comment actions Permalink

Hello Samuel,

it looks like an incarnation of a known issue we're currently investigating.
It happens only with
VS 2003 and has nothing to do with Unit Test Runner. We'll try to fix it
ASAP.


Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

Here's the stack trace I'm getting. I tried several times and it's
very consistent:


>> jetbrains.vsaddin.dll!JetBrains.VSAddin.TextControl.VSTextControl.Upd
>> ateCommandFilter() Line 694 C#
>>


jetbrains.vsaddin.dll!JetBrains.VSAddin.TextControl.VSTextControl.MyCo
mmandFilter.Exec(ref System.Guid pguidCmdGroup = {System.Guid}, uint
nCmdID = 684, uint nCmdexecopt = 0, System.IntPtr pvaIn = 0,
System.IntPtr pvaOut = 1240264) Line 600 C#

system.windows.forms.dll!System.Windows.Forms.NativeWindow.DefWndProc(
ref System.Windows.Forms.Message m) + 0xde bytes

system.windows.forms.dll!System.Windows.Forms.NativeWindow.WndProc(ref
System.Windows.Forms.Message m) + 0x6 bytes

jetbrains.vsaddin.dll!JetBrains.ReSharper.Shell.VSIntegration.VSShell.
MyMainWindow.WndProc(ref System.Windows.Forms.Message m =
{System.Windows.Forms.Message}) Line 135 + 0xc bytes C#

system.windows.forms.dll!System.Windows.Forms.NativeWindow.Callback(Sy
stem.IntPtr hWnd, int msg, System.IntPtr wparam, System.IntPtr lparam)
+ 0x30 bytes

system.windows.forms.dll!System.Windows.Forms.NativeWindow.DefWndProc(
ref System.Windows.Forms.Message m) + 0x11e bytes

system.windows.forms.dll!System.Windows.Forms.NativeWindow.WndProc(ref
System.Windows.Forms.Message m) + 0x6 bytes

jetbrains.resharper.commoncontrols.dll!JetBrains.ReSharper.CommonContr
ols.WindowListener.WndProc(ref System.Windows.Forms.Message m) Line 37
C#

system.windows.forms.dll!System.Windows.Forms.NativeWindow.Callback(Sy
stem.IntPtr hWnd, int msg, System.IntPtr wparam, System.IntPtr lparam)
+ 0x30 bytes
I'm still using build 249 but will update to 254 today. If that has
any effect I'll repost here.



0
Comment actions Permalink

In case this helps..

I installed 254 yesterday and the problem didn't happen all day after installing 254 (whereas previously it happened often). This morning I did get the same 98% CPU usage problem again with 254 (also after using Unit Test Runner, I know you said it's not related) but the stack trace was completely different now. The active thread when I hit pause is always:


> system.dll!System.Net.Sockets.Socket.ReceiveFrom(byte[] buffer, int offset, int size, System.Net.Sockets.SocketFlags socketFlags, ref System.Net.EndPoint remoteEP) + 0x14b bytes
system.dll!System.Net.Sockets.UdpClient.Receive(ref System.Net.IPEndPoint remoteEP) + 0x54 bytes
jetbrains.resharper.shell.dll!JetBrains.ReSharper.Shell.SocketManager.PortListenerThread.Run() Line 131 + 0xe bytes C#


The other running threads are the CacheUpdate and AnimatedBitmapPainter with what appears to be the same stack trace.

0
Comment actions Permalink

Hello Samuel,

the stack trace you posted last is from the ReSharper thread that checks
for license violation over the network
by looking for instances of ReSharper on different machines concurrently
running the same license. The real problem
is in the UI thread (normally the first one in the Threads window) which
I suspect is in the same UpdateCommandFilter
function.


Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

In case this helps..

I installed 254 yesterday and the problem didn't happen all day after
installing 254 (whereas previously it happened often). This morning I
did get the same 98% CPU usage problem again with 254 (also after
using Unit Test Runner, I know you said it's not related) but the
stack trace was completely different now. The active thread when I
hit pause is always:


>> system.dll!System.Net.Sockets.Socket.ReceiveFrom(byte[] buffer, int
>> offset, int size, System.Net.Sockets.SocketFlags socketFlags, ref
>> System.Net.EndPoint remoteEP) + 0x14b bytes
>>

system.dll!System.Net.Sockets.UdpClient.Receive(ref
System.Net.IPEndPoint remoteEP) + 0x54 bytes

jetbrains.resharper.shell.dll!JetBrains.ReSharper.Shell.SocketManager.
PortListenerThread.Run() Line 131 + 0xe bytes C#
The other running threads are the CacheUpdate and
AnimatedBitmapPainter with what appears to be the same stack trace.



0
Comment actions Permalink

Yes, perhaps I overlooked the UI thread. I just got the problem again and the thread is again the UpdateCommandFilter ui issue, same stack trace posted earlier.

0
Comment actions Permalink

For the first time I had this happen today when I hadn't run any unit tests. Same UpdateCommandFilter stack trace.

This occurs far less frequently with build 254 than with 249. Any news on when it will be fully fixed?

0
Comment actions Permalink

This sounds like a problem I reported to Tracker a long time ago, and still have. I've managed to avoid it by not changing tabs in the unit test runner.

For completeness, I'm using VS2003 and do not have any Developer Express stuff installed (as mentioned elsewhere in this thread).

0

Please sign in to leave a comment.