Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Technical Support
 Hang when using Find In Files

You must be registered to post a reply.
Click here to register.

Screensize:
UserName:
Password:
Format: BoldItalicizeUnderlineStrikethrough Align leftCenterAlign right Insert horizontal ruleUpload and insert imageInsert hyperlinkInsert email addressInsert codeInsert quoted textInsert listInsert Emoji
   
Message:

Forum code is on.
Html is off.

 
Check to subscribe to this topic.
   

T O P I C    R E V I E W
Mindcrime Posted - Feb 19 2006 : 02:42:29 AM
VA_X.dll file version 10.2.1440.0 built 2006.01.17
Licensed to:
VA X: [email protected] (1-user license) Support ends 2007.01.11
VA.NET 7.1:
VAOpsWin.dll version 1.3.2.0
VATE.dll version 1.0.4.12
DevEnv.exe version 7.10.3077.0
msenv.dll version 2.0.2417.0
Font: Lucida Console 12(Pixels)
Comctl32.dll version 5.82.2900.2180
WindowsNT 5.1 Build 2600 Service Pack 2
4 processors

Platform: Win32
Stable Includes:
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\VC7\\ATLMFC\\INCLUDE;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\VC7\\INCLUDE;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\VC7\\PlatformSDK\\include\\prerelease;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\VC7\\PlatformSDK\\include;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\SDK\\v1.1\\include;

Library Includes:
c:\\program files\\microsoft visual studio .net 2003\\vc7\\atlmfc\\src\\mfc;
c:\\program files\\microsoft visual studio .net 2003\\vc7\\atlmfc\\src\\atl;
c:\\program files\\microsoft visual studio .net 2003\\vc7\\crt\\src;

Other Includes:

I don't have a 100% specific repro for this, but basically I noticed that when I do a FindInFiles operation and a "hit" exists in a file I have open, the search will hang and never complete. VS still runs OK otherwise, but I cannot do FindInFiles again. Also, if I attempt to close the file it found the "hit" in, VS will hang for good.
30   L A T E S T    R E P L I E S    (Newest First)
Uniwares Posted - Oct 02 2006 : 2:37:26 PM
Searching the internet for this topic reveals that there are some other people with the same problem, where VS locks up doing a find in files. And there are no references to VAX. So i guess it IS a VS problem. Although it seems to be related to add-ins in general.
jpizzi Posted - Oct 01 2006 : 12:12:50 AM
Maybe this is sufficient reason for you to get a new machine?

Let us know if you ever get a call stack or more information.

