dotnet
WPF 3D model example throws OutOfMemoryException from render thread after resuming from hibernation
This issue has been moved from a ticket on Developer Community.
[severity:Other] Using the Viewport3D and GeometryModel3D features in .NET 4.8 application seem to always cause an exception when Windows 11 computer resumes from hibernation.
Applying this example XAML into the WPF application template in Visual Studio 2022 produces an application which will throw after computer is hibernated and resumed. https://learn.microsoft.com/en-us/dotnet/desktop/wpf/graphics-multimedia/how-to-create-a-3-d-scene?view=netframeworkdesktop-4.8#create-a-3d-scene-in-xaml
Sample VS solution: WPF3DBugTest.zip
Issue repro steps:
- Build the provided application with Visual Studio 2022
- Configure Visual Studio to stop on OutOfMemoryException and run the application with debugger attached
- Hibernate Windows
- Turn computer back on and login
- Try to move or resize the application window
- Visual Studio stops on exception, resuming closes the application.
I have noted that running the application without debugger attached might not cause visible issues, or the repro steps might not be reliable. However, in a more complex application utilizing WPF 3D features an exception always occurs.
The crash occurs as OutOfMemoryException is thrown in WPF render thread.
System.OutOfMemoryException
HResult=0x8007000E
Message=Insufficient memory to continue the execution of the program.
Source=PresentationCore
StackTrace:
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) in MS.Win32\HwndWrapper.cs:line 221
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o) in MS.Win32\HwndSubclass.cs:line 253
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs) in System.Windows.Threading\ExceptionWrapper.cs:line 73
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler) in System.Windows.Threading\ExceptionWrapper.cs:line 24
at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs) in System.Windows.Threading\Dispatcher.cs:line 1021
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam) in MS.Win32\HwndSubclass.cs:line 207
Windows information: Edition Windows 11 Pro Version 24H2 OS build 26100.2314 Experience Windows Feature Experience Pack 1000.26100.32.0
Original Comments
Feedback Bot on 11/20/2024, 07:21 AM:
We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.
A workaround seems to be to minimize the application window before hibernating. However, this is not feasible to do programmatically as trying to minimize the app window from the Windows system power management "suspend" event handler doesn't help.
We also receive regular error reports from our users with the same exception call stack. We have not attempted to verify that this is related to resuming for hibernation, though. WPF 4.x 3D application.
We are 💯 getting this issue related to hibernation. Our best current workaround is to try to detect the pending hibernation, remove these 3d elements, and reconstruct upon wake. But not super reliable. We are happy to provide any diagnostics/debugging needed to help the WPF team find a resolution!
@joshucar Do you means that any wpf application with the 3D element, will OutofMemory after hibernation? Thank you.
@joshucar Do you means that any wpf application with the 3D element, will OutofMemory after hibernation? Thank you.
That is what we are seeing, yes. If we have a ModelVisual3D loaded, we will get an OOM when the computer resumes from hibernation or hybrid sleep. We only see this on Windows 11; Windows 10 doesn't seem to cause this issue.
@lindexi, what would be a good way to send you what we have - don't think I want to post it here/publicly 🙈
@joshucar You can try your self. Just drag the dump file to Visual Studio to analysis. I cannot guarantee the security of your dump data.
@LennyVC Do you meet this issues? Could you take the DUMP file to analysis?
Hi @lindexi !
Is it possible for you to take a .DMP from the sample VS Solution attached to this ticket?
@LennyVC
https://drive.google.com/file/d/1JHuMeRPnApaqst3yVgPAA3cILAFCUDaw/view?usp=sharing
First time creating a dump file so I hope I did it right. I started the sample app. Wait for it to crash and go to error line with the "insufficient memory exception" and then save the .DMP
@Todilo Sorry, based on my analysis, the current DUMP you provided was captured after the issue had already occurred. At this point, we can only see that an exception was thrown by the GFX layer of WPF, which has been identified as an out-of-memory error. Common causes for this include problems with the graphics card driver or certain resources being loaded that result in insufficient GPU memory.
As we can see, the current memory usage of the application is normal. Therefore, I believe this issue is likely related to the display area, such as a driver problem or insufficient video memory:
windbg> !address -summary
--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
Free 218 7dbe`52f85000 ( 125.743 TB) 98.24%
<unknown> 1114 241`9dace000 ( 2.256 TB) 99.99% 1.76%
Image 879 0`09ab4000 ( 154.703 MB) 0.01% 0.00%
Heap 166 0`02ffb000 ( 47.980 MB) 0.00% 0.00%
Stack 87 0`02900000 ( 41.000 MB) 0.00% 0.00%
Other 13 0`001b3000 ( 1.699 MB) 0.00% 0.00%
TEB 29 0`0003a000 ( 232.000 kB) 0.00% 0.00%
PEB 1 0`00001000 ( 4.000 kB) 0.00% 0.00%
--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_MAPPED 878 200`05614000 ( 2.000 TB) 88.63% 1.56%
MEM_PRIVATE 397 41`9ded4000 ( 262.468 GB) 11.36% 0.20%
MEM_IMAGE 1014 0`09b83000 ( 155.512 MB) 0.01% 0.00%
--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_FREE 218 7dbe`52f85000 ( 125.743 TB) 98.24%
MEM_RESERVE 371 241`95880000 ( 2.256 TB) 99.98% 1.76%
MEM_COMMIT 1918 0`177eb000 ( 375.918 MB) 0.02% 0.00%
--- Protect Summary (for commit) - RgnCount ----------- Total Size -------- %ofBusy %ofTotal
PAGE_EXECUTE_READ 404 0`07c25000 ( 124.145 MB) 0.01% 0.00%
PAGE_NOACCESS 93 0`07597000 ( 117.590 MB) 0.00% 0.00%
PAGE_READONLY 555 0`05050000 ( 80.312 MB) 0.00% 0.00%
PAGE_READWRITE 754 0`032e7000 ( 50.902 MB) 0.00% 0.00%
PAGE_WRITECOPY 82 0`0029d000 ( 2.613 MB) 0.00% 0.00%
PAGE_READWRITE|PAGE_GUARD 29 0`00059000 ( 356.000 kB) 0.00% 0.00%
PAGE_EXECUTE_READWRITE 1 0`00002000 ( 8.000 kB) 0.00% 0.00%
--- Largest Region by Usage ----------- Base Address -------- Region Size ----------
Free 1da`83728000 7c19`834d8000 ( 124.100 TB)
<unknown> 7dfc`70cfd000 1f8`727d9000 ( 1.970 TB)
Image 7ffa`e66f1000 0`00e71000 ( 14.441 MB)
Heap 199`8be66000 0`00859000 ( 8.348 MB)
Stack 26`22980000 0`0017b000 ( 1.480 MB)
Other 199`ed270000 0`00181000 ( 1.504 MB)
TEB 26`22669000 0`00002000 ( 8.000 kB)
PEB 26`22668000 0`00001000 ( 4.000 kB)
Could you please share the steps you took to reproduce this issue? Are your steps the same as others—specifically, does the application throw this exception after loading the model and then resuming from sleep mode?
@Todilo Sorry, based on my analysis, the current DUMP you provided was captured after the issue had already occurred. At this point, we can only see that an exception was thrown by the GFX layer of WPF, which has been identified as an out-of-memory error. Common causes for this include problems with the graphics card driver or certain resources being loaded that result in insufficient GPU memory.
As we can see, the current memory usage of the application is normal. Therefore, I believe this issue is likely related to the display area, such as a driver problem or insufficient video memory:
windbg> !address -summary --- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal Free 218 7dbe`52f85000 ( 125.743 TB) 98.24% <unknown> 1114 241`9dace000 ( 2.256 TB) 99.99% 1.76% Image 879 0`09ab4000 ( 154.703 MB) 0.01% 0.00% Heap 166 0`02ffb000 ( 47.980 MB) 0.00% 0.00% Stack 87 0`02900000 ( 41.000 MB) 0.00% 0.00% Other 13 0`001b3000 ( 1.699 MB) 0.00% 0.00% TEB 29 0`0003a000 ( 232.000 kB) 0.00% 0.00% PEB 1 0`00001000 ( 4.000 kB) 0.00% 0.00% --- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotal MEM_MAPPED 878 200`05614000 ( 2.000 TB) 88.63% 1.56% MEM_PRIVATE 397 41`9ded4000 ( 262.468 GB) 11.36% 0.20% MEM_IMAGE 1014 0`09b83000 ( 155.512 MB) 0.01% 0.00% --- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal MEM_FREE 218 7dbe`52f85000 ( 125.743 TB) 98.24% MEM_RESERVE 371 241`95880000 ( 2.256 TB) 99.98% 1.76% MEM_COMMIT 1918 0`177eb000 ( 375.918 MB) 0.02% 0.00% --- Protect Summary (for commit) - RgnCount ----------- Total Size -------- %ofBusy %ofTotal PAGE_EXECUTE_READ 404 0`07c25000 ( 124.145 MB) 0.01% 0.00% PAGE_NOACCESS 93 0`07597000 ( 117.590 MB) 0.00% 0.00% PAGE_READONLY 555 0`05050000 ( 80.312 MB) 0.00% 0.00% PAGE_READWRITE 754 0`032e7000 ( 50.902 MB) 0.00% 0.00% PAGE_WRITECOPY 82 0`0029d000 ( 2.613 MB) 0.00% 0.00% PAGE_READWRITE|PAGE_GUARD 29 0`00059000 ( 356.000 kB) 0.00% 0.00% PAGE_EXECUTE_READWRITE 1 0`00002000 ( 8.000 kB) 0.00% 0.00% --- Largest Region by Usage ----------- Base Address -------- Region Size ---------- Free 1da`83728000 7c19`834d8000 ( 124.100 TB) <unknown> 7dfc`70cfd000 1f8`727d9000 ( 1.970 TB) Image 7ffa`e66f1000 0`00e71000 ( 14.441 MB) Heap 199`8be66000 0`00859000 ( 8.348 MB) Stack 26`22980000 0`0017b000 ( 1.480 MB) Other 199`ed270000 0`00181000 ( 1.504 MB) TEB 26`22669000 0`00002000 ( 8.000 kB) PEB 26`22668000 0`00001000 ( 4.000 kB)Could you please share the steps you took to reproduce this issue? Are your steps the same as others—specifically, does the application throw this exception after loading the model and then resuming from sleep mode?
Yes, that is what I do.
- start application
- see model all is well
- sleep mode
- wake from sleep mode
- after a few seconds, exception.
We have at least 2 computers at work where this happens. Also been reported at least 1 from a customer. Same scenario.
@Todilo It seems that the problem was caused by some resources not properly handling the situation of lost devices.
@Todilo It seems that the problem was caused by some resources not properly handling the situation of lost devices.
@lindexi Not entirely sure what that means. Device such as in graphic device? It is a laptop if that matters, I do have a docking station but have also tried without any periphials plugged in.
@Todilo What I means is https://learn.microsoft.com/en-us/windows/win32/direct3d9/lost-devices
@lindexi which is nothing a user of WPF can handle I would assume. And not something I as a user of windows can resolve either? Could it be caused by having 2 graphics card (intel + nvidia)?
Could it be caused by having 2 graphics card (intel + nvidia)?
@Todilo Sorry, I'm not sure about this problem.
I'm still trying to find the reproduction steps for the debuggable version now. I'm still not sure of the source of the problem now.
Here is the minimal example application source code from the original post. It should reproduce the issue reliably with the steps described.
For those who have been able to reproduce the issue, does it happen on hibernate, sleep, or in both cases?
Also, I'm not able to reproduce it on Windows 10. Is that something agreed upon, that this is a Windows 11 related issue?
I can not reproduce this issus in my Windows 11 25H2 26200.5715, event hibernate or sleep or both
For those who have been able to reproduce the issue, does it happen on hibernate, sleep, or in both cases?
Also, I'm not able to reproduce it on Windows 10. Is that something agreed upon, that this is a Windows 11 related issue?
I am using windows 11 Home, and sleep.
We added more information to our error reports last week, and we have found one "lead". First, in our case, this is about OutOfMemoryException and the exact same stack trace with UpdateWindowPos as shown in the original post. But, it does not look like this error only happens on wake up. We have 6 error reports since our last release, and 2 of them have come within a few seconds after wake up. But, here's the lead, in all cases, RenderCapability.Tier >> 16 == 0, RenderOptions.ProcessRenderMode == Default, and SystemParameters.IsRemoteSession == False. The computers have a variety of monitor and GPU setups, no pattern there. I'm going to try to gather more information about why the render tier is 0 (e.g. registry information). All computers are Windows 11 (but so are also the vast majority of user computers in general, so this might not mean anything).
One question for now, obviously, is why are we seeing this OutOfMemoryException in render tier 0?
I can't explain this phenomenon, but it is indeed a new "lead". It may means that this doesn't seem to be a universal error, but rather there is a loophole in the implementation of a certain branch.
@Todilo @tormnator Could you help me to continue this issue?
Please run the .NET 10 application demo I built (published together with the debug build of WPF) on your machine and attach Visual Studio to the running process for deeper debugging.
The .NET 10 application demo: WPF3DBugTest_NET10_win-x86_Debug.7z
Follow these steps:
- Launch the .NET 10 app that was published with the debug WPF binaries.
- In Visual Studio, open Attach to Process and ensure the Code Type (or selection) includes Native.
- Confirm that the symbol file for wpfgfx_cor3.dll — wpfgfx_cor3.pdb — is loaded, and that the loaded wpfgfx_cor3.pdb is the one from the ZIP archive I provided (that archive contains the Debug build with full debugging information).
- Open the Breakpoints window and add a C++ function breakpoint for the function named MilInstrumentationCallHRCheckFunction.
- Try to reproduce the issue. If the breakpoint is hit, inspect the call stack and local context — this should reveal useful information.
- If you cannot step into or otherwise have trouble debugging, use
Debug>Save Dump Asto create a DUMP file and share that DUMP with me for further analysis.
Expected result: when the bug is reproduced, Visual Studio should hit the breakpoint in MilInstrumentationCallHRCheckFunction, and the call stack should provide actionable clues.
https://github.com/dotnet/wpf/blob/ee7cbb82652173e3a9f4e8feec155eb58eed5f4f/src/Microsoft.DotNet.Wpf/src/WpfGfx/shared/util/UtilLib/Instrumentation.h#L130
And you can find my demo code in https://github.com/lindexi/lindexi_gd/tree/06c5d6c55ce91d1dae25c40c281b32e8318f730a/WPFDemo/DarkerbewurNefelearca
@Todilo @tormnator Could you help me to continue this issue?
Please run the .NET 10 application demo I built (published together with the debug build of WPF) on your machine and attach Visual Studio to the running process for deeper debugging.
The .NET 10 application demo: WPF3DBugTest_NET10_win-x86_Debug.7z
Follow these steps:
- Launch the .NET 10 app that was published with the debug WPF binaries.
- In Visual Studio, open Attach to Process and ensure the Code Type (or selection) includes Native.
- Confirm that the symbol file for wpfgfx_cor3.dll — wpfgfx_cor3.pdb — is loaded, and that the loaded wpfgfx_cor3.pdb is the one from the ZIP archive I provided (that archive contains the Debug build with full debugging information).
- Open the Breakpoints window and add a C++ function breakpoint for the function named MilInstrumentationCallHRCheckFunction.
- Try to reproduce the issue. If the breakpoint is hit, inspect the call stack and local context — this should reveal useful information.
- If you cannot step into or otherwise have trouble debugging, use
Debug>Save Dump Asto create a DUMP file and share that DUMP with me for further analysis.Expected result: when the bug is reproduced, Visual Studio should hit the breakpoint in MilInstrumentationCallHRCheckFunction, and the call stack should provide actionable clues.
wpf/src/Microsoft.DotNet.Wpf/src/WpfGfx/shared/util/UtilLib/Instrumentation.h
Line 130 in ee7cbb8
MilInstrumentationCallHRCheckFunction( And you can find my demo code in https://github.com/lindexi/lindexi_gd/tree/06c5d6c55ce91d1dae25c40c281b32e8318f730a/WPFDemo/DarkerbewurNefelearca @lindexi I have tried this however I can't get it to crash. Could it be a .net 10 fix? I tried running straight from source-code, though I had to change to .net9 as I have not .net 10 installed. And running then it crashes as expected. Edit: I also downloaded .net 10.0.10-rc1 with visual studio 2026 insider and run it. Then it still crash.
@lindexi I have never been able to reproduce the issue on my setup (Lenovo P15s laptop, dock, multiple monitors, Windows 10). I have been further studying the problem today, including adding more data to our internal error reports, and trying various tricks to force the system to fail, or even force render tier 0, without luck. We'll be releasing the next version of our app soon, and will see if the additional data helps (assuming the errors continue).
My hypothesis--for us--is that the OutOfMemoryException in the render thread happens on laptop computers, often times (but not always) related to connecting to/disconnecting from external monitors.
I also found a registry key HKEY_CURRENT_USER\SOFTWARE\Microsoft\Avalon.Graphics\IgnoreDwmFlushErrors and saw that the path to VS 2022 was added. This made me do a little AI research on it, and it led me to the following links: https://support.microsoft.com/en-us/topic/june-14-2022-kb5013892-cumulative-update-for-net-framework-3-5-and-4-7-2-for-windows-10-version-1809-and-windows-server-version-2019-39351abe-295b-44ea-8099-65632e28f055 and https://www.perplexity.ai/search/in-the-windows-registry-under-HuK57WIuRZiOSXFwfI60Uw?0=d
So, maybe this is a known issue after all, and maybe we should also add our app(s) to that registry key? One observation which might support this is that our error logs show that users who get the OOM exception are able to continue the application afterwards. WPF documents seem to indicate that the render thread is "zombied" after the error and will not work anymore, but that does not seem to be the case here. But who knows...