|T O P I C R E V I E W
||Posted - Jun 26 2021 : 09:36:50 AM
after upgrading to VS 16.10 (16.10.2 just now) I am experiencing regular freezes of the Visual Studio. Sometimes it freezes three times a day but sometimes it freezes five times in one hour. It looks like the actual freeze is more likely to happen just after build finishes but I think it does not limit to this situation. After freezing the VS is nonresponsive and displays "Visual studio is busy" notification. VS (devenv.exe) does not consume any CPU when it is frozen. I tried "Analyze Wait Chain" from task manager and it indicated that one thread in devenv.exe is waiting on VaCodeInspectionServer.exe and another thread in devenv.exe is waiting on VaDbMtx.exe. Disabling Code Inspection in VA did not resolve the issue and frozen devenv.exe was still waiting on VaCodeInspectionServer.exe (why?) and VaDbMtx.exe. Disabling the whole VA on the other hand seems to help, but my productivity is badly reduced.
License: Standard (xxxxxxxxxxxxxx) Support ends 2022.01.28
VA_X.dll file version 10.9.2406.0 built 2021.04.23
DevEnv.exe version 16.10.31410.357 Professional
msenv.dll version 16.0.31410.357
Comctl32.dll version 6.10.19041.844
Windows 10 10.0 2009 Build 19043.1081
16 processors (x86-64, WOW64)
Language info: 1250, 0x405
Platform: Project defined
C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\Include\um;
C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\cppwinrt;
C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\winrt;
C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\shared;
C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um;
C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\ucrt;
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Auxiliary\VS\include;
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.29.30037\atlmfc\include;
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.29.30037\include;
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Auxiliary\VS\UnitTest\include;
Stable Source Directories:
C:\Program Files (x86)\Windows Kits\10\Source\10.0.18362.0\ucrt;
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Auxiliary\VS\src;
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.29.30037\crt\src;
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.29.30037\atlmfc\src\atl;
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.29.30037\atlmfc\src\mfcm;
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.29.30037\atlmfc\src\mfc;
|30 L A T E S T R E P L I E S (Newest First)
||Posted - Aug 18 2021 : 07:01:09 AM
Thank you for confirming this. Microsoft fixed a bug in VS2019 version 16.11 that was causing a lot of these performance problems, but not quite all of them.
||Posted - Aug 17 2021 : 1:45:17 PM
I can confirm I had no freeze since I've started using 16.11 previews (now official 16.11.1)
||Posted - Aug 17 2021 : 11:15:46 AM
Martin, do you have much code in C#?
Looking at one of your dump files, the IDE is waiting on a thread that is doing a lot with Microsoft Code Analysis, without any sign of VA in this particular thread.
We have had another user who reported major performance problems that were fixed by disabling IDE Code Analysis for C#, as explained here:
can you please also try this, and see if it makes any difference for you?
||Posted - Aug 17 2021 : 11:08:58 AM
Apologies for this, the new version of Visual Studio 2019 has fixed a very similar issue for several of our users.
We have recently pinned down a memory leak in VA, which can happen when you change configurations:
IDE Build menu -> Configuration Manager...
is this something you do often? Or perhaps something that happens as part of your build process?
I see I have asked about the memory usage before, but its worth mentioning, since we now know the trigger for this memory leak.
Have you ever seen any form of pattern or trigger to this hang?
Looking at the dump file you sent, it looks like you have another couple of extensions installed. Partly to test this, can you please close all instances of the IDE and then run the command:
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\devenv.exe" /RootSuffix VATest
this will create and load a new, default profile for Visual Studio, so you will be asked which basic settings you want to use, and you should only have the standard, default IDE extensions installed. Visual Assist will not be installed into this profile, so you will need to go into the dialog:
IDE Extensions menu -> Manage Extensions
and install Visual Assist from the online extension store, to install VA for this test profile.
To load your normal, default profile just load the IDE normally. To return to this test profile again, pass the /RootSuffix command line switch when loading the IDE. You can run both profiles at the same time, next to each other. In VS2019 the profile name will be shown just under the close button, in the top right hand corner of the main IDE window. If you export your IDE settings from your main profile you can them import them into the test profile.
Do you see the same problem with the test profile, with just the default extensions and VA installed? I am assuming the problem triggers relatively quickly / easily, so it won't take to long to tell if it is happening or not.
||Posted - Aug 17 2021 : 07:58:23 AM
Upgrading VS to 16.11.1 did not help. VS froze right after the very first rebuild after the upgrade. Please note that all of my freezes are permanent and I have to kill VS through Task Manager.
||Posted - Jul 22 2021 : 09:56:50 AM
We have had another user report that preview version 16.11 fixes this problem, so this looks like the solution. Hopefully this version, and this fix will be out of preview soon.
||Posted - Jul 22 2021 : 08:10:33 AM
16.10.4 do not fix the issue for me. But the 16.11 Preview seems better (just testing since few hours).
The VA X support report me that it's a Visual Studio bug: https://developercommunity.visualstudio.com/t/VS-with-latest-VisualAssist-hangs-consta/1472972
||Posted - Jul 22 2021 : 07:30:53 AM
I updated to 16.10.4 (which is the latest official non-preview release now), and that seems to have fixed the hangs for me.
||Posted - Jul 21 2021 : 04:34:26 AM
Would you be able to try installing Visual Studio 2019 version 16.11 Preview:
You can install the preview along side your current install of Visual Studio 2019, so you are not forced to rely only on the preview version.
We have one user who has reported that this has helped a great deal, and Microsoft think that they may have fixed a problem related to this in the preview. Unfortunately without being able to reproduce the problem ourselves we cannot test this directly.
||Posted - Jul 21 2021 : 03:54:28 AM
The same happens to me. I can 100% repro these ~30 second freezes by opening one of our solutions while a few other VS instances are active. All of them become unresponsive for ~30 seconds.
I'm happy to provide any diagnostics or test speculative fixes.
||Posted - Jul 21 2021 : 03:36:17 AM
I confirm that it's a nightmare with Visual Assist X 10.9.2406.0 and Visual Studio 16.10.x and solution/project with C++ code only.
Each day, I have multiple freezes of VS IDE. And If I have multiple instance of Visual Studio opened (which happens very often), a freeze in one VS instance, often lead to freeze all Visual Studio instances.
I have to kill all instances to be able to work again. And very often, just open a solution (containing lot of projects and files) lead to a freeze. It seems to happens when few files are already open inside the solution "session".
In order to be able to work, I have disabled Visual Assist plugin :(. But I miss so many feature, that it's very annoying.
Just hope that a new version (even Beta version), will be available soon to fix that problem.
||Posted - Jul 15 2021 : 11:47:37 AM
I have the dump files, many thanks both Woody and martin, and I have asked our developers about this. Hopefully it will help to shed some light on the problem here.
||Posted - Jul 15 2021 : 09:12:24 AM
I apologize for the delay but I was on vacation.
Anyway I managed to capture two sets of memory dumps of hung VS (and some auxiliary processes) using Task Manager. You can download them using https://1drv.ms/u/s!AoUsQ2Ca5kakgvwTdL41WY15ltE5Kg?e=tIyxlh. As dumps can contain I sent the password to feline but if someone is interested to look at them please leave me a message.
First set is from VS 16.10.2 and the second one is from 16.10.3. I see no difference in behavior between these two versions. Also neither disabling IntelliSense nor Debug Assistance helped with the problem.
||Posted - Jul 15 2021 : 04:24:20 AM
Unity is really using C# for game development scripting. But some studios have access to the Unity engine source code itself that is mostly C/C++ either for easier debugging or for their own changes/optimizations.
Anyway, today my VS2019 froze for about 8 minutes. During that time I've made two dumps through Task Manager after about 1 minute and after 6 minutes.
I've compressed and uploaded the first one here:
My Visual Studio Community 2019 is version 16.10.2 and Visual Assist is version 10.9.2382.0
Hope it helps.
||Posted - Jul 13 2021 : 08:27:19 AM
I didn't know that Unity used C/C++. Then again I know virtually nothing about Unity, only that it "uses" C#.
Can you please try and capture a mini dump of "devenv.exe" when you are seeing this problem? This will allow us to get a better sense of what VA is doing during the problem.
If you are not sure how to do this, this page explains:
Since dump files tend to be large, if you don't have an easy host to upload the file, I can email you details of our FTP server, if that helps, for uploading the dump file.
||Posted - Jul 12 2021 : 07:41:15 AM
You need to download the whole capture.sleepy (it's a renamed ZIP archive) instead of downloading internal packed text files. Once you use the link I posted there is a download icon in the upper right corner.
I'm pretty sure it's the same issue. C# programmers probably don't need VA installed. I'm primarily a C/C++ programmer, working with VA for years, currently switching between a Unity C# SLN and Unity C/C++ engine source SLN, often having both opened at the same time. If VA has really an external exe, maybe it's the C/C++ part making VA stuck, so the C# instance can't use it too. I will give your other instructions a try.
||Posted - Jul 09 2021 : 10:38:27 AM
Are you using this: https://github.com/VerySleepy/verysleepy
to generate these logs? When I look at the text files directly I am not seeing much that makes sense.
If you have "Windows Performance Recorder" installed, would you be able to grab a log with this please? This gives a fairly detailed sense of what is going wrong, and I already have some other logs in this format to compare this to.
As a test, can you please close all instances of the IDE, and then run "regedit.exe", and set the value:
HKEY_CURRENT_USER\SOFTWARE\Whole Tomato\Visual Assist X\VANet16\ForceVcpkgInclude = 00
you need to edit the registry while the IDE is closed, since VA saves out its settings on exit, so if you have any instances open, they will overwrite your edit.
I don't know if this will help in your situation, but it might do so. If this does help it could cause VA to miss some C++ include directories, so if it does, I will look at this with you as well.
So far no one has reported a problem like this with a C# solution, only C++ solutions, so I honestly don't know if you are running into the same problem or a different one that just looks similar.
||Posted - Jul 09 2021 : 04:38:31 AM
I have exactly the same issue since the VS2019 16.10.0 major update. It's in a C# project for Unity 2020.2.7f1 and also in C/C++ source code of the engine itself. I have disabled all other extensions.
I was trying to profile the devenv.exe using Very Sleepy CS
Results are available here:https://drive.google.com/file/d/1Gn3xETxvB8TgD2LW_Se2qABoXl9MDhgx/view?usp=sharing
A screenshot of the worst offender (compressed to 100KB JPG )
||Posted - Jul 02 2021 : 07:57:01 AM
When you have IDE intellisense enabled, if the IDE intellisense cannot produce a listbox, then VA will step in and produce one its self, even though the IDE intellisense has priority. So its certainly possible that you have code that the IDE understands better than VA does. Plus if disabling IDE intellisense isn't helping, then enabling it again should not be a problem at all.
If you can find any specific examples where VA should be producing a listbox, but isn't, then I would be interested in looking at them. It's possible its simply a different problem, but if there is code VA is struggling to understand then that could be a factor. But since parsing seems to be finished, since colouring is being applied, it doesn't sound like the problem is VA never finishes parsing.
It's good news that the hangs have stopped for now. Having an instance of devenv.exe running in the background that you don't know is there could be a factor, if it is somehow consuming significant resources.
We are actively looking into these performance problems, but so far they are proving very hard to reproduce internally, which is obviously making this harder.
||Posted - Jul 01 2021 : 6:58:50 PM
When I started VS on Jun 28th there were two instances of devenv.exe (and only one visible VS). But when I tried it now, only one instance of devenv.exe remained running. Anyway I use two instances of VS occasionally but described issues happen even with one instance of VS. As to when sources get colored I think everything works as usual. I didn't notice any other irregularities in performance or reliability of VA except for freezing.
The more interesting thing is that for the last few days I haven't experienced any hangs. But it looks like VA suggestions are working even worse than normal. Is VA getting some information from IntelliSense (that is disabled)?
I will try to enable some of the options I disabled recently, will watch for problems and will generate dump / logs eventually.
||Posted - Jun 30 2021 : 11:58:37 AM
Discussing with edl_si via email.
Martin, when you are working with more than one instance of the IDE, does the first instance get time for VA to finish parsing before you load the second instance? Assuming you have VA's syntax highlighting enabled, this is only applied once VA has finished parsing, so knows how to colour your symbols.
I am just wondering if having both instances parsing a lot of code at the same time is a factor, but even if it was, it should not hang the IDE, just slow it down a bit at most.
||Posted - Jun 29 2021 : 2:57:35 PM
Sent you a mail - btw that was with Intellisense disabled this time, still seems to be happening unfortunately
||Posted - Jun 29 2021 : 1:31:37 PM
edl_si, you are seeing a different problem to me, or at least it has a different trigger. My complex test case Visual Studio 2019 version 16.0.3 and also in Visual Studio 2017.
||Posted - Jun 29 2021 : 10:00:47 AM
That's no surprise, but it was worth asking just in case. A dump file is definitely a good place to start, please. I have just emailed you the FTP details:
another option, assuming you have it installed, is "Windows Performance Recorder". If you have this, and could run it before triggering the problem with Visual Studio, I would be very interested in the performance log it generates. This would give us something to compare to the dump file, to see if it gives us more of an idea of what is going on and going wrong here.
||Posted - Jun 29 2021 : 07:29:50 AM
Getting approval is probably quite an ordeal, as likely will go through various levels of management who won't really understand.
Is it likely a dump file of when it freezes or log files will be of any use to you for my case? If so my email is firstname.lastname@example.org, if you want to send me the ftp details
||Posted - Jun 29 2021 : 06:46:03 AM
Martin, thank you for checking this. The memory usage numbers are quite low, so that doesn't sound like a problem.
In my test case for the problem with lots of configurations, the IDE title bar gets updated with "not responding" by Windows, and the IDE does resume responding given time, so it sounds like you have a different problem. Can you please capture a mini dump of the hung IDE. If you are not sure how, this page explains how:
I would also be interested in VA logs, but since this is somewhat random, that is going to generate large log files, but if you are OK to turn on logging, can look for them, this page explains how:
The mini, or even full dump files are likely to be to large to email. If you want I will email you details of our FTP server, so you can upload the files there, unless you have a convenient host for them?
edl_si, I need to run some tests here on earlier versions of Visual Studio 2019, but I was not aware that the bug I am thinking of only happened in later versions of the IDE, so this is unexpected.
Would it be possible to get a copy of just your SLN and VCXPROJ files, without anything else, purely for testing purposes? I appreciate this is often not possible, but since there won't be any code involved it might be possible. I have one test case where the SLN and VCXPROJ files on their own is enough to trigger a problem, so a second test case to compare would be rather helpful. It would also tell us if you are seeing the same problem or a different problem.
If it helps we can sign a non disclosure agreement. The files would only be used for testing purposes, to try and understand and fix this bug.
If it is possible to share the files, please send me the files via email:
including this thread ID or URL in the description, so we can match it up.
||Posted - Jun 28 2021 : 12:14:47 PM
I get 41 hits unique hits for debug|x64 in the sln, (we have 41 projects) each project has between 8 and 18 configurations. If you want the total configuration numbers across all projects I work it out as 738 in the sln (as the sln has 18 configs so has to map all even for the sub projects which have less configs).
Again to re-iterate this did not occur before we updated VS, we previously used 16.6.2 and did not see this issue.
devenv.exe is using 714MB so doesn't seem to be a memory issue.
I can test out disabling Intellisense, normally I leave it on as I thought it was still the default source of information for VA?
||Posted - Jun 28 2021 : 11:55:32 AM
IntelliSense was enabled so I disable it now.
Debugger integration was enabled so I disabled it now.
I can not recall any source files we are generating during the build process. We have some .idl files in a separate "Idl" project but they are quite stable and the whole project is skipped on regular build.
After I opened the solution, changed some files and built it, the Task manager reports around 250 MB for the first instance of devenv.exe and 680 MB for the second instance. Second instance is the one that consumes CPU while I am working in the VS window.
Also please note that VS does not recover from these freezes so maybe it would be better to call them hangs? Strange is that Windows does not usually report VS as being hung in this situation. Also ending a frozen/hung VS application from the Processes tab of Task manager (all processes of VS are there grouped as one "application") takes several minutes and usually requires several attempts.
As I changed two options mentioned above I will report back tomorrow.
||Posted - Jun 28 2021 : 10:32:43 AM
Thank you for the details. Neither of you are using such a large solution that the solution size would suggest possible problems.
Have you disabled IDE intellisense, which is normally done via:
IDE tools menu -> Options -> Text Editor -> C/C++ -> Advanced -> IntelliSense -> Disable IntelliSense = True
doing this would mean you don't have to worry about both VA and the IDE parsing everything at the same time.
edl_si, do you have a lot of projects, or Solution Configurations, or both at once, in your solution? A delay on start up suggests VA is having to do a lot of work parsing the solution structure. There is a known problem that shows up on solution load. The test case only has a single project, but 90 different configurations. I got the number 90 by opening the SLN file in a text editor, and searching for unique lines describing the DEBUG|x64 state of each configuration.
How does this compare to your situation?
martin, ending a build is not a situation I would expect VA to care about, since it does not involve editing the code files. Do you know if your build process updates / generates code files that VA might then be parsing?
Do you have:
VA Options -> Debug Assistance -> Enable debugger integration required by VA Step Filter for native C/C++
turned On or Off? This should not effect performance, but it is something that might be effecting build performance.
Can both of you please run Windows Task Manager in detailed view, and see what memory usage you see for Microsoft Visual Studio? Since the IDE is a 32bit process there is a 3gb limit on how much memory it can use, so its possible that you are running into this. I would have thought very unlikely with these numbers of files, but worth checking just in case.
||Posted - Jun 28 2021 : 09:38:36 AM
Title bar says we have 8409 files in our solution. But lots of library files are not added to the solution like for example 15k files of boost.
All projects in the solution are C/C++ projects but some files use other languages like hlsl, js/typescript (+react/html/css), etc. but they are mostly excluded from parsing using settings of VA.
Yes I turned Code inspection back again. Code inspection is working fine and I am using it regularly. I have VA Code Inspection Results windows always visible and using it to fix old code I'm messing with. On your sample code it reported redundant void, redundant continue and redundant return.
Analyze wait chain reports threads waiting on VaCodeInspectionServer.exe and VaDbMtx.exe even when VS is working as expected. Also freezes are more frequent on my notebook (AMD Ryzen 7 4800H, 8C16T, 16 GB RAM) than on my desktop (AMD Ryzen Threadripper 1920X, 12C24T, 32 GB RAM).