"Find was stopped in progress" while performing search in Visual Studio - by aschmidt

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 718217 Comments
Status Closed Workarounds
Type Bug Repros 33
Opened 1/12/2012 7:24:59 AM
Access Restriction Public


While performing a search in Visual Studio, I'm consistently receiving "Find was stopped in progress." error message and no results. If I do search using grep tool, the result is returned.
No workaround (Ctrl+Break, Alt+Break, Break) worked. 
Sign in to post a comment.
Posted by Alexander Miloslavskiy on 5/13/2015 at 1:45 AM
In fact, the bug is not in VS, but in the keyboard!
Please see: http://stackoverflow.com/a/28219093/147805
Posted by spongman on 1/14/2015 at 12:05 PM
this is NOT fixed in VS2013 (Version 12.0.31101.00 Update 4)
Posted by Jim Sn on 12/31/2014 at 11:37 AM
Still fails for me in 12.0.31101.00 Update 4, with a copyright date of 2014. I can't get any of the workarounds to fix it.
Posted by Microsoft on 2/26/2014 at 2:43 PM
We have fixed the submitted bug for an upcoming release of Visual Studio. We do like to hear feedback, so please don’t hesitate to file an issue again.

Language Experience Team
Posted by MelchiorCorgie on 10/2/2013 at 5:56 AM

This bug is not new, see: http://stackoverflow.com/questions/259398/visual-studio-find-results-in-no-files-were-found-to-look-in-find-stopped-pr. The previous MS Connect occurrence mentioned in the stack overflow entry has been deleted, which looks crazy but anyway. Maybe you're new here so you don't know, but Microsoft has been avoiding to solve this problem for nearly 10 years now, and the internet is full of annoyed users who have spent hours searching to solve this problem.

Maybe you can contact someone from the Windows team and they will help you solve this problem. For instance Raymond Chen seems to know the internal behavior of the Ctrl+Break combination of keys: http://blogs.msdn.com/b/oldnewthing/archive/2008/02/11/7596539.aspx. It may be linked.

I hope you reconsider fixing this bug.
Posted by Dave Gacke on 4/29/2013 at 1:28 PM
Thank you Andreas Vergison, your solution worked perfectly for me. :)
Posted by Xood on 4/24/2013 at 2:22 AM
I can't believe this bug has been marked as "unsolvable".
It is bugging me since at least two or three years, and apparently it is happening to many people.

Any dedicated coder should be willing to put in extra hours to find bugs like these.
How knows, maybe fixing it will solve other issues unrelated to VS.

I would love to see this bug pushed up the chain of command. The way this is handled (and the no longer existing entry from 2010) is by no means the way it should be done.

On Windows 8, the original behavior can be restored by pressing the "Pause/Break" key while inside the search input box. This clue should already be helpful to develop a fix to the problem. Just figure out what this key does and go from there.
Posted by mpeac on 4/18/2013 at 11:11 PM
Still broken in VS2012
Posted by Vaccanoll on 4/3/2013 at 5:37 AM
Got to love MS bug fixing. They basically said "We know all of you keep having this bug, but since it is not easy to repro, we are just going to pretend it is not there."

Good stuff here. Can't make this kind of support treatment up.
Posted by Andreas Vergison on 1/2/2013 at 12:09 PM
I could reproduce it as follows:
1. press and hold down Ctrl
2. press and hold down ScrLk
3. release Ctrl
4. release ScrLk

Do a search (Ctrl-sh-F) and you'll see the "Find was stopped in progress." line.

To revert to "normal" state then press Ctrl-ScrLk to "normal" way.

Posted by Erik Olofsson on 10/26/2012 at 5:37 AM
A while back none of the workarounds worked and I had to restart Windows each time it happened. So I created an extension that filters the offending key out of GetAsyncKeyState:

Posted by MarcD on 10/6/2012 at 11:38 AM
Nice to know this bug still exists in the latest and what might be the worst rendition of Visual Studio to-date, Visual Studio 2012.

