[219] Complete VS2005 Hang After Screensaver
Hello,
I had opened a solution, done absolutely nothing (well, thinking about
the object model while scribbling on a piece of paper :-). In the
meantime, my screensaver (just blank screen) kicked in. I typed my
password, and found VS2005 completely dead. No minimize button, no '...
(Not Responding)' in the title, just plain no reaction. No cpu usage
either.
The CLR debugger gave me the following call stack:
> mscorlib.dll!System.Threading.Monitor.Wait(object obj, int
millisecondsTimeout, bool exitContext) + 0x14 bytes
JetBrains.ReSharper.Psi.dll!
JetBrains.ReSharper.Psi.Impl.Caches2.CacheUpdateThread.Run() Line 71 +
0x10 bytes C#
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context
(object state) + 0x3b bytes
mscorlib.dll!System.Threading.ExecutionContext.Run
(System.Threading.ExecutionContext executionContext,
System.Threading.ContextCallback callback, object state) + 0x81 bytes
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() + 0x40
bytes
This is from the thread with priority 'Below Normal', to which the
debugger jumped after 'Break All'. The main thread's stack was as
follows:
> mscorlib.dll!System.Threading.WaitHandle.WaitOne(long timeout,
bool exitContext) + 0x2e bytes
mscorlib.dll!System.Threading.WaitHandle.WaitOne(int
millisecondsTimeout, bool exitContext) + 0x23 bytes
System.Windows.Forms.dll!
System.Windows.Forms.Control.WaitForWaitHandle
(System.Threading.WaitHandle waitHandle =
{System.Threading.ManualResetEvent}) + 0xa1 bytes
System.Windows.Forms.dll!
System.Windows.Forms.Control.MarshaledInvoke
(System.Windows.Forms.Control caller, System.Delegate method, object[]
args, bool synchronous) + 0x36d bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.Invoke
(System.Delegate method, object[] args) + 0x48 bytes
System.Windows.Forms.dll!
System.Windows.Forms.WindowsFormsSynchronizationContext.Send
(System.Threading.SendOrPostCallback d, object state) + 0x61 bytes
System.dll!
Microsoft.Win32.SystemEvents.SystemEventInvokeInfo.Invoke(bool
checkFinalization = true, object[] args = ) + 0x68 bytes
System.dll!Microsoft.Win32.SystemEvents.RaiseEvent(bool
checkFinalization = true, object key = , object[] args =
) + 0x106 bytes
System.dll!Microsoft.Win32.SystemEvents.OnUserPreferenceChanged
(int msg, System.IntPtr wParam, System.IntPtr lParam) + 0x6f bytes
System.dll!Microsoft.Win32.SystemEvents.WindowProc(System.IntPtr
hWnd = 787598, int msg = 8218, System.IntPtr wParam = 47, System.IntPtr
lParam = 285677664) + 0x29d bytes
Hope somebody at JetBrains can read something from that.
Cheers,
Christian
Please sign in to leave a comment.
Hello Christian,
we've seen this problem here and are looking into it. At the first glance,
the problem with UI thread waiting infinitely (the second stack trace you
posted) in Control.MarshaledInvoke
doesn't seem to be related to ReSharper at all, although I may be wrong.
Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
>> mscorlib.dll!System.Threading.Monitor.Wait(object obj, int
>>
>> mscorlib.dll!System.Threading.WaitHandle.WaitOne(long timeout,
>>
Dear Dmitry,
Thanks!
Christian
A little update on this one:
It occurs even if I just leave VS for some time, working in other apps.
So this is quite, ahem, nasty ;)
CLR debugger stack trace follows:
> mscorlib.dll!System.Threading.Monitor.Wait(object obj, int
millisecondsTimeout, bool exitContext) + 0x14 bytes
JetBrains.ReSharper.Psi.dll!
JetBrains.ReSharper.Psi.Impl.Caches2.CacheUpdateThread.Run() Line 71 +
0x12 bytes C#
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context
(object state) + 0x3b bytes
mscorlib.dll!System.Threading.ExecutionContext.Run
(System.Threading.ExecutionContext executionContext,
System.Threading.ContextCallback callback, object state) + 0x81 bytes
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() + 0x40
bytes
Cheers,
Christian
Hello Christian,
please check other threads and post stack traces here. The stack trace you
posted is OK, the problem is in the UI thread being blocked
(thread named 'Main' in the threads window).
Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
>> mscorlib.dll!System.Threading.Monitor.Wait(object obj, int
>>
Dmitry,
I get the same issue as Christian. I tried copying the stack trace of thread 'Main' but VS would tell me something like 'there are no symbols loaded' and 'no source code can be displayed'. Any ideas?
Alexandre
Hello Alexandre,
please try to disable option 'Enable Just My Code' (Tools|Options|Debugging|General).
Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
Dmitry,
My bad. I will try that as soon as VS2005 locks up again.
Alexandre
Dmitry,
I tried disabling 'Just My Code', then, I restarted VS2005 and attached the hung process. I still get the same error. I attached a screenshot of what's happening.
Alexandre
Attachment(s):
vs2k5_hang.JPG
I think I should simply click on the 'Call Stack' tab when 'Main' is selected even though I get the 'no symbols loaded' on a double-click.
I should stop forgetting my head at home. :\
I'll do it next time. ;)
Alexandre
What you're doing should be enough to get the stack trace... Can you see
any stack traces for other threads?
Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
Hello Dmitry,
Here's another call stack I could retrieve besides the one with the ReSharper Cache Update:
> mscorlib.dll!System.Threading.WaitHandle.WaitOne(long timeout, bool exitContext) + 0x2e bytes
mscorlib.dll!System.Threading.WaitHandle.WaitOne(int millisecondsTimeout, bool exitContext) + 0x23 bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.WaitForWaitHandle(System.Threading.WaitHandle waitHandle = {System.Threading.ManualResetEvent}) + 0xa1 bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.MarshaledInvoke(System.Windows.Forms.Control caller, System.Delegate method, object[] args, bool synchronous) + 0x36d bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.Invoke(System.Delegate method, object[] args) + 0x48 bytes
System.Windows.Forms.dll!System.Windows.Forms.WindowsFormsSynchronizationContext.Send(System.Threading.SendOrPostCallback d, object state) + 0x61 bytes
System.dll!Microsoft.Win32.SystemEvents.SystemEventInvokeInfo.Invoke(bool checkFinalization = true, object[] args = ) + 0x68 bytes
System.dll!Microsoft.Win32.SystemEvents.RaiseEvent(bool checkFinalization = true, object key = , object[] args = ) + 0x106 bytes
System.dll!Microsoft.Win32.SystemEvents.OnUserPreferenceChanged(int msg, System.IntPtr wParam, System.IntPtr lParam) + 0x6f bytes
System.dll!Microsoft.Win32.SystemEvents.WindowProc(System.IntPtr hWnd = 1049642, int msg = 8218, System.IntPtr wParam = 31, System.IntPtr lParam = 292352896) + 0x29d bytes
Hello Alexandre,
that's indeed the problematic stack trace we've seen several time. We're
looking into it.
Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
>> mscorlib.dll!System.Threading.WaitHandle.WaitOne(long timeout, bool
>> exitContext) + 0x2e bytes
>>
I had been working with 219 for quite some time now without running into
this problem. But like all good things, it had to come to an end. I dont
know what I changed but I have this exact same issue and it happens every
5 to 10 minutes. I have to kill VS2005 and start over. I get the same call
stacks, see below. Let me know if there is anything else I can do to get
this resolved quickly. Thanks.
One -
> mscorlib.dll!System.Threading.WaitHandle.WaitOne(long timeout, bool exitContext)
+ 0x2e bytes
mscorlib.dll!System.Threading.WaitHandle.WaitOne(int millisecondsTimeout,
bool exitContext) + 0x23 bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.WaitForWaitHandle(System.Threading.WaitHandle
waitHandle = {System.Threading.ManualResetEvent}) + 0xa1 bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.MarshaledInvoke(System.Windows.Forms.Control
caller, System.Delegate method, object[] args, bool synchronous) + 0x36d
bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.Invoke(System.Delegate
method, object[] args) + 0x48 bytes
System.Windows.Forms.dll!System.Windows.Forms.WindowsFormsSynchronizationContext.Send(System.Threading.SendOrPostCallback
d, object state) + 0x61 bytes
System.dll!Microsoft.Win32.SystemEvents.SystemEventInvokeInfo.Invoke(bool
checkFinalization = true, object[] args = ) + 0x68 bytes
System.dll!Microsoft.Win32.SystemEvents.RaiseEvent(bool checkFinalization
= true, object key = , object[] args = ) + 0x106 bytes System.dll!Microsoft.Win32.SystemEvents.OnUserPreferenceChanged(int msg, System.IntPtr wParam, System.IntPtr lParam) + 0x6f bytes System.dll!Microsoft.Win32.SystemEvents.WindowProc(System.IntPtr hWnd = 4129708, int msg = 8218, System.IntPtr wParam = 0, System.IntPtr lParam = 178905128) + 0x29d bytes Two -
> mscorlib.dll!System.Threading.Monitor.Wait(object obj, int millisecondsTimeout, bool exitContext) + 0x14 bytes JetBrains.ReSharper.Psi.dll!JetBrains.ReSharper.Psi.Impl.Caches2.CacheUpdateThread.Run() Line 71 + 0x12 bytes C# mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context(object state) + 0x3b bytes mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x81 bytes mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() + 0x40 bytes > Hello Alexandre, > > that's indeed the problematic stack trace we've seen several time. > We're looking into it. > > Regards, > Dmitry Shaporenkov > JetBrains, Inc > http://www.jetbrains.com > "Develop with pleasure!" >> Hello Dmitry, >> >> Here's another call stack I could retrieve besides the one with the >> ReSharper Cache Update: >> >> >> >>> mscorlib.dll!System.Threading.WaitHandle.WaitOne(long timeout, bool >>> exitContext) + 0x2e bytes >>> >> mscorlib.dll!System.Threading.WaitHandle.WaitOne(int >> millisecondsTimeout, bool exitContext) + 0x23 bytes >> >> System.Windows.Forms.dll!System.Windows.Forms.Control.WaitForWaitHand >> l e(System.Threading.WaitHandle waitHandle = >> {System.Threading.ManualResetEvent}) + 0xa1 bytes >> >> System.Windows.Forms.dll!System.Windows.Forms.Control.MarshaledInvoke >> ( System.Windows.Forms.Control caller, System.Delegate method, >> object[] args, bool synchronous) + 0x36d bytes >> >> System.Windows.Forms.dll!System.Windows.Forms.Control.Invoke(System.D >> e legate method, object[] args) + 0x48 bytes >> >> System.Windows.Forms.dll!System.Windows.Forms.WindowsFormsSynchroniza >> t ionContext.Send(System.Threading.SendOrPostCallback d, object >> state) + 0x61 bytes >> >> System.dll!Microsoft.Win32.SystemEvents.SystemEventInvokeInfo.Invoke( >> b >> ool checkFinalization = true, object[] args = ) + >> 0x68 >> bytes >> System.dll!Microsoft.Win32.SystemEvents.RaiseEvent(bool >> checkFinalization = true, object key = , object[] args =
>> ) + 0x106 bytes
>> System.dll!Microsoft.Win32.SystemEvents.OnUserPreferenceChanged(int
>> msg, System.IntPtr wParam, System.IntPtr lParam) + 0x6f bytes
>> System.dll!Microsoft.Win32.SystemEvents.WindowProc(System.IntPtr
>> hWnd = 1049642, int msg = 8218, System.IntPtr wParam = 31,
>> System.IntPtr lParam = 292352896) + 0x29d bytes