| T O P I C R E V I E W |
| alex.korban |
Posted - Jun 01 2007 : 12:14:29 AM
I'm using VS2003 with VAX build 1557, and it deadlocks after I do a Find in Files in the entire solution a few times.
I saw that you asked for call stacks in another post, so here it is for msenv.dll (which at the point of deadlock uses quite a lot of CPU time):
ntoskrnl.exe+0x584d
ntoskrnl.exe!KeQueryRuntimeThread+0x5e8
hal.dll+0x2ef2
hal.dll!KeRaiseIrqlToSynchLevel+0x6
ntoskrnl.exe!NtQueryInformationToken+0x140c
ntoskrnl.exe!ZwSetSystemInformation+0x23
ntdll.dll!KiFastSystemCallRet
kernel32.dll!Sleep+0xf
msenv.dll!VStudioTerm+0x59574
msenv.dll!VStudioMain+0x7fe11
And here is the call stack for devenv.exe:
ntoskrnl.exe!ZwAssignProcessToJobObject+0x15
ntoskrnl.exe!KeQueryRuntimeThread+0x5e8
ntoskrnl.exe!CcPurgeCacheSection+0x240
win32k.sys+0x2f70
win32k.sys+0x3776
win32k.sys+0x3793
ntdll.dll!KiFastSystemCallRet
msenv.dll!DllGetClassObject+0x1c490
MSO.DLL!Ordinal907+0x288
MSO.DLL!Ordinal121+0x7db
Regards
Alex |
| 20 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - May 05 2008 : 12:55:00 PM
Can you try upgrading to the latest version of VA and see if this makes any difference please?
http://www.wholetomato.com/downloads/default.asp
|
| n/a |
Posted - May 04 2008 : 09:22:18 AM
Hi,
I have Vista SP1, VS 2003 and Visual Assist 10.2.1444.0.
I have a same problem and I can't find solution for the VS2003 stuck.
It happens just when I find in files. |
| sean |
Posted - Jun 07 2007 : 01:49:04 AM
MigrateDevColor is just a public symbol that the callstack walker is using for reference. Since you don't have symbols for the va dlls, the stack walker is using that public symbol as a frame of reference - it would be better if it didn't and just put in a cumulative offset (rather than an offset from the last public symbol it could find).
Do you run with multiple instances of the IDE open?
You could try enabling logging. Maybe we'll see something in there.
http://docs.wholetomato.com?W305
(Delete any pre-existing logs if you try this.)
|
| alex.korban |
Posted - Jun 07 2007 : 01:08:51 AM
By the way, what does MigrateDevColor() do? I see it in the va_x.dll threads' call stacks every time there is a lockup, so I wonder if it's significant. |
| alex.korban |
Posted - Jun 07 2007 : 01:03:06 AM
Hi Sean
I normally have Output, VA Find References, Find Results 1 & 2 and VA View open, as well as Solution Explorer, Class View and Resource View. I have a bunch of other standard windows open when debugging - call stack, watch window etc.
I wouldn't say that it locks up more often during debugging.
Ctrl+Scroll Lock doesn't seem to help.
My solutions are C++ only. |
| sean |
Posted - Jun 07 2007 : 12:53:50 AM
Can you describe the window layout that you usually use?
The person in the other thread mentions that it usually happens during debugging. Anything like that true for you?
Were you able to try Ctrl+Scroll Lock?
Are your solutions single or mixed language?
|
| alex.korban |
Posted - Jun 06 2007 : 10:26:34 PM
Hi
Well, disabling Solution Build Environment didn't help either. Is there anything else I could try? |
| alex.korban |
Posted - Jun 06 2007 : 02:34:01 AM
Hi Sean
No, it wasn't trying to open the file it said it was stuck on. If the IDE got focus, it would access VAX files but that's about it.
I saw the Ctrl+Scroll Lock workaround in the other thread, but haven't tried it yet. I believe it's for a different issue though - I don't get a "No files to search in" message, the search is stuck in progress instead, and so I can't start another one. Ctrl + Break definitely doesn't stop it, but I can still save the files and restart the IDE.
I should mention that sometimes the whole IDE becomes unresponsive and the only thing I can do is kill the process. |
| sean |
Posted - Jun 06 2007 : 02:27:14 AM
Nothing in particular. I was wondering if there were repeated attempts to open a particular file - like it's stuck trying to open a file to do the search.
If it happens again, does pressing Ctrl+ScrollLock fix the hang?
( http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=180537 )
|
| alex.korban |
Posted - Jun 06 2007 : 02:04:48 AM
Hi
I uninstalled VSTabs, and that made no difference. I also had a look at file access during the last lockup (using FileMon), and didn't see anything suspicious. Is there anything in particular I should be looking for?
I disabled Solution Build Environment too, but haven't had any lockups yet, so I can't say whether it helped yet. |
| feline |
Posted - Jun 05 2007 : 07:50:03 AM
Are you in a position to uninstall, or disable, one or both of these other addin's, to see if this makes any difference?
I have never heard of VSTabs. It looks interesting, but should be safe to disable temporarily.
Solution Build Environment, I have the suspicion you may be depending on this for your build process, which would make disabling it rather more difficult.
|
| alex.korban |
Posted - Jun 04 2007 : 9:40:56 PM
Hi Sean
They seem to be independent of the solution, and all the files are on a local drive.
I'll give FileMon a try next time.
Regards
Alex. |
| sean |
Posted - Jun 04 2007 : 9:19:01 PM
Thanks for taking the time to report these details. Unfortunately, they don't get us any closer to a resolution.
Do the hangs happen in particular solutions and not others or are they solution independent?
Are any of the files in this particular solution located on networked drives?
The next time this happens, you might try firing up filemon (or procmon) and see if there is any suspect file activity.
|
| alex.korban |
Posted - Jun 04 2007 : 8:30:18 PM
Just got another deadlock, this time with VisualAssist mentioned in the call stack:
devenv.exe thread:
ntoskrnl.exe+0x584d
ntoskrnl.exe!KeQueryRuntimeThread+0x5e8
hal.dll+0x2ef2
hal.dll!KfLowerIrql+0x17
ntoskrnl.exe!NtQueryInformationToken+0x140c
ntoskrnl.exe!ZwSetSystemInformation+0x23
ntdll.dll!KiFastSystemCallRet
kernel32.dll!Sleep+0xf
msenv.dll!VStudioTerm+0x59574
msenv.dll!VStudioMain+0x36def
msenv.dll!VStudioMain+0x3715b
msenv.dll!VStudioMain+0x37092
msenv.dll!VStudioMain+0x3743a
VAssistNET.dll+0x13a0a
USER32.dll!GetDC+0x6d
USER32.dll!GetDC+0x14f
USER32.dll!DefWindowProcW+0x184
USER32.dll!DefWindowProcW+0x1d0
ntdll.dll!KiUserCallbackDispatcher+0x13
USER32.dll!SendMessageA+0x49
va_x.dll!MigrateDevColor+0x9925
msenv.dll thread:
ntoskrnl.exe!ZwCloseObjectAuditAlarm+0x45
hal.dll!KfLowerIrql+0x17
ntoskrnl.exe!NtQueryInformationToken+0x140c
ntoskrnl.exe!ZwSetSystemInformation+0x23
ntdll.dll!KiFastSystemCallRet
kernel32.dll!Sleep+0xf
msenv.dll!VStudioMain+0x51021
These two threads are consuming most of the CPU time.
There are also three va_x.dll threads stuck in GetModuleFileName():
ntoskrnl.exe!ZwAssignProcessToJobObject+0x15
ntoskrnl.exe!NtQueryInformationToken+0xb4e
ntoskrnl.exe!ZwSetSystemInformation+0x23
ntdll.dll!KiFastSystemCallRet
ntdll.dll!RtlEnterCriticalSection+0x46
va_x.dll!MigrateDevColor+0xeeb0d
va_x.dll+0x21dd2
kernel32.dll!GetModuleFileNameA+0x1b4
And besides that, there is a kernel32.dll thread doing this:
ntoskrnl.exe!ZwAssignProcessToJobObject+0x15
ntoskrnl.exe!KeQueryRuntimeThread+0x5e8
ntoskrnl.exe!CcPurgeCacheSection+0x240
ntoskrnl.exe!NtQueryInformationToken+0x140c
ntoskrnl.exe!ZwSetSystemInformation+0x23
ntdll.dll!KiFastSystemCallRet
kernel32.dll!Sleep+0xf
kernel32.dll!GetModuleFileNameA+0x1b4
And a msvb7.dll thread doing this:
ntoskrnl.exe!ZwAssignProcessToJobObject+0x15
ntoskrnl.exe!NtQueryInformationToken+0x16c6
ntoskrnl.exe!ZwSetSystemInformation+0x23
ntdll.dll!KiFastSystemCallRet
USER32.dll!GetLastInputInfo+0x105
USER32.dll!MsgWaitForMultipleObjects+0x1f
msvb7.dll!DllGetClassObject+0x39ea2
kernel32.dll!GetModuleFileNameA+0x1b4
And a mscorwks.dll thread doing this:
ntoskrnl.exe!ZwAssignProcessToJobObject+0x15
ntoskrnl.exe!NtQueryInformationToken+0x16c6
ntoskrnl.exe!ZwSetSystemInformation+0x23
ntdll.dll!KiFastSystemCallRet
USER32.dll!GetLastInputInfo+0x105
USER32.dll!MsgWaitForMultipleObjects+0x1f
msvb7.dll!DllGetClassObject+0x39ea2
kernel32.dll!GetModuleFileNameA+0x1b4
Here is the full list of threads:
Sorry about the long post, I hope this helps.
Regards
Alex. |
| alex.korban |
Posted - Jun 04 2007 : 5:38:17 PM
Hi
I'm pretty sure I've never encountered this issue before I started using VisualAssist, and even if it did happen, it was very rare. As far as I know it's specific to VS2003 and doesn't happen in VS2005, but I'm not certain because I don't use VS2005 much.
I'm using a standard theme on XP, no extensions.
I have two addins installed in VS2003:
- Solution Build Environment - support for custom environment variables (http://www.workspacewhiz.com/SolutionBuildEnvironmentReadme.html)
- VSTabs - provides a custom tab strip (http://www.zero-one-zero.com/vs/)
Regards
Alex. |
| sean |
Posted - Jun 04 2007 : 2:56:05 PM
I've seen a report or two on the net that don't mention VA. I've also seen a couple of documented cases where vs2003 will hang during Find In Files on Vista unless some sort of display compatibility switch is set.
Are any of you using theme extensions on XP? I've never experienced this problem. There must be some configuration element to this. |
| dodudo7 |
Posted - Jun 04 2007 : 2:12:27 PM
This does happen to me too, several times a week, but it's not something new with 1557, it happened also in the past.
IMHO, this is a VS2003 bug, I think (not sure) that I encountered it also on computers without VA. |
| feline |
Posted - Jun 04 2007 : 10:40:42 AM
That's bad. Do you have any other plugin's installed?
Any system utilities that might be hooking into the IDE, or effecting how it scans the hard drive?
I use Find in Files a certain amount, and I don't think it has ever caused me a problem. I am wondering if there is something odd about your system that is encouraging this problem. |
| alex.korban |
Posted - Jun 04 2007 : 05:31:06 AM
Hi
I see this problem very often, several times a day, but I can't see any pattern in what I do before the Find in Files that would cause the lockup.
Regards
Alex |
| feline |
Posted - Jun 01 2007 : 11:34:38 AM
Thank you! It is nice to get a call stack of this for a change. I have asked the developers if this offers any clues. I am not immediately seeing any sign of VAX in this stack, but this does not prove anything.
How often have you seen this problem? Several times a day, once a week, once a month?
case=6890 |
