wpf: Insufficient Memory exception
VSF_TYPE_MARKDOWNA WPF Application starts on a dell XPS with a screen resolution of 3840 x 2160. The scale and layout is set to 250% (recommended). The application starts from Visual Studio 2019 Preview in Debug Mode on the notebook screen and works as expected. Now I move the application window to a secondary monitor with the same resolution 3840 x 2160 but with scale set to 100%. As soon as the application goes full screen, the application runs into an uncaught exception: >Insufficient memory to continue the execution of the program.
> at System.Windows.Media.Composition.DUCE.Channel.SyncFlush() > at System.Windows.Interop.HwndTarget.UpdateWindowSettings(Boolean enableRenderTarget, Nullable`1 channelSet) > at System.Windows.Interop.HwndTarget.UpdateWindowPos(IntPtr lParam) > at System.Windows.Interop.HwndTarget.HandleMessage(WindowMessage msg, IntPtr wparam, IntPtr lparam) > at System.Windows.Interop.HwndSource.HwndTargetFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled) > at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled) > at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o) > at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs) > at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
This is what I have tried so far: A empty WPF application with just a main window does not have the same problem. The same application that runs into the Insufficient memory problem started from outside of Visual Studio does not have the same problem. The same application started in Debug mode in Visual Studio 2017 also runs into the insufficient memory problem.
So it seems to be a problem that occurs with this particular application when run in Debug mode on a 4K monitor in both VS 2019 and VS 2017.
This issue has been moved from https://developercommunity.visualstudio.com/content/problem/487807/insufficient-memory-exception.html VSTS ticketId: 819184 These are the original issue comments: (no comments) These are the original issue solutions: (no solutions)
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 5
- Comments: 29 (12 by maintainers)
Is everyone confused? @GitHubUser30 says it’s fixed in VS 16.5, but @glemselenselv says it’s not. OP from vsfeedback issue says DPI matters, @glemselenselv says it doesn’t. Some internal reports say it only occurs while debugging, others say not. Some reports say there’s plenty of memory, others say not (or don’t say at all).
They might all be right. That’s because (a) any render-thread failure will lead to the exact same callstack, and (b) many different “out of resources” problems in the render-thread will lead to the exact same OutOfMemory exception. So people could be talking about different problems.
(a) means that @hellobody (and others) who report the callstack are not necessarily sharing the same problem, and the callstack doesn’t help identify it (or diagnose it, or fix it). (b) means that looking at memory usage isn’t necessarily helpful; the failure could be due to lack of
To figure out what’s really happening, we need to catch it in the act. Even a crash dump isn’t necessarily helpful, as the failure happens on the render-thread but isn’t reported until the next time the UI thread calls SyncFlush, by which time the evidence for the failure may be long gone. (Although we recently diagnosed one report as a traditional OOM, based on the crash dump holding a huge amount of managed objects, which we presume left no room for the back-buffer.)
The one thing all the reports I’ve seen have in common is VS. My hunch is that something about how VS manages its windows - the debugger-tools window, the visual-tools window it injects into debugged apps, even the code-editor window or the SQL-query-editor window - is confusing or stressing the render-thread past the breaking point, when moving to a large or high-DPI monitor. But I don’t have direct evidence, and I can’t repro any of these reports.
Thus I need your help. Find a reliable repro, and tell me exactly how it happens, including the size/DPI and configuration of your monitors, the graphics cards, the state of all VS knobs, the works. Even better, trace the failure using the time-travel debugging tool, and send me the trace. Thank you.
Time to repeat advice already given here earlier:
If you are getting OOM while running your app under VS debugger, and the OOM goes away after unchecking “Enable UI Debugging Tools for XAML”, then you are seeing the problem covered by this issue. It’s a VS problem, not WPF, and @etvorun says
If you are getting OOM in some other way (even if the callstack is the same), you are seeing a different problem. @SamBent says
In other words, this issue really belongs to VS, and it’s been fixed. So I’m closing it. All the other problems reported here need new issues and supporting evidence, as detailed in the doc.
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/time-travel-debugging-overview