I just opened up 44 windows in VS2003, did a Find in files for both all open files and current solution (100 files). No hang. Even searched for "double" (this is an application that does significant floating point math; it found 1563 instances of the word).
pwc Posted - Sep 29 2006 : 2:16:50 PM
No, I tried again. The second instance of VS2003 just seems to hang (the break all button doesn't enable). I'll keep trying.

About the only additional information I have is that it seems to happen whenever I have a fair number of windows open, say 20+. I've seen it happen in both tabbed and MDI window mode. A coworker had the problem too, he got a new machine a few months ago and has not seen the problem since. Seems like it could be dependent on some saved state information somewhere. I have tried clearing all VAX files and deleting the ncb for my solution - no luck.
jpizzi Posted - Sep 27 2006 : 01:16:55 AM
Were you ever able to get a call stack? Kevin gave some pointers on how to get one.
pwc Posted - Sep 26 2006 : 6:19:06 PM
FYI, this just happened to me in 1535, so it appears to not be fixed.
thruska Posted - Aug 23 2006 : 01:09:55 AM
Oh! A Service Pack for VS.NET 2003? Didn't realize there was one. Thanks for the heads-up. You can copy the .pdb file into the symbols directory and VS should pick it up even though its not on the symbol server. Kind of a hacky workaround but that usually works.
kevinsikes Posted - Aug 22 2006 : 11:12:55 PM
Hi Thomas,

When attaching the debugger via Task Manager - Processes - Debug, VS would not load symbols, even with current symbols on the machine and _NT_SYMBOL_PATH set properly in the environment. Trying to load symbols manually causes the IDE to look for them in the same directory as devenv.exe. Since reading your post, I've had better luck launching another instance of VS, then going to Tools - Debug Processes. Then at least publicly available symbols get loaded. I still have to load msvcr71.pdb manually, but I wonder if this is a VS 2003 Service Pack 1 issue (a new msvcr71.dll and .pdb came with SP1, but it's not available on Microsoft's symbol server.)
Next time I have to grab a call stack, I'll make sure to use the latter method instead of Task Manager to attach to the hung devenv.exe process.
thruska Posted - Aug 22 2006 : 10:31:32 PM
Can someone turn on debugging symbols before posting the next call stack? Simply posting addresses is extremely useless. Or, better yet, follow these directions to create a minidump:

http://bill.atwill.com/docs/

Then upload the minidump somewhere and link to it here so support can handle it (they can simply load VS and plop the minidump in and figure out what is wrong very quickly). Make sure you identify the version of VS and VAX you are using. I've experienced this problem with previous versions (pre-VAX) but haven't run into it yet with the latest builds (I don't do nearly as much searching across projects these days).
kevinsikes Posted - Aug 22 2006 : 2:13:54 PM
Paul,

I haven't experienced the problem in some time. I've rolled back and forth between 1301 and the newest builds, and I've been on 1532 since it came out without a FIF hang. Upon attaching the new instance of VS 2003 debugger, make sure you hit the break execution (pause) button after the attach has finished, then you'll be able to get a call stack. The second IDE may look hung, but may not be: watch for the break execution button to light up, then press it.
pwc Posted - Aug 22 2006 : 2:04:50 PM
Sigh, it happened yet again. This bug is awful and is a huge impact on our productivity.

Same symptoms: Find in files hangs (CPU maxed) when it hits an open file (open in devenv). It seems to happen when I have a fair number of files open (say 20+). The devenv remains somewhat responsive until I activate the window of the file it is hung on, then the whole devenv is unresponsive.

How do you obtain a call stack? I rt-clicked the hung devenv.exe in the task manager and clicked 'debug' with VS 2003. This brings up an new instance of VS and a dialog asking which to debug (native and managed). I click OK, and the new instance of VS is hung too (at least I finally killed it after 10 minutes of no activity (CPU went idle too). This happens every time I attempt to get a call stack.

-Paul
kevinsikes Posted - Aug 07 2006 : 10:44:21 AM
This happened again at an inopportune time. I've rolled back to 1301 for now. I'll beat up on Find in Files to see if it happens again, but my suspicion is it's related to later VA X builds.
kevinsikes Posted - Aug 02 2006 : 3:41:29 PM
I had another spin lock using FIF, this time while in break mode in the debugger. CPU usage is 87-90%. This is after rolling back the Perforce client (the QT dll does not appear in the call stack anyway.) I wonder if this problem is due to my hyperthreaded CPU - perhaps some race condition is created during a FIF operation?

> kernel32.dll!7c8023be()
kernel32.dll!7c8399f3()
kernel32.dll!7c802451()
msenv.dll!5019301a()
msenv.dll!500aec87()
msenv.dll!5004a747()
msenv.dll!50014022()
vsdebug.dll!518e3c12()
vsdebug.dll!518e4c44()
vsdebug.dll!518e65ac()
vsdebug.dll!518e3566()
vsdebug.dll!518e34c6()
vsdebug.dll!518e747a()
sdm2.dll!518a4835()
rpcrt4.dll!77e79dc9()
rpcrt4.dll!77ef321a()
msenv.dll!5004a9ad()
msenv.dll!5004abd2()
msenv.dll!500b34ee()
VAssistNET.dll!012641a3()
VAssistNET.dll!01251474()
VAssistNET.dll!012516dc()
VAssistNET.dll!01252707()
ntdll.dll!7c91056d()
VAssistNET.dll!012640ca()
VAssistNET.dll!01252b6b()
VAssistNET.dll!01262e28()
ntdll.dll!7c910732()
ntdll.dll!7c9106ab()
ntdll.dll!7c9106eb()
usp10.dll!74dc4f18()
usp10.dll!74da324c()
user32.dll!77d48b26()
user32.dll!77d49488()
user32.dll!77d49491()
user32.dll!77d49491()
vsdebug.dll!518e96ac()
rpcrt4.dll!77ef3bf3()
msenv.dll!5009e801()
user32.dll!77d48bd9()
ole32.dll!77600c31()
ole32.dll!77600bdb()
VA_X.dll!1ee6360e()
ole32.dll!7750f237()
user32.dll!77d5f685()
VA_X.dll!1ed8db12()
user32.dll!77d5f685()
VA_X.dll!1ed1d3c6()
VA_X.dll!1ee653ab()
VA_X.dll!1ee89e4d()
ole32.dll!7750f15c()
ole32.dll!7750fc79()
ole32.dll!77600e3b()
ole32.dll!776009bc()
ole32.dll!77600df2()
ole32.dll!7750fcb3()
ole32.dll!7750fae9()
ole32.dll!7750fa56()
user32.dll!77d48734()
ole32.dll!7750fa56()
ole32.dll!7750fa56()
user32.dll!77d48816()
ole32.dll!7750fa56()
user32.dll!77d489cd()
ole32.dll!7750fa56()
user32.dll!77d4c96c()
user32.dll!77d48a10()
VA_X.dll!1ed172c2()
user32.dll!77d4c96c()
msenv.dll!500c9b9d()
MSO.DLL!30ce950f()
MSO.DLL!30ce9467()
msenv.dll!500c9bd4()
msenv.dll!500e12e0()
ntdll.dll!7c919aeb()
ntdll.dll!7c919ba0()
kernel32.dll!7c80ac66()
kernel32.dll!7c80ac78()
devenv.exe!004088a8()
devenv.exe!00406ed7()
devenv.exe!00410032()
ntdll.dll!7c910895()
ntdll.dll!7c919a9c()
ntdll.dll!7c919b3f()
ntdll.dll!7c919aeb()
advapi32.dll!77dd6a18()
ntdll.dll!7c919aeb()
ntdll.dll!7c919ba0()
kernel32.dll!7c80ac66()
kernel32.dll!7c80ac78()
devenv.exe!004055a1()
devenv.exe!004055c2()
devenv.exe!004055d8()
devenv.exe!004077bc()
devenv.exe!0040780e()
kernel32.dll!7c816d4f()
kernel32.dll!7c8399f3()

VA_X.dll file version 10.3.1530.0 built 2006.07.08
VAOpsWin.dll version 1.3.3.4
VATE.dll version 1.0.5.7
DevEnv.exe version 7.10.3077.0
msenv.dll version 7.10.3077.0
Font: Bitstream Vera Sans Mono 15(Pixels)
Comctl32.dll version 5.82.2900.2180
Windows XP 5.1 Build 2600 Service Pack 2
2 processors

Platform: Win32
Stable Includes:
d:\\compiler\\sdkfeb03\\include;
d:\\compiler\\DX9\\Include;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\include;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\atlmfc\\include;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\PlatformSDK\\include\\prerelease;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\PlatformSDK\\include;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\SDK\\v1.1\\include;
d:\\compiler\\ntddk\\inc;
d:\\compiler\\mp3;
d:\\compiler\\qdesign;
d:\\compiler\\wmsdk\\wmfsdk9\\include;
d:\\compiler\\sentinel;
d:\\compiler\\id3lib-3.8.3\\include;

Library Includes:
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\atlmfc\\src\\mfc;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\atlmfc\\src\\atl;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\crt\\src;

Other Includes:


kevinsikes Posted - Aug 01 2006 : 09:49:49 AM
I rolled back to 2005.2 and experienced the hang once, then left for vacation shortly after doing so, so I don't have any hard numbers to share with the group as to whether rolling back made a big difference. I'll let you know if I experience any more FIF hangs this week.
pwc Posted - Aug 01 2006 : 12:33:33 AM
No Perforce installed.

I've never seen this problem until I started using VAX.

I'll grab a call stack the next time it happens.

support Posted - Jul 31 2006 : 9:07:42 PM
Another note: We find many reports of hangs with "Find in Files" on the net. It seems it's a problem for those [few] users out there without VA X.

We'll wait for replies from pwc and kevinsikes and go from there.
support Posted - Jul 31 2006 : 8:56:52 PM
kevinsikes:
While VA X does not wait for "Find in Files" nor do anything when it's run, perhaps a checkout of a file triggers something that effects us.

We run the build of Perforce you were running prior to upgrading to Perforce 2006.1.

Can you roll back to 2005.2 and tell us what happens?
support Posted - Jul 31 2006 : 8:56:05 PM
pwc:
Can you install build 1446 or 1530 of VA X?

Do you have Perforce installed?

Can you post a call stack?
pwc Posted - Jul 31 2006 : 09:32:42 AM
I have "Fast Solution Build" and "Project Line Counter" add-ins installed, but this problem has happended before their installation.

I searched for 'qt-mt3*.dll' - none found.

I'll try getting a call stack the next time it happens.

Dean Ashton Posted - Jul 31 2006 : 03:03:43 AM
Even though Perforce uses QT, I'm tempted to think that the callstack is bogus. QT doesn't hook into the OS quite so tightly as to explain why - from the dump above - VAX is calling it, and even how ntdll.dll is calling VAssistNET.dll.

Dean
rhummer Posted - Jul 29 2006 : 2:19:41 PM
Perforce uses QT for it's interface. So I presume thats wher teh qt stuff is coming from.
feline Posted - Jul 29 2006 : 2:08:12 PM
pwc do you have any other plugin's installed?
can you search your machine for any files called "qt-mt3*.dll" ? the Qt dll could be a factor for kevinsikes so if you also have a version of this dll it will suggest a common cause for the crashes.
pwc Posted - Jul 26 2006 : 7:10:39 PM
Several of us at our company have experienced this problem as well (find in files run from with IDE, dev env hangs when it hits an open file). msenv.dll version is 7.10.3077.0. We have have to kill the devenv to escape - quite disruptive.

VA_X.dll file version 10.2.1440.0 built 2006.01.17
Licensed to:
VA.NET 7.1:
VAOpsWin.dll version 1.3.2.0
VATE.dll version 1.0.4.12
DevEnv.exe version 7.10.3077.0
msenv.dll version 7.10.3077.0
Font: Courier New 13(Pixels)
Comctl32.dll version 5.82.2900.2180
WindowsNT 5.1 Build 2600 Service Pack 2
Single processor

Platform: Custom
Stable Includes:
c:\\program files\\microsoft visual studio .net 2003\\vc7\\include;
c:\\program files\\microsoft visual studio .net 2003\\vc7\\atlmfc\\include;
c:\\program files\\microsoft visual studio .net 2003\\vc7\\PlatformSDK\\include\\prerelease;
c:\\program files\\microsoft visual studio .net 2003\\vc7\\PlatformSDK\\include;
c:\\program files\\microsoft visual studio .net 2003\\sdk\\v1.1\\include;
C:\\dev\\MWOffice\\OwlNext\\include\\owl;
C:\\dev\\MWOffice\\WTL\\Include;
C:\\dev\\OwlNext\\source\\owlcore;

Library Includes:
c:\\program files\\microsoft visual studio .net 2003\\vc7\\atlmfc\\src\\mfc;
c:\\program files\\microsoft visual studio .net 2003\\vc7\\atlmfc\\src\\atl;
c:\\program files\\microsoft visual studio .net 2003\\vc7\\crt\\src;
C:\\dev\\OwlNext\\source\\owlcore;

Other Includes:

kevinsikes Posted - Jul 20 2006 : 10:36:48 AM
Very interesting. I use Perforce source control integration with Visual Studio, and I recently upgraded to Perforce client tools 2006.1, which installed qt-mt336.dll. (The previous version was qt-mt335.dll with Perforce 2005.2) I will roll my Perforce client software back to 2005.2 to see if it eliminates the spin lock. Thanks, Joe!
jpizzi Posted - Jul 20 2006 : 02:10:30 AM
Just glancing through the callstack, I notice QT 3.3.6. Have you had this installed for a while, or is it possible that the change in behavior is from that change instead of the change to VA 1530?

Just asking....
kevinsikes Posted - Jul 19 2006 : 2:40:07 PM
Here's the call stack. See previous post for VAX and VS DLL versions.
Symptom: CPU is spinning at 88% for DevEnv.exe during Find in Files and must be killed with task manager.

> kernel32.dll!7c8024e6()
kernel32.dll!7c8399f3()
kernel32.dll!7c8023a8()
kernel32.dll!7c802451()
msenv.dll!5019301a()
msenv.dll!5003a699()
msenv.dll!50019e27()
msenv.dll!5001a07e()
msenv.dll!5001a0dd()
msenv.dll!5001a5f2()
VAssistNET.dll!012638ea()
ntdll.dll!7c910732()
ntdll.dll!7c9106ab()
ntdll.dll!7c9106eb()
VAssistNET.dll!01252b6b()
VAssistNET.dll!012626ba()
ntdll.dll!7c9105c8()
ntdll.dll!7c910551()
ntdll.dll!7c91056d()
user32.dll!77d48734()
user32.dll!77d48816()
user32.dll!77d4b89b()
user32.dll!77d5f3e3()
user32.dll!77d5f39a()
VA_X.dll!1ed8ed11()
VA_X.dll!1ed8e2fa()
VA_X.dll!1ed8e8be()
VA_X.dll!1ed29d56()
user32.dll!77d4b3a7()
user32.dll!77d4c331()
user32.dll!77d608be()
msenv.dll!500b112d()
msenv.dll!500b114e()
user32.dll!77d60826()
msenv.dll!500c41d7()
msenv.dll!500c41e2()
ntdll.dll!7c9105c8()
ntdll.dll!7c9105c8()
ntdll.dll!7c910551()
ntdll.dll!7c91056d()
user32.dll!77d48bd9()
user32.dll!77d4885a()
user32.dll!77d4882a()
kernel32.dll!7c80262a()
kernel32.dll!7c802600()
kernel32.dll!7c809737()
kernel32.dll!7c802600()
kernel32.dll!7c8399f3()
kernel32.dll!7c802600()
kernel32.dll!7c802542()
ntdll.dll!7c90e2f1()
kernel32.dll!7c8024b7()
qt-mt336.dll!39ea81a9()
qt-mt336.dll!39ea82d9()
qt-mt336.dll!39ea899f()
kernel32.dll!7c8024b7()
qt-mt336.dll!39ea81a9()
qt-mt336.dll!39ea899f()
VA_X.dll!1ee656a2()
qt-mt336.dll!39d50217()
qt-mt336.dll!39d4cbd8()
qt-mt336.dll!39d01046()
qt-mt336.dll!39d50f82()
qt-mt336.dll!39d30b0a()
qt-mt336.dll!39eb7336()
VA_X.dll!1ee61f19()
VA_X.dll!1ed24322()
VA_X.dll!1ee63ed0()
VA_X.dll!1ee63f60()
user32.dll!77d48734()
user32.dll!77d48816()
user32.dll!77d489cd()
user32.dll!77d4c96c()
user32.dll!77d496c7()
VA_X.dll!1ed173b2()
user32.dll!77d4c96c()
msenv.dll!500c9b9d()
MSO.DLL!30ce950f()
MSO.DLL!30ce9467()
msenv.dll!500c9bd4()
msenv.dll!500e12e0()
ntdll.dll!7c919aeb()
ntdll.dll!7c919ba0()
kernel32.dll!7c80ac66()
kernel32.dll!7c80ac78()
devenv.exe!004088a8()
devenv.exe!00406ed7()
devenv.exe!00410032()
ntdll.dll!7c910895()
ntdll.dll!7c919a9c()
ntdll.dll!7c919b3f()
ntdll.dll!7c919aeb()
advapi32.dll!77dd6a18()
ntdll.dll!7c919aeb()
ntdll.dll!7c919ba0()
kernel32.dll!7c80ac66()
kernel32.dll!7c80ac78()
devenv.exe!004055a1()
devenv.exe!004055c2()
devenv.exe!004055d8()
devenv.exe!004077bc()
devenv.exe!0040780e()
kernel32.dll!7c816d4f()
kernel32.dll!7c8399f3()
kevinsikes Posted - Jul 17 2006 : 9:18:54 PM
I never had the Find in Files problem before the 15xx builds. Now with 1530 they happen a few times a day. It seems this only happens when "Look In" is set to "Current Project" rather than a specific folder, but of course it doesn't happen every time. One of two symptoms manifests:
1) VS.NET gets into a spin lock. CPU utilization is 80-90%. VS must be killed using Task Manager.
-or-
2) Find In Files is "broken" for the rest of the VS session; the Find button is grayed out. As a clue, note that VS will gray out the Find button if "Current Project" is selected to look in, but no project is loaded. Could VS mistakenly think there's no project loaded after some failure?

I will grab a call stack the next time this happens and send it to Support.

VA_X.dll file version 10.3.1530.0 built 2006.07.08
VAOpsWin.dll version 1.3.3.4
VATE.dll version 1.0.5.7
DevEnv.exe version 7.10.3077.0
msenv.dll version 7.10.3077.0
Font: Bitstream Vera Sans Mono 15(Pixels)
Comctl32.dll version 5.82.2900.2180
Windows XP 5.1 Build 2600 Service Pack 2
2 processors
feline Posted - Jun 09 2006 : 3:38:24 PM
can you start a new thread for this please neil, otherwise it is going to get rather confusing.

when you do, do you have any other plugin's installed? any programs running that trap keyboard shortcuts at a global level? what happens if you trigger OFIW via the toolbar or VA menu?
neil Posted - Jun 09 2006 : 12:41:56 PM
My Visual Studio 2003 hangs every time I press Ctrl-Alt-O. This reproducible. It happens every time. Any ideas? Thanks.

VA_X.dll file version 10.2.1446.0 built 2006.05.31
Licensed to:
VA.NET 7.1:
VAOpsWin.dll version 1.3.2.4
VATE.dll version 1.0.4.14
DevEnv.exe version 7.10.3077.0
msenv.dll version 7.10.3077.0
Font: Courier New 13(Pixels)
Comctl32.dll version 5.82.2900.2180
WindowsNT 5.1 Build 2600 Service Pack 2
2 processors

Platform: Win32
Stable Includes:
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\include;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\atlmfc\\include;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\PlatformSDK\\include\\prerelease;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\PlatformSDK\\include;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\SDK\\v1.1\\include;

Library Includes:
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\atlmfc\\src\\mfc;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\atlmfc\\src\\atl;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\crt\\src;

Other Includes:

Mindcrime Posted - Jun 01 2006 : 01:26:56 AM
reinstalling the 360 xdk does not help. We've since switched to VS 2005 so I'm hoping that makes this problem just disappear.
rhummer Posted - May 27 2006 : 2:55:35 PM
Yeah feline, you need to have a licence to develop for the X360. I could try reinstalling teh SDK on Tuesday when I return to the office ( Monday is a holiday in the states. )

Note: I've almost always had the SDK installed before I went and installed VA X.

© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000