| T O P I C R E V I E W |
| Ivan A. Fotan |
Posted - Oct 18 2017 : 10:03:16 PM
After installing Windows 10 Fall Creators Update, Visual Assist (10.9.2237.0) become very unstable under Visual Studio 2017.
I see the following symptoms:
1. when a new tab is opened, or switch between tabs, VA Navigator Bar is unavailable on that tab, or just empty. I need to close and reopen the tab, sometimes several times, to make it work. When it happens, auto-suggestions does not work for that file. Seems like VA lost the active document.
2. Sometimes it crashes when a new tab is opened or tabs are switched.
I saw such issues when I had installed Windows 10 Insider build and had to return back to normal version to continue to use VA. But now Fall Creator Update is here, and troubles came back.
===================================================
VA_X.dll file version 10.9.2237.0 built 2017.10.03
DevEnv.exe version 15.0.27004.2002 Enterprise
msenv.dll version 15.0.26929.2
Comctl32.dll version 6.10.16299.19
Windows 10 10.0 Build 16299
8 processors (x86-64, WOW64)
Language info: 1251, 0x422
Platform: Project defined
Stable Includes:
f:\Development\WTL\_LATEST_\Include;
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\include;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\VS\UnitTest\include;
C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\VS\include;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.11.25503\atlmfc\include;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.11.25503\include;
D:\WinDDK\_LATEST_\inc\ddk;
D:\WinDDK\_LATEST_\inc\api;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\x64;
Other Includes:
Stable Source Directories:
C:\Program Files (x86)\Windows Kits\10\Source\10.0.10240.0\ucrt;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\VS\src;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.11.25503\crt\src;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.11.25503\atlmfc\src\atl;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.11.25503\atlmfc\src\mfcm;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.11.25503\atlmfc\src\mfc;
|
| 30 L A T E S T R E P L I E S (Newest First) |
| sean |
Posted - Jan 06 2018 : 4:14:09 PM
Build 2248 is not necessary for the Windows 10 updates to work and prevent the problems related to the Windows 10 bugs that have been causing problems since last summer.
Build 2248 fixes the crash in Code Inspection that started occurring with the 15.5 update of VS2017. To deal with that crash, you had three options:
1) disable Code Inspection
2) don't use the 15.5 update
3) use VA build 2248
|
| Alexis |
Posted - Jan 06 2018 : 3:35:14 PM
I just bought a licence again and downloaded the last build, and all works perfect.
I do not complain about having bought this license since I am happy with the product. however, I think there should be a fix for those who have an earlier version, since it makes the product unusable. |
| feline |
Posted - Jan 06 2018 : 08:59:53 AM
Please try installing all available Windows 10 updates, and see if this fixes the problem. We think it should, but most people testing this are using VA 2248, which has some changes to try and handle the problem on our side. |
| Alexis |
Posted - Jan 06 2018 : 07:46:12 AM
Hi! I am currently having this problem, my last visual assit available version is 2237
I was reading that the problem should be fixed now with the lastest windows 10 updates. Is this correct?
My VA version should work just fine?
thanks and excuse my English
|
| sean |
Posted - Dec 18 2017 : 7:22:22 PM
case=112698 was opened for the Code Inspection crash that started with the 15.5 update.
case=112698 is fixed in build 2248. |
| azur |
Posted - Dec 14 2017 : 06:59:10 AM
@sean: I have installed: KB4054517; VS 15.5.1 and VA 2238.2 but VisualStudio crash on the first action in the editor.
So I followed your hint "disable Code Inspection". After that I can use VisualStudio with VA.
Thanks
|
| phillipfoose |
Posted - Dec 13 2017 : 1:30:16 PM
quote:
Originally posted by sean
And also confirm that you have KB4054517 installed ( http://support.microsoft.com/kb/KB4054517 ).
Having trouble reproducing the missing window, I'll leave the logging on and if it repros I'll post the logs here. |
| sean |
Posted - Dec 13 2017 : 12:56:26 PM
And also confirm that you have KB4054517 installed ( http://support.microsoft.com/kb/KB4054517 ). |
| sean |
Posted - Dec 13 2017 : 12:55:29 PM
@phillipfoose
if you are seeing strange VA Nav Bar behavior, please enable logging while repro'ing the problem. Send the captured logs via https://www.wholetomato.com/support/contact.asp
Logging details here: https://support.wholetomato.com/default.asp?W305 |
| phillipfoose |
Posted - Dec 13 2017 : 12:50:10 PM
The performance seems to be much better, and I haven't yet gotten any crashes (knock on wood), but have had the VA navigation bar disappear off and on... |
| dswallow |
Posted - Dec 13 2017 : 10:31:10 AM
quote:
Originally posted by sean
VS2017 15.5 introduced some header changes that crash the Code Inspection parser. To prevent that particular crash, disable Code Inspection. A fix will be available at the end of the week.
Thanks; that seems to have helped. :) |
| sean |
Posted - Dec 13 2017 : 10:10:17 AM
VS2017 15.5 introduced some header changes that crash the Code Inspection parser. To prevent that particular crash, disable Code Inspection. A fix will be available at the end of the week. |
| dswallow |
Posted - Dec 13 2017 : 09:43:02 AM
quote:
Originally posted by NafetsPB
Microsoft finally published their latest patches for the Fall Creators Update to bump it up to build version 16299.125 (KB4054517) plus an update for Visual Studio 2017 (version 15.5.1).
I am currently testing this combination together with VA 2238.2 installed and the results that I am seeing right now are very promising indeed. The entire IDE is responding much faster and I also did not see any issues related to VA as of now.
So right now it is a huge improvement; I will continue testing to see if this is just a "one-time-thing" or if the issues are finally resolved.
It just crashed & burned on me, moments after opening up a solution and editing 2 lines in a file. And just did it again trying to make the same edits. And crashed & burned a third time right in the middle of repeating the second of those edits.
VS 2017 15.5.1, VA 2238.2, KB4054517, KB4053577, etc. |
| NafetsPB |
Posted - Dec 13 2017 : 03:11:30 AM
Microsoft finally published their latest patches for the Fall Creators Update to bump it up to build version 16299.125 (KB4054517) plus an update for Visual Studio 2017 (version 15.5.1).
I am currently testing this combination together with VA 2238.2 installed and the results that I am seeing right now are very promising indeed. The entire IDE is responding much faster and I also did not see any issues related to VA as of now.
So right now it is a huge improvement; I will continue testing to see if this is just a "one-time-thing" or if the issues are finally resolved. |
| feline |
Posted - Dec 06 2017 : 08:17:26 AM
Are you aware that keeping an eye out for the blank / missing VA context and navigation fields on newly opened files, and then closing the new editor window, to re-open it and see if these fields are drawn correctly can help to keep the VA bug under control?
It's not a fix, but if you are seeing this regularly then it can help. |
| tony.riviere |
Posted - Dec 05 2017 : 7:23:42 PM
quote:
Originally posted by MartinRichter
Just updated to
https://support.microsoft.com/en-us/help/4051963
Seams that it changes something... even the problem about CreateWindowEx isn't mentioned.
I guess that these fixes are not mentioned because they are actually not fixed. I did install KB4051963 with many hopes but I still have both issues: SetPixel performance in my MFC application, and Visual Assist bug.
In fact, everything is fine just after a reboot, but it's getting worse after few hours (both bugs). |
| feline |
Posted - Dec 05 2017 : 09:09:57 AM
Thank you for the update, it will be interesting to see how you find this over the next few days. Hopefully this will help. |
| xMRi |
Posted - Dec 05 2017 : 08:17:35 AM
Just updated to
https://support.microsoft.com/en-us/help/4051963
Seams that it changes something... even the problem about CreateWindowEx isn't mentioned. |
| phillipfoose |
Posted - Dec 04 2017 : 12:50:20 PM
I've been using it all day and haven't had any issues yet in terms of instability/crashing. Was unable to go more than about 15 minutes between lockups/crashes previously. It's good to be back at it again, it makes you really appreciate Visual Assist when it's taken away from you! |
| feline |
Posted - Dec 04 2017 : 05:52:27 AM
Thank you for the update, I am glad that this is working better for you now. Hopefully things will improve, with the upcoming Windows update and the next build of VA. |
| pbrown |
Posted - Dec 02 2017 : 2:40:52 PM
quote:
Originally posted by Woody
So far with that Win10 update, VA works fine again! Awesome
Things look pretty good to me so far as well. I'm testing with the Windows Defender overrides backed out, and performance looks OK so far. I think the MS update did not including anything addressing the CreateWindow issue; I did get a blank window once in "Find All References" yesterday after applying the update. |
| Woody |
Posted - Dec 02 2017 : 1:49:38 PM
So far with that Win10 update, VA works fine again! Awesome |
| SBone |
Posted - Nov 30 2017 : 2:29:14 PM
According to a new response (verified by one other) in one of Sean's post, KB4051963 appears to resolve the perf problem with SetPixel, after I reboot I may re-enable VAX and see if they snuck the fix for CreateWindow/Ex in. |
| pbrown |
Posted - Nov 30 2017 : 2:17:45 PM
quote:
Originally posted by sean
Unfortunately a memory leak like that can cause problems regardless of the system resources since VS is a 32-bit process -- there's no chance the VS process will get 4GB of memory, much less approach 64GB. VS can crash due to memory exhaustion when the process is only using 2.5GB -- admittedly, that is an extreme example, 3.5GB is more common for memory exhaustion. The process doesn't use a single heap and each competes with the others. Even without VA you have the managed heap competing with the native heap.
PDB Symbols loaded during debugging can eat up memory. Some tips for dealing with that can be found here: https://wholetomato.fogbugz.com/f/page?W730
I'm ashamed that I didn't realize that the 32-bit IDE process might be relevant.
I haven't gotten any crashes of this sort, but the interactivity problems nearly as bad. I mentioned this here because I hadn't had any issues like this until recently. I have no specific reason to believe this is VAX-related, other than timing. Build 2238 sounds sort of like an "emergency hotfix" build that would be more likely to have issues like this. I don't know if there is any way in VS2017 to account for plugin memory usage, but I'd be happy to look into that further if the problem continues.
Disabling default Intellisense makes a huge difference for me on memory consumption -- it went from 1.4GB to 600MB. I had disabled Intellisense by default on older IDEs because the startup parsing performance was so horrible. But newer IDEs don't seem as bad, and I didn't bother disabling. Loading PDBs for debugging pushed the memory footprint to more like 820MB while debugging (my PDB is ~350MB, but not all of it will be resident) and 740MB after debugging completed. I configure VS2017 to only load symbols for my files so it doesn't try to load almost-always irrelevant symbols on every run. |
| sean |
Posted - Nov 30 2017 : 1:43:30 PM
Unfortunately a memory leak like that can cause problems regardless of the system resources since VS is a 32-bit process -- there's no chance the VS process will get 4GB of memory, much less approach 64GB. VS can crash due to memory exhaustion when the process is only using 2.5GB -- admittedly, that is an extreme example, 3.5GB is more common for memory exhaustion. The process doesn't use a single heap and each competes with the others. Even without VA you have the managed heap competing with the native heap.
PDB Symbols loaded during debugging can eat up memory. Some tips for dealing with that can be found here: https://wholetomato.fogbugz.com/f/page?W730
|
| pbrown |
Posted - Nov 30 2017 : 12:49:35 PM
FYI -- I have been going back and forth between enabling/disabling VAX build 2238.2 on my system with Win10-64 RS3 (Fall Creators Update), Visual Studio 2017 (latest), and with the Windows Defender workaround (all 21 items turned off). I turn off VAX for a while due to the issues, then get annoyed with the loss of functionality, and then turn it back on despite the known issues. ("Find All References" is my favorite tool. MS' version doesn't have any refresh button (sigh), ties all its hits to files/line numbers that aren't updated when you edit code related to the references. And it also "helpfully" seems to ignore references that are #ifdef'ed out based on your project settings and/or build type.)
I'm seeing the occasional window failure (e.g., some tool windows come up blank), but I can usually work around those. The performance is much better with the Windows Defender hack, but I'm still seeing some new (since RS3) performance issues which may or may not be related to the known ones. My typical use case has one or more instances of VS2017 opened, each with its own (often large) project. I'll work in my office for a while, then access via remote desktop in the evening, then leave it open overnight, pull down new code from Git in the morning. My projects are very large (5688 files, plus external references) and Visual Studio's memory footprint about 30 minutes after opening is 1.4GB. Everything seems to be fairly responsive at this point. But I found that this morning, after doing a bunch of development work yesterday and leaving VS2017 open overnight, typing became extremely slow. I was getting like one character per second. The memory footprint had grown to 2.8GB, but the CPU load was NOT unreasonably high. Closing/reopening VS2017 seemed to address the problem. (I didn't attempt to simply close and reopen the solution in the same process.)
Seems like there could be a leak of some sort, maybe from VAX, maybe from elsewhere. A basic memory leak like this wouldn't be an issue on my particular system - I have 64GB of RAM - but I could see other leak related problems that might not be mitigated by huge amounts of RAM. |
| sean |
Posted - Nov 20 2017 : 1:27:10 PM
Unrelated other than both changes happening in RS3. If all goes according to plan, we will have completed a change in our use of GetPixel for our next release (case=112147).
The performance problem is reported here: https://developercommunity.visualstudio.com/content/problem/136952/mfc-ribbon-slow-on-first-loadshow.html
but there has been no response from MS. |
| pbrown |
Posted - Nov 20 2017 : 1:23:04 PM
quote:
Originally posted by sean
The latest update from Microsoft is that the fix for the known CreateWindowEx problem on 64-bit Windows 10 version 1709 Fall Creators Update is scheduled to be available on December 12. ...
I assume the Windows Defender performance problem is completely unrelated, other than they are both related to RS3 / Fall Creators Update? If so, is that something you're looking at separately, or do you have reason to believe a Microsoft patch might fix that as well?
Thanks,
Pat |
| sean |
Posted - Nov 17 2017 : 5:50:42 PM
I've been able to force the known CreateWindowEx problem experienced in 32-bit programs on 64-bit Win10. The symptoms are identical to the problems VA is seeing -- much more confident that they are one and the same.
I've also found that when some UI is missing, I'm able to make progress:
- close whatever window was just opened (that is missing UI)
- open VS Tools | Options and scroll around the list to force load of components that weren't previously loaded
- close options
- retry opening whatever window previously failed to load properly
|
| sean |
Posted - Nov 16 2017 : 9:02:44 PM
The latest update from Microsoft is that the fix for the known CreateWindowEx problem on 64-bit Windows 10 version 1709 Fall Creators Update is scheduled to be available on December 12. Additionally, the fix should also be included in the next Windows Insider Preview (WIP) fast ring build. At this point, our fingers are crossed that the known problem is the same as the one that is affecting VA. |
