Wpf: Insufficient Memory exception

[vsfeedback]

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)

[stevenbrix]

@vatsan-madhavan is this a known issue regarding high dpi support? this sounds oddly familiar...

[vatsan-madhavan]

This is a new one.

Is the app manifested as PMA or PMAv2, or is it an unmanifested app (ie System Aware)?

I’ve routinely exercised similar scenarios albeit up to 200% on similar resolutions - both my work & home setups are similar and I’m running wpf apps in debug mode regularly without crashes. I’ll have to try 250% to see if it crosses some threshold and triggers problems...

BTW are there any crash dumps we can look into?

[adrianhara]

I'm experiencing the same issue albeit on a normal fullhd (1920x1200) screen. It only happens in debug mode, if I launch the app without debugging it works fine. Launching in debug mode results in memory usage going up while the app is idle (no user input, nothing) and crash around 800mb. Launching without debug results in stable memory usage of about 70mb.

Same stack trace as above. The issue does not reproduce with visual studio 2017.

Ideas?

[grubioe]

@adrianhara - can you share what version of .NET are you running?

[adrianhara]

@grubioe I have 4.7.03190 installed, the app targets 4.6.1. I've been using Vs2017 in the meantime. I tried again 2019 Professional today and it's the same behavior. I disabled every single extension except Microsoft Library Manager. I also disabled Code Lens. I also updated to the latest version 16.1.1.

Is there any more info I can supply to help you diagnose this?

[adrianhara]

I also reported the issue in-visualstudio: https://developercommunity.visualstudio.com/content/problem/591629/running-a-wpf-app-in-debug-mode-causes-memory-leak.html. I attached a recording with screenshots (and memory dump) illustrating the issue.

[grubioe]

Thanks Adrian. I'll review with the team.

[adrianhara]

@grubioe any update?

[adrianhara]

I've managed to isolate the issue, it's caused by "Enable UI Debugging Tools for XAML". If I uncheck this, the memory usage is constant.

[grubioe]

@rladuca - have you been able to review this issue?

[adrianhara]

Any news on this front?

[grubioe]

@LyalinDotCom , @chabiss - can you review this issue, it seems to be related to the VS UI Debugging tools.

Thanks!

[glemselenselv]

Almost a year and no update? I still see this issue quite often. Only in Debug, DPI or scaling seems to have no effect, it happens on all screens.

VS Enterprise 16.5.0, the project targets 4.6.1

[hellobody]

Also experiencing this issue.
WPF, Release x64 build, .NET Framework 4.7.2, VS 2019

App manifest has dpiAware setting with value "true/PM":

Please review crash dump analyzes.
noname.exe.10916.dmp.analyzes.txt

[LyalinDotCom]

@chabiss would be the right owner for any possible bugs in designer, I have removed myself and will start a thread.

[etvorun]

If it still repros for anyone on this thread then please use VS feedback to report your repro. Please attached a crash dump of your app.
The issue should have been fixed in VS 16.5. OutOfMemory was a false positive in that case. It had something to do with video driver quirks, WPF using DirectX 9 and VS displaying a little toolbar in application-under-debugger. As a workaround you can uncheck Debug > Options > General > Enable UI Debugging Tools for XAML > Show runtime tools in application (could also be done by using most left toggle button in Live Visual Tree toolbar). Or uncheck entire Enable UI Debugging Tools for XAML.

[SamBent]

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

• (regular) memory
• GPU memory
• GDI handles
• contiguous unmanaged memory large enough to hold a back-buffer
• (others, you get the idea)

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.

[vatsan-madhavan]

time-travel debugging tool

https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/time-travel-debugging-overview

[hellobody]

Hi @SamBent,

Seems you are correct - we may just have similar call stack but different issue:
We experience this crash in Release x64 build (not during VS debug session). Built in VS 2019 v.16.4.*.
It crashes sometimes (not often) so we cannot reproduce it by wish.

I managed to get extended call stack of crashed thread with managed and unmanaged calls.
And I see the following calls in it before "out of memory" exception:
...
System.Windows.Controls.PopupControlService.RaiseToolTipOpeningEvent(Boolean))
...
System.Windows.Controls.ToolTip.OnIsOpenChanged(System.Windows.DependencyObject, System.Windows.DependencyPropertyChangedEventArgs)), calling (MethodDesc 00007ff9cb6f0cf8 +0 System.Windows.Controls.ToolTip.HookupParentPopup())
...
System.Windows.Controls.Primitives.Popup.CoerceIsOpen(System.Windows.DependencyObject, System.Object)), calling (MethodDesc 00007ff9ccd7ff58 +0 System.Windows.Media.VisualTreeHelper.GetParent(System.Windows.DependencyObject))

I suspect crash happens after Tooltip opening (Popup control creation).

Please review extended call stack attached, might be you can get something useful from it and help solve this issue:
Tooltip_Popup_DUCE+Channel.SyncFlush_managed_unmanaged_callstack.txt

Thanks.

[SamBent]

@hellobody - thanks for the report. Unfortunately a callstack isn't helpful, as I've explained earlier. And I doubt that Tooltip is involved beyond starting a codepath that will check for render-thread errors (SyncFlush); it's probably not the cause of those errors. But if you can get a time-travel trace of your crash, that would be very helpful.

The most interesting thing in your report is "not during VS debug session". That argues against my hypothesis that VS is contributing to the problem.