Search stops working for “Entire Solution”

问题:

Somehow Visual Studio search has stopped working for me. Anytime I search "Entire Solution" for some text I get this result:

Find all "[Whatever I was searching for]", Subfolders, Find Results 1, "Entire Solution" No matching text found to look in. Find was stopped in progress.

Why does it suddenly say "No files were found to look in"?

I've found a number of links on Google that say to press Ctrl + Break or Ctrl + Scroll Lock, but none of them seem to work for me.

回答1:

I get that problem once in a while. One seemingly nonsensical solution I've found is to click inside the Find Results window (not the Output window). Once the blinking text cursor is visible, hit Ctrl+Break four or five times. This seems to "unblock" whatever causes the problem.

There are reports Ctrl + ScrLk may need to be used instead of Ctrl+Break . If these doesn't work then try Break alone.

Note from Codeguard: I have found an explanation and deterministic solution to this problem

回答2:

Windows 7 Pro SP1 64-bit, Visual Studio 9.0.30729.1

Didn't Work:

• Ctrl + Break
• Ctrl + Scroll Lock
• Restart of Visual Studio

Worked:

• Break (in Find Result 1 & 2) (only pressed once)

Source: Comments in Gordon's link...

回答3:

Bug source

This is neither Visual Studio nor Windows related bug. In fact, the bug is in your keyboard! Many keyboards from different vendors have been reported to be buggy.

Problem

If you press Ctrl+Break and release Ctrl first, then Break gets stuck on a buggy keyboard. If you ever pressed Ctrl+Break the "wrong" way, you will have this problem with search being interrupted.

Details

According to scan code specifications, Break and Ctrl+Break are special. They send "make" (press) AND "break" (release) scan codes the moment you press Break. They send nothing when you release Break. The buggy keyboard will send the following sequence:

1. Ctrl "make" scan code
2. Ctrl+Break "make" scan code
3. Ctrl "break" scan code
4. Pause "break" scan code

That is, Ctrl+Break is never released, but instead Pause is released.

Reproduction

You could for example use old good Spy++ from Visual Studio tools. Attach it to anything, for example Windows notepad, and monitor messages (I suggest that you select only keyboard messages). Press Ctrl+Break, releasing Ctrl first. Check the output from Spy++. You will see the sequence I shown in Details section.

I have tried two different keyboards on the same computer. Logitech K120 has the bug while some other Mitsumi keyboard behaves according to specifications and does not have the bug.

If you think about it, it's easy to understand that correct behavior needs special case handling, while buggy behavior is naive. This is why many different keyboards can be buggy.

Solution

Replace your keyboard :)

Workaround

You simply need to press Ctrl+Break, paying attention to releasing Break first. It doesn't matter which application is active.

回答4:

This bug has been in Visual Studio a long time and it never seems to get fixed.

See this MS Connect item from 2004: http://connect.microsoft.com/VisualStudio/feedback/details/105511/find-in-files-says-no-files-were-found-to-look-in-find-was-stopped

I couldn't believe they still hadn't fixed it in VS2010 - but it's still there :(

The Connect item has been marked as Closed - Won't Fix: https://connect.microsoft.com/VisualStudio/feedback/details/718217/find-was-stopped-in-progress-while-performing-search-in-visual-studio

回答5:

Ctrl+Break or Ctrl+ScrLk cancel a find operation. Try it. What has happened is that some software layer (presumably Windows) thinks those keys are still being pressed even though they are not. Pressing and releasing them clears the flag.

It could be any of these combinations:

Ctrl+Break

Alt+Break

Break

Ctrl+ScrLk

Remember that you have multiple control and alt keys on your keyboard -- try it with each of them. If it's the right Ctrl key + ScrLk, pressing the left Ctrl is not going to resolve the issue.

Here is the Connect issue which Microsoft closed as "Won't Fix".

If this is a recurring problem for you, there is a Visual Studio extension that suppresses the virtual key that causes the problem.

回答6:

Ctrl + F and Ctrl + Shift + F have stopped working on Visual Studio 2015 Community Edition.

My friend told me going to:

1. Tools → Import and Export Settings:

2. Choose: Reset all settings → Next

3. Choose: No, just reset settings, overwriting my current settings → Next

4. Choose: General → Finish

回答7:

I tried all the previous options. They didn't work for me, but reading them made me sure that this is a bug, and I will have to try some unknown ways to get it working. So, I tried a simple file search in Visual Studio 2010 in:

1. The current document
2. All the open documents

Both of which worked.

Then I tried Find in Files and woah! It started working.

回答8:

Search solution in Visual Studio 2012 is broke. I tested this on three machines, did not work on two. What I found which does work is click on drop down arrow next to search field and select Find all. This is a bit of pain because you have to select drop down every time you search in solution.

回答9:

I had the same problem in Visual Studio 2013 (Update 3). None of the key combinations listed previously worked for me. I had *.cs selected in the FileTypes.

To get it working, I changed it to *.*, and then back again to *.cs - now it works.

回答10:

I have been using Visual Studio 13 without this problem for couple of years now and I started having this issue after applying Update 5 or it could be a weird keys combo pressed by me unknowingly which triggered it, I don't know for sure.

