Home Dashboard Directory Help

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


 as Fixed Help for as Fixed

Sign in
to vote
Type: Bug
ID: 718217
Opened: 1/12/2012 7:24:59 AM
Access Restriction: Public
Moderator Decision: Sent to Engineering Team for consideration
User(s) can reproduce this bug


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 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 MS-Moderator09 [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)
Sign in to post a workaround.
Posted by Aric TenEyck on 5/30/2014 at 1:04 PM
Since this seems to be related to the Scroll Lock key, I'll share the experience I just had:

I work in an...interesting electrical environment. I occasionally build up static, and when I do, I touch the case of my computer or the metal pole of my cube wall to discharge myself.

I have an old MS Natural Keyboard (Product ID 71305-545-0665902-10342). When I touch the computer case, and sometimes when I touch the cube pole, the keyboard resets itself. The three lights flash, and the auto-repeat rate gets set to "slow". I have pinned the keyboard properties control panel to my Start menu so that I can reset the auto-repeat rate easily. (On a side note, there's another spot on my desk where, if I touch there, I can make one of my monitors reboot.)

Today, I discharged myself and watched my keyboard reset. After it reset, the lights flickered a bit and the Scroll Lock light came on. I turned it off, but later, I started seeing this bug (the first time I'd ever seen it) in VS2010. Pressing Scroll Lock and Control a couple of times didn't help, but doing a full reboot of my computer did. Apparently, the static discharge put the keyboard into a strange state where it was doing something weird with Scroll Lock.

Posted by weskevs on 4/1/2014 at 3:29 AM
Press "Ctrl+Scroll Lock" worked for me too. Thanks!
Posted by Jeff Fischer on 12/29/2013 at 2:37 AM
I think it can also be caused by a low memory state.
Posted by Poeinator on 8/5/2013 at 7:38 AM
Press "Ctrl+Scroll Lock" worked for me too. Thanks!
Posted by steve_tiger_03 on 7/22/2013 at 10:27 AM
Press "Ctrl+Scroll Lock" key to fix this problem.
Posted by Dave Gacke on 4/29/2013 at 1:29 PM
This was posted in the comments by Andreas Vergison. I am reposting here because his suggestion worked perfectly for me.

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 David B. Trout on 1/12/2013 at 1:21 AM
I can confirm the workaround does indeed work for me as well for VS2008: simply reverse the keystroke sequence in the CORRECT ORDER to reset the accidental toggled state of the key in question (ScrLk in this case):

CORRECT sequence:

    press and hold key AAAA
    press key BBB

    let go of BBB
    let go of AAA

BAD sequence:

    press and hold key AAAA
    press key BBB

    let go of AAA
    let go of BBB

So to fix the problem, simply press and hold the Ctrl key, then press and let go of the ScrLk key, and then finally let go of the Ctrl key.

I can also confirm that pressing the keys in the above BAD sequence, just as a test, does indeed recreate the problem, and that then pressing the keys in the CORRECT sequence does indeed fix the problem. That is to say, I can confirm that the problem can be easily recreated at any time and easily recovered from at any time.
Posted by ernest elda on 10/19/2012 at 6:21 AM
For workaround see a comment posted by todo ronp. It worked for me in VS.NET 2010.