Posted by iquazee on 9/27/2012 at 8:50 PM
To illustrate the point below (that it's a Windows bug, still present in Windows 8), here is a WinDbg session log.
The GetAsyncKeyState function argument is 3 (VK_CANCEL) - which means Ctrl+Break.
The Ctrl+Break combination is NOT pressed on the keyboard.

# We are about to exit the USER32!GetAsyncKeyState function:
0:041:x86> u @eip
75747ab5 c20400         ret     4
75747ab8 53             push    ebx
75747ab9 e817000000     call    USER32!NtUserGetAsyncKeyState (75747ad5)
75747abe 0fbff0         movsx esi,ax
75747ac1 668bc6         mov     ax,si
75747ac4 ebeb            jmp     USER32!GetAsyncKeyState+0xf1 (75747ab1)
75747ac6 85c0            test    eax,eax
75747ac8 0f8568ffffff    jne     USER32!GetAsyncKeyState+0x2c (75747a36)

# The call stack looks like this:
0:041:x86> k
ChildEBP RetAddr
1b65f960 70a7c08f USER32!GetAsyncKeyState+0xf5
1b65f9f0 70a7c16c msenv!CBackgroundFindInFiles::Find+0xbb
1b65f9f8 759a8543 msenv!CBackgroundFindInFiles::FindInFilesThread+0xf
1b65fa04 77d3ac69 KERNEL32!BaseThreadInitThunk+0xe
1b65fa48 77d3ac3c ntdll_77ce0000!__RtlUserThreadStart+0x72
1b65fa60 00000000 ntdll_77ce0000!_RtlUserThreadStart+0x1b

# The GetAsyncKeyState argument is VK_CANCEL (0x3)
0:041:x86> ? poi(@esp + 4)
Evaluate expression: 3 = 00000003

# The GetAsyncKeyState result is 0x8000 (low 16 bits of EAX)
0:041:x86> r
eax=ffff8000 ebx=00000000 ecx=77c82ad2 edx=00000000 esi=00000000 edi=75747a15
eip=75747ab5 esp=1b65f184 ebp=1b65f960 iopl=0         nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b             efl=00000206
75747ab5 c20400         ret     4

So, the most significant bit is set, which indicates that Ctrl+Break is pressed, while in fact it is NOT pressed.

Hope that this helps to pinpoint the root cause of the issue.
Posted by iquazee on 9/27/2012 at 8:20 PM
It looks that the corresponding VS2010 bug got deleted - I'm unable to find it anymore.

One of the Microsoft responses for the old bug was that this is an issue with Ctrl-Break combination in Windows (the keyboard state gets messed up sometimes with that key, so that GetAsyncKeyState / GetKeyState may return the wrong result for Ctrl+Break).

The bug is still not fixed in Windows 8 + VS 2012 RTM :(
Posted by Microsoft on 6/27/2012 at 1:05 PM
Hello again,

There are a couple of reasons that could cause Find to throw this message. Whenever the background find operation is interrupted this message will be displayed. As I mentioned, we've done some stability improvements to the Find dialog in VS2012 post RC. At this time, given that we don't have a consistent repro, we'll not be able to investigate the issue further. We'll certainly add this to our backlog and consider for future versions.

Posted by aschmidt on 6/20/2012 at 11:35 AM

Thanks for the feedback.

There could be files opened in the VS by say, Resharper and in case *.* seach that may stop the search thread, but shouldn't that just skip the file in use?

Source files were having read access, I believe, but I couldn't tell if say, Resharper or VS itself has exclusive lock on file preventing it from reading. In addition, my instance of VS current runs under Admin rights.
Posted by Microsoft on 6/20/2012 at 10:56 AM

Thank you for logging this issue. The message indicates that the find operation was cancelled while a search was still in progress. This can happen in a couple of different cases. One likely case might be that there was a problem accessing or reading the file. You mentioned that this happens with certain solutions. Could you please check if the files in the solution have read access ? We've fixed an issue with long filenames post RC. It would also help to know whether Visual Studio was running under admin rights.

We look forward to hearing from you!
Murali Krishna Hosabettu Kamalesha | Program Manager | Visual Studio Professional - Editor team
Posted by aschmidt on 3/27/2012 at 10:33 AM
Please refer to Bug ID 105511 at
http://connect.microsoft.com/VisualStudio/feedback/details/105511/find-in-files-says-no-files-were-found-to-look-in-find-was-stopped for details regarding reproducing this bug in Visual Studio 2010.
Posted by todo ronp on 1/21/2012 at 11:38 PM
This happens if you press Ctrl + Scroll Lock. To fix it, you just have to press Ctrl+ScrollLock again. This bug has been in every visual studio release since at least VS6 (the first version I used), possibly earlier. In day-to-day scenarios, I suspect it's related to using Ctrl+Break to stop a build (presumably from accidentally hitting Ctrl+ScrollLock in the process - but this is just a guess...maybe it's something in the keyboard hardware).

Seem bizarre? Yes...agreed..
Posted by EricLeong [Feedback Moderator] on 1/13/2012 at 12:49 AM
Thank you for reporting this issue. In order to research the issue reported, we must first reproduce in our labs. Unfortunately, we are unable to reproduce the issue with the steps you provided.

Could you please provide us with the following information?

1. Please help to confirm if this issue still occurs with Visual Studio in safe mode. To do this, you need launch Visual Studio by "devenv.exe /safemode".

2. You mentioned that "Depending on the solution" in repro steps. Do you mean this issue occur with some specific projects/solutions? Could you please provide us with a sample project zip for further investigating?

It would be greatly appreciated if you could provide us this information as quickly as possible.

Thank you
Posted by MS-Moderator01 on 1/12/2012 at 7:44 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)