Echelon_Force's solution worked for me. Thanks!

Didn't Work:

Ctrl + Break

Ctrl + Scroll Lock

Worked:

Break (in Find Result 1 & 2 window - Only pressed once)

Happy finding in files!

回答11:

Unfortunately none of these special key strokes work for me. Only restarting Visual Studio 2010 seems to work for me.

回答12:

In my case I had a bogus character in the "Look at these file types:" field in the search window.

Removing the character solved the problem.

Visual Studio 2017

回答13:

All of the combinations of Scroll Lock and Break didn't do anything for me. As a workaround, I added the solution directory to the Search Folders (the second ellipsis button), then changed the Look In field to the solution directory. The root problem still exists, but for me, this is functionally the same thing.

(Visual Studio 2013, Windows 8.1, x64)

回答14:

I am running Visual Studio 2012 Professional in a Virtual Machine, connecting using rdesktop from a Linux machine.

None of the other suggestions worked, but solved the problem was:

• Go to the 'Find and Replace' screen. (ctrl-shift-f in my case)
• Enter a search text and choose 'Entire Solution'
• Hit 'Find Next', it should find a result.
• Hit 'Find All', now works without aborting. (Note, i hit my Mouse really hard and some swearing was involved, too, but I don't think that has any relevance apart from a psychological one :D )

回答15:

In Visual Studio 2013 after Update 3, I had the same problem. Before, I could just put ".cs" or ".cshtml" in the Look at these file types: and it would work. But after Update 3 I now have to put ".cs" or ".cshtml" (or whatever file types I want to search in) and it works fine.

回答16:

This works for me after everything else didn't or worked only sometimes:

Do the search, and while searching, hold CRTL all the time and keep pressing Break.

回答17:

If you are searching for multiple file types, they must be separated with a ; character, not a space.

This returns the correct results:

*.cs;*.vb;*.js;*.aspx

This returns nothing at all:

*.cs *.vb *.js *.aspx

This isn't the problem the original poster, but for other people who can't figure out why their search isn't working, this could be the reason.

回答18:

Another late-to-the-party answer, but I found yet another "solution" for this problem.

When it looks as if the Visual Studio app has frozen on search...leave it alone. Don't close it. Don't restart it. Just let it go for about 10-15 minutes and the problem may correct itself, as it did in my specific case. I'm not sure as to why leaving it alone solved the problem, although my wholly uneducated guess is that Visual Studio is building some sort of an index to be able to search files and running into a snag. Once the 10-15 minutes are up and VS completes its search, it seems fine after that.

回答19:

Probably won't apply to most situations, but what fixed it for me was turning off 'Use Regular Expressions' in the search window. I had previously been using Regular Expressions for some tricky replacements and didn't turn off when finished. I think perhaps it was interpreting part of simple replace text (see below - had some special characters) as the start of an incomplete or malformed regular expression, and so couldn't actually do any matching. Would be nice if it told you!

回答20:

It only seems to lock-up if I use Ctrl + F (Find in Entire Solution) and never if I use Ctrl + Shift + F (Find in Files).

回答21:

The following worked for me. Visual Studio → menu Windows → Reset Window Panel. The resizing of Visual Studio made it to hide the option.

回答22:

This was one of my biggest problems with Visual Studio. For me (Windows 10, Visual Studio 2015) the find in all files window got locked with a white-out, and guess what, hitting print screen solves it.

回答23:

That Ctrl+Break trick worked for me for years, it's really interesting to finally understand why this happens. With VS2015 I have somewhat related problem with search: my Ctrl+Shift+F simply does not work, this key combination seems to be ignored when I press it. I tried to reinstall even VS 2015 and I still got that same broken behavior.

In case somebody has identical problem, here's what was the reason:

I turns out that for whatever random reason VS2015 shows that "find in files" dialog on another monitor that's attached to my PC. That other monitor is 4K Samsung TV that normally stays "Off" and I have no clue why VS 2015 sends that search dialog box to that monitor. Surprisingly, when I turn on my TV the search dialog moves to the primary monitor on its own!

回答24:

Ctrl + Break works for Visual Studio 2008

回答25:

Nothing worked for me. I use also Resharper. So I had to reset my VS key bindings and reapply Resharper shortcuts. Only this got me it working.

1. Reset current keyboard configuration (Tools | Options | Environment | Keyboard | Reset).
2. Go to ReSharper | Options | Environment | Keyboard & Menus | "Visual Studio" | Apply Scheme.

回答26:

This has begun occurring for me with the update to Version 15.8.8 of Visual Studio. None of the above steps worked. There is no error. Just what appears to be a 'stuck' search.

I had recently installed ApexSQL Refactor 2018.03.0331. Uninstalling this did not resolve the issue and does not seems to be the cause. It seems to be related to Version 15.8.8 of Visual Studio update.

I completely uninstalled Visual Studio and reinstalled Version 15.8.8 again. The issue with Ctrl-Shift-F searching the Entire Solution is no longer an issue. Whatever caused the problem does resolve after uninstalling and installing.

I once again installed ApexSQL Refactor 2018.03.0331 and everything still works well.