| Author |
 Topic  |
|
sean
Whole Tomato Software
USA
2817 Posts |
 Posted - Nov 09 2017 : 3:03:18 PM
|
| The crash when opening the VA Options dialog might be one addressed in 2238.2 or it might be the one that will be addressed by Nov Patch Tuesday. |
 |
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Nov 10 2017 : 12:24:14 AM
|
If you are using 2238.0 or 2238.1, 2238.2 is now available:
https://www.wholetomato.com/binaries/VA_X_Setup2238_2.exe
It is a minor update over 2238.1 -- it adds retries after failed attempts to display VA menus (like alt+g goto).
2238.2 is now the current release on our download page.
|
|
|
|
NafetsPB
Junior Member
Germany
22 Posts |
Posted - Nov 10 2017 : 09:15:03 AM
|
quote:
Originally posted by sean
2238.2 is now the current release on our download page.
I downloaded and installed 2238.2 immediately but realized that, at least on my system with Visual Studio 15.4.3 and Windows 10 FCU, it caused much more trouble than 2238.1. Visual Studio was very slow and all VA popup windows were plain white boxes.
Whatever the changes are from 2238.1 to 2238.2, it might be worth looking into it. I re-installed 2238.1 again to get the system more stable (not perfect by far but better than with 2238.2, at least on my system). Strange. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Nov 10 2017 : 3:09:56 PM
|
If you are willing to have another look at VA 2238.2, it's possible Windows Defender is part of the reason Visual Studio is so slow. To check this out, you can exclude Visual Studio, and thus VA, from the problem scanning, by:
Windows Defender Security Center | App & browser control | Exploit protection settings | Program settings | Add program to customize
Add by program name
enter: devenv.exe
I selected override system settings for all 21 settings and set all to off
restart system
|
zen is the art of being at one with the two'ness |
|
|
|
NafetsPB
Junior Member
Germany
22 Posts |
Posted - Nov 13 2017 : 03:38:00 AM
|
quote:
Originally posted by feline
If you are willing to have another look at VA 2238.2, it's possible Windows Defender is part of the reason Visual Studio is so slow.
Well, actually Windows Defender is not active in our organization because we are using a commercial anti-virus and threat detection solution. Or is this a general problem with any software that is scanning the system for malware? |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Nov 13 2017 : 05:22:11 AM
|
Assuming you have permission to change the Windows Defender settings on your machine, can you please try doing so anyway? According to this thread:
https://www.tenforums.com/performance-maintenance/96792-fall-creators-update-poor-performance-lagginess-fix.html
even if you are using a commercial anti-virus, Windows Defender is still active enough in the background for this performance problem to show up. So it would be interesting to know if this is what is happening for you, or if the performance problem is coming from somewhere else. |
zen is the art of being at one with the two'ness |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Nov 13 2017 : 12:12:21 PM
|
| The slowdown with Exploit Protection affects any version of VA, not just 2238.2. Also, it is typically only experienced once per VS process. |
|
|
|
NafetsPB
Junior Member
Germany
22 Posts |
Posted - Nov 14 2017 : 05:42:31 AM
|
| Thank you for pointing me to that Defender tutorial again! Even though we are using a commercial AV solution the steps mentioned there actually improved my system's performance a lot! |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Nov 14 2017 : 06:17:20 AM
|
| Thank you for the update, I was a little suspicious of that thread saying that this problem happened even with another anti-virus installed and active, so it is interesting, and a little concerning that you were still seeing the performance problem. Concerning simply because it means this could be a more common problem. |
zen is the art of being at one with the two'ness |
|
|
|
pbrown
Senior Member
USA
44 Posts |
Posted - Nov 16 2017 : 1:30:57 PM
|
I'm seeing a new issue (for me) running 2238.2 with all 21 Windows Defender settings overridden to disabled.
I use the VAX "Find References" feature all the time. Most of the time I attempt to find all references, it works normally. However, I've probably had ~5 instances where the dialog is completely empty (shows no references). When this happens, the status line shows stuff like "Found 26 references in 4 files to: XXX (searched project)". Refreshing doesn't help, but if I do an all-new "Find References", it usually comes up successfully. Does this fall into the same category as the known dialog issues?
|
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Nov 16 2017 : 2:14:30 PM
|
| Yes, it does appear related to the FCU CreateWindow failures. The control that is hosted in the Find References results window is created via a call to CreateWindowEx which sometimes fails. That particular failure will not cause a crash because VS doesn't interact with it. |
Edited by - sean on Nov 16 2017 2:25:15 PM |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
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. |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
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
|
|
|
|
pbrown
Senior Member
USA
44 Posts |
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
Whole Tomato Software
USA
2817 Posts |
|
|
pbrown
Senior Member
USA
44 Posts |
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
Whole Tomato Software
USA
2817 Posts |
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
Senior Member
USA
44 Posts |
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. |
|
|
|
SBone
New Member
USA
4 Posts |
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. |
|
|
|
Woody
Senior Member
Czech Republic
33 Posts |
Posted - Dec 02 2017 : 1:49:38 PM
|
| So far with that Win10 update, VA works fine again! Awesome |
|
|
|
pbrown
Senior Member
USA
44 Posts |
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. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
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. |
zen is the art of being at one with the two'ness |
|
|
|
phillipfoose
Junior Member
USA
23 Posts |
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! |
|
|
|
xMRi
Tomato Guru
Germany
315 Posts |
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. |
Martin Richter [rMVP] WWJD http://blog.m-ri.de
"A well-written program is its own heaven; a poorly written
program is its own hell!" The Tao of Programming |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
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. |
zen is the art of being at one with the two'ness |
|
|
|
tony.riviere
Ketchup Master
France
58 Posts |
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
Whole Tomato Software
United Kingdom
19021 Posts |
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. |
zen is the art of being at one with the two'ness |
|
|
|
NafetsPB
Junior Member
Germany
22 Posts |
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. |
|
|
|
dswallow
New Member
USA
3 Posts |
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. |
Doug Swallow
|
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
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. |
|
|
|
Topic |
|
Windows 10 Fall Creator Update + VS 2017
