It seems that Visual Studio 2022 has a new feature that resembles GitHub Autopilot.
This is an image related to this feature:
This feature is very very annoying (slow and unpredictable and interfering with your typing speed). Thus I searched to see how can I disable it. But I can't find anything.
So, how can I disable this?
The new Intellicode in Visual Studio was pretty annoying for me as well, and I was able to follow the steps in this Stack Overflow post to disable it completely.
However, if you just want to disable the specific prompt, you can press esc and dismiss the suggestion.
Some extensions can cause a typing delay, for example Rainbow Braces. It can cause a lag of few secs trying to type, usually on large files > 5000 lines. After disabling the typing comes to normal.
I've noticed that my VS15 forgets changes I make to the settings in options and check boxes under Tools on reboot.
For instance, when I exchange a string in a document, I get the pop-up telling my how many substitutions have been made. There's the check box showing/hiding this message next time. I uncheck it and fairly enough the pop-up doesn't come up again. Until I restart VS, that is. After that, the pop-up is back!
The same goes for many other options (typical NuGet packages' suggestion based on the contents of CSHTML-file, for instance). However, all the settings I make in Resharper menu are remembered. Also, the key short-cuts seem to be remembered.
I restarted, updated and reinstalled - no luck there. Starting VS in admin mode gives no change, neither. I noticed that if I change the values in the registry, the changes are effective in VS. It's like VS won't write the modified settings to the registry by itself (and I'm damn sure too chicken and too lazy to horse around in the registry for that).
Has anybody else experienced that?
What more can I do to diagnose it?
How do I kill the problem?
I'm using Visual Studio 2008 Professional Edition for development. I have observed that whenever I test web applications or websites using Ctrl+F5 and then stop the debugging (or close the browser), the debugging starts again, as if I pressed Ctrl+F5 again.
Initially I thought this could be because of a sticky ctrl key but I have checked and confirmed that sticky keys in my machine are not enabled.
I searched on the web and have observed that many others have also faced the very same issue. But Microsoft says that the issue is due to a sticky ctrl key. (Refer : http://connect.microsoft.com/VisualStudio/feedback/details/534915/stop-debugging-shortcut-key-shift-f5-causes-debugging-to-restart-instead-of-just-stopping)
Anyone else has any other ideas as to why this could be happening (in case I might have missed out on some updated forum)
Thanks a lot.! :)
I really like your question as this occurs to me occasionally and don't know why after many years & don't believe it's related to sticky keys.
There are only two ways I can stop the debugging in this situation:
Alt + D; E = I press Alt + D; to open the Debug menu then E for 'Stop Debugging' This is alternative hotkey combination that will work.
is to click the stop button on the debug tool bar.
(optional) Sometimes when I'm not able to press teh Alt + D I'm not able to get focus to the toolbar and I press ctrl 5 times. Somehow the sticky keys get stuck even though I didn't turn them on.
Hope that helps.
I too have this happen to me sometimes, and I too have disabled StickyKeys. I even see this sometimes when I have locked my computer. When this happens and I try to type in my password, the computer acts like I am pressing down control.
My only suggestion is to use the menus to stop Debugging, and then gently tap the Control key twice, and then try again. It always stops when I do this.
In the back of my mind, I wonder if it is due to conflicts of third-party utilities that intercept key combos for their triggers. SnagIt, Freesnap, AutoHotKey are three that I use, but when the problem is so intermittent, you can't really disable them and say, "yup, my problem went away."
This may sound simple and might not be the answer for you but it was for me. Somehow in Visual Studio 2015 my Shift+F5 got mapped to "Debug.Restart" and "Debug.StopDebugging" got remapped to Ctrl+Alt+Break. Not sure if Resharper somehow screwed up the shortcuts.
I was able to fix it by going to Tools... Options... Environment... Keyboard, searching for "Debug.StopDebugging" and assigning Shift+F5 to it.
I also had the same problem. I'm also using Visual Studio 2008. Just click tools>>option>>environment>>Keyboard. And then set
to "Default".
This happened to me when I upgraded VS to that disaster 16.6.x which changed Shift-F5 from Debug.stop to Debug.start.
Tools menu > Options > Keyboard fixes it. (It's a confusing dialog but you'll figure it out -- you're a programmer, ie IQ through the roof, right? Yeah!
Shift-Ctrl-F5 does restart.
I'm in my 50th year of programming and still loving it and making tons of money.
What a career this is!
In my VS2008, suddenly, I can use just letters, no enter, space, delete, backspace, or any other keys.
Any advice how to fix this?
Keyboard is working perfectly in other applications.
Thanks.
I was having this problem several times a day. Make sure the Language setting is set to "Same as Microsoft Windows" under Tools -> Options -> Environment.
ReSharper Options - Environment - General - Clear Caches solved problem.
Close the document that you are working on and reopen it. It works for me when my keyboard seems to be not functioning and i can't type into the current form.
For me the only thing that worked is this solution in this link => https://superuser.com/a/1626086/1055404
Just go to tools -> options -> Environment -> Keyboard and click on reset button on the top right corner
Try to remember line number (better ;) ), close the file you want to modify, then re open it.
It happening sometimes to me and that "hack" works perfectly.
It is realy strange behaviour, in my case even the restart of windows was not helpful. the trick was for me to open the project using "File" menu in VS and then open the .csproj not
.sln file.
Disabling Productivity Power Tools and restarting the IDE worked for me.
Should not that it was very shortly after installing Resharper that the problem occurred, having never experienced it before.
It happens to me when I'm close to run out of RAM. Closing processes (not VS) makes keyboard usable again.
I work under a Virtual Machine, On my case I had to close and open the VS again.
Have you been comparing changes before a push/commit? Check if you have any modal windows open. Had the same problem and when I tried to close VS17, it warned me, that I had a modal window that prevented some user inputs. I pressed "ok" to the window, restarted VS and I could again do inputs. I had the exact same error as you - could insert letters, but couldnt fx delete, "end", "home" etc.
I had the same issue with Visual Studio 2017. I was not able to remove code after typing. I just close the Visual Studio and run as administrator. Its working fine for me.
Set another keyword mapping scheme in the
Tools - Options - Environment - Keyboard
Look at your keyboard shortcuts and make sure there isn't anything set to any of the keys you're trying to use. This happened with me when I installed an extension and messed with some keyboard shortcuts and inadvertently set settings sync to 'c' no matter where it was input.
Close vertical or horizontal group.
In my Visual Studio instance, even if I just wrote a single line of return in a C# console application, it will take me a minute after pressing F5 to execute the actual code (I mean the time it takes to stop on the single return statement after pressing F5 -- I set a breakpoint on the return statement in the main function). What is wrong? Is there a check list?
I am using Visual Studio 2008 VSTS edition and debugging on Windows Server 2003 x64.
You may need to delete all your breakpoints---note that you need to click the "Delete all breakpoints" button (or use Ctrl + Shift + F9), NOT just delete them one by one. If Visual Studio has mangled your solution settings the latter will not work. You may need to add a breakpoint first, in order for this to work (clever, eh?).
If worst comes to worst, you may need to delete your .suo file and let Visual Studio start a new one from scratch. Note that you will lose your personal solution configuration settings, however (only for this solution, not any others). However, you may want to move/rename the file temporarily until you determine whether or not this is the problem; that way, you can always move it back. I have seen some online resources recommend deleting (moving/renaming) the .ncb file as well.
I have seen this before. Try deleting all your breakpoints and then set the ones you want. Hit F5. Is it faster now?
I just noticed that you mentioned setting up the .NET source debugging feature. Try to disable that. Your network connectivity to Microsoft's source server may be slow. Also disable any symbol server connectivity in menu Tools → Options → Debugging → Symbols.
Also try disabling "Enable property evaluation and other implicit function calls" in menu Tools → Options → Debugging → General.
Or remove your .suo file which can be found next to your solution (.sln) file.
This solved an issue I had with debug sessions taking a long time to start and stop.
I had this problem. After trying all the listed advice and removing all Visual Studio extensions, we finally figured out that somehow IntelliTrace was enabled. Disabling that fixed everything.
How to: Enable and Disable IntelliTrace
Do you have a lot of breakpoints set? Those can really slow down startup time. Everytime a new module is loaded into the process address space, they all need to be checked to see if they are valid.
Go to menu Tools → Options → Debugger → Symbols and check if you have public symbols set or UNC network paths set. Also check menu Tools* → Options → Debugger → General to see if you have source server set.
All of these can affect debugging based on slow network speed or unavailable servers. The 5 minute wait time is network timeouts.
If nothing in options is set, check to see if you have the _NT_SYMBOL_PATH environment variable set.
My colleague had a very slowly responding Visual Studio, and it literally took minutes to perform a step while debugging.
The root cause turned out to be an anti virus program (Threatfire) that went crazy while Visual Studio was running. Killing its process immediately fixed everything.
In my case changing the debug symbol "Automatically load symbol for" option from "All modules" to "Only specified modules" solved the problem. You can change this option from menu Tools → Options → Debugging → Symbols.
A different cause plus... How to find the problem
To me it was the option ShowOtherThreadIpMarkers. A value of 1 makes Visual Studio (2010) unbearably slow (3-5 seconds for each debug step. With a value of 0, it is fast again.
What is it that option? I have no idea. I could not find it through the Visual Studio user interface.
I unchecked all possible debugging options in there and nothing worked.
So I went to Import/Export Settings and loaded my old settings I've previously saved going backward in time until Visual Studio was fast again, then compared the vssettings files..., etc., etc.
I'd like to remark that if you load the settings while you are in debug mode stopped on a breakpoint, they become effective immediately. You don't have to stop the debugger and restart.
From ScottGu's blog linked by Travis: "One other performance gotcha I've heard about recently is an issue that a few people have reported running into with the Google Toolbar add-in. For some reason this can sometimes cause long delays when attaching the Visual Studio debugger to the browser. If you are seeing long delays with your web application loading, and have the Google Toolbar (or other toolbars) installed, you might want to try uninstalling them to see if that is the cause of the issue."
Running under the debugger for me was roughly 10x slower than running without debugging.
After trying every solution suggested here, I went through every debugger setting and enabled/disabled to see if it made a difference.
For me, it turned out that disabling Suppress JIT optimization on module load in the debug settings massively improved things.
Make sure you don't have any stale network mappings to servers that no longer exist (network timeouts will kill you). Or use something like Process Monitor to see if a network (or other file error) seems to be blocking for a long time.
Are you using a symbolsServer to download symbols for Windows DLL files?
If so, disable that as it can take some time, but I wouldn't expect that to cause long delays in a basic console application.
Menu Tools → Options → Debugging → Symbols.
I know this is an old topic, but for what it's worth...
I've found that if I've had a separate Internet Explorer window open for a long time it can take up to a minute to start debugging. Close all Internet Explorer windows and debugging starts immediately.
In my case Google Toolbar was slowing down my debugging.
gplus_notifications_gadget.html just kept going on and on overloading the debugger. I wanted to keep the Google Toolbar because I use it on a regular basis, so I just disabled the G+ notification button (the small button besides the profile button). It is happy now.
I had the same issue in Visual Studio 2010, with stepping in the code excruciatingly slow (between 3 to 10 seconds). However, none of the above settings modification did the trick.
I eventually found the ultimate solution, which would work in all of the above post issues: reset all your settings, as described here (essentially menu Tools → Import and Export Settings, Reset all settings, with saving existing settings to a file (for reverting)).
You may first want to save a particular part of your settings. For instance, I first saved my color theme (Solarized-like) and then restored it after the global reset.
For me, the setting that killed performance (Windows 8 even hanged except for mouse movement) was to uncheck "Break all processes when one process breaks" in menu Options → Debugging → General.
Just one more cause of a slow Visual Studio debugging experience...
Long time ago I enabled FusionLog to see what was causing an assembly binding problem.
Make sure you disable it after using it. Why? Because it writes a lot of logging data to the disk while enabled.
This is the FusionLog key on Window's Registry (regedit.exe):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion
Change the ForceLog, LogImmersive and LogResourseBindings values from 1 (enabled) to 0 (disabled).
I had this problem too, but it had nothing to do with breakpoints in my case. It was code shortcuts that I added in the tasks window:
http://www.customsoftwareframeworks.com/blog/longwaittimetoinsertoraddalineoftextbuginvisualstudio--tasklistwindow--onlywhenaddingandremovelines
I'm sure there are other ways you could see a problem like this, but there is a bug somewhere that caused this problem for me...deleting all my options would have fixed this, but that is something that I did not want to do. So, I debugged it and wrote about it in my blog...your problem sounds like mine.
Something that has worked for me is to make sure there are no conditional break points. Other than that, I have had success fixing slow debugging by simply restarting Visual Studio and only opening one instance of Visual Studio at a time.
I had a similar issue and none of the other guidance seemed to help. I had rebooted to no avail. I had removed all breakpoints, deleted the .suo file, checked that symbols weren't being loaded from external sources, and checked that no paths existed in the application that was unavailable.
Then, I thought to clean the solution. I noticed in the output window that C# IntelliSense reported an issue when cleaning:
There was a problem reading metadata
from
'{B0C3592F-F0D1-4B79-BE20-3AD610B07C23}'
('The system cannot find the file
specified.'). IntelliSense may not
work properly until the solution is
reloaded.
In this case, once you actually discover the error message, it tells you exactly how to resolve it. (Good job on the error text, poor job on discoverability!) I unloaded the solution's projects, then reloaded them. I was then able to successfully run clean solution. It worked, and the debugger did as well.
Closing the "Autos" window improved debugging for me in Visual Studio 2008 for a big native C++ solution.
Hiding it won't work. It needs to be closed.
I experienced the same slowdown and disconnecting from the network fixed the problem for me as some other comments and answers have stated (but of course that is not an ideal fix).
For my case this one simple change fixed my solution: In the project properties on the debug tab I disabled "Enable the Visual Studio hosting process" (I am running Visual Studio 2010).
Get more memory and a faster HD. More details are here.