VS2017 (15.3) OutOfMemoryException (in SQLite)
After updating VS2017 from 15.2 to 15.3, it crashes every time when I do this:
- open one of my solutions (120 C# projects) - checked standard and lightweight solution load, both cases cause a crash
- click on the name of one of the methods
- (VS starts eating memory and CPU and becomes unresponsive)
- wait a few minutes
- VS crashes
This is 100% reproducible.
The Event Log entry is as follows:
Application: devenv.exe Framework Version: v4.0.30319Description: The process was terminated due to an unhandled exception.
Exception Info: System.OutOfMemoryException
at System.Windows.Media.Composition.DUCE+Channel.SyncFlush()
at System.Windows.Interop.HwndTarget.UpdateWindowSettings(Boolean, System.Nullable`1<ChannelSet>)
at System.Windows.Interop.HwndTarget.UpdateWindowPos(IntPtr)
at System.Windows.Interop.HwndTarget.HandleMessage(MS.Internal.Interop.WindowMessage, IntPtr, IntPtr)
at System.Windows.Interop.HwndSource.HwndTargetFilterMessage(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
at MS.Win32.HwndWrapper.WndProc(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(System.Object)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(System.Windows.Threading.DispatcherPriority, System.TimeSpan, System.Delegate, System.Object, Int32)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr)
I've captured memory usage screenshots:
- The 1st one is after just starting VS without a solution.
- The 2nd one is after opening the solution and not doing anything else.
- The 3rd one is directly after clicking the method name (step #2 above); the increase from using ~700MB to ~3.3GB RAM happens in a split second. It then sits like this (RAM usage doesn't change much and CPU is ~12-13% which is one full core on my 8-core machine) for a few minutes and then crashes.
Add Comment
The screenshots I attached using the problem reporting tool are not visible... You might want to fix that.
In the meantime, here they are:
1.
2.
And screenshot #3, because apparently I can't add 3 images to a comment :-/
3.
I also reported a possibly related OOM crash in RoslynCodeAnalysisService32.exe here: https://github.com/dotnet/roslyn/issues/21580.
It's exactly the same problem with our team!!! (30 cs project, some of csproj has more than 15,000 cs file)
I've noticed something similar here. However, the stack trace is slightly different. I've worked around this by uninstalling VS2017 version 15.3 and reinstalling VS2017 version 15.0.
Could you paste the stack trace here?
Sorry, I missed this, the perf log can be found https://developercommunity.visualstudio.com/content/problem/101667/visual-studio-2017-fills-memory-and-crashes.html?childToView=115103#comment-115103 I believe you are the one who's dealing with my issue on that thread.
Hey Jakub, can you supply us with a repro solution where we can investigate this? That would be very helpful.
Alternatively, if you could provide us with a link to the roslyn db cache file that would be helpful. The cache file will be under your solution directory in a folder called: .vs\Roslyn\v15\sqlite3\storage.ide. Thanks!
I can't share the solution (it's company property), but I can share the Roslyn cache. How can I do so privately, is there any place I can upload this? Do you need the cache from just after a crash, before a crash or it doesn't matter?
I reported a similar issue to the folks at DevExpress, since I thought CodeRush for Roslyn was at fault (and tbh, I'm not exactly sure whether it is completely innocent), but I noticed that disabling CRR made a difference (obviously, since its Roslyn-based analyzers don't run) and also that disabling Code Lens made a difference (instead of memory going up and levelling, it went up briefly and then went down again).
But disabling either is something I'd rather not do, for the convinience it brings.
Obviously, this is on VS 2017 Enterprise (15.3.2), since other editions don't have Code Lens. Not sure if thats the case for Jakub.
It's VS 2017 Enterprise here as well (all versions from 15.3 to the current 15.3.2) - no Roslyn-related extensions other than what's bundled with VS though.
Can you check if disabling Code Lens makes a difference for you?
We have the same problem!!
It surprises me there are so few upvotes on this issue. Let's show MS folks this is important!
I was able to reduce memory by replacing large project references with file references.Until the patch comes out.
<ProjectReference ... > => <Reference ...>
I'm somewhat confused why we seem to be the only folks running into this issue...compared to what others say about their solution size, mine are rather small-ish (11 projects, 4k .cs files and 1k .xaml files) and still easily shows the issue after switching Git branches externally (not using the SCC Plugin) or causing a csproj change otherwise (like a rebase for example).
As soon as VS detects this and presents me with the "Project file changed" -> "Reload Solution" popup, picking either has a high chance of crashing with OOM. Only thing I notice during that time is ServiceHub.RoslynCodeAnalysisService32.exe hitting .vs/SLN/vs15/sqlite3/storage.ide a lot, but nothing from devenv.exe that looks suspicious at a glance.
Solution by
Add Comment
Thank you, I confirm 15.4.1 fixes the issue for me! :-)
Under VS Version 15.8.9, the default git integration still allocates huge amount of memory(since our repo is big) inside "Microsoft Visual Studio 2017 (32 bit)" process, way more than 3GB, one may argue that the lack of 64 bit version is the real problem, but you can not disable the default git integration either.
I fixed the problem via NoGit extension
Solution by
Add Comment
Nope, no change there. On the very 1st Go To Implementation, everything locks up and VS crashes after a few seconds maximizing to 3.5 GB RAM usage.
We downgraded to 15.2 for now.
There is still a problem when proceeding as follows.
https://github.com/dotnet/roslyn/wiki/Performance-considerations-for-large-solutions
- Disabling Full Solution Diagnostics
- Disabling CodeLens
- Disabling Solution Crawler
- Adjusting File Caching Threshold(RecoverableTreeLengthThreshold = 1)
- Disabling Reference Promotion
- Specifying a main method explicitly
- Checked Option-Text Editor-C#-Advanced-Perform editor feature analysis in external process
I strongly recommend using Rider(https://www.jetbrains.com/rider/)