c# - when - wpf tutorial youtube
How to debug “Not enough storage is available to process this command” (2)
We've started to experience
Not enough storage available to process this command. The application is
WPF, the exception starts to pop up after some hours of working normally.
System.ComponentModel.Win32Exception (0x80004005): Not enough storage is available to process this command at MS.Win32.UnsafeNativeMethods.RegisterClassEx(WNDCLASSEX_D wc_d) at MS.Win32.HwndWrapper..ctor(Int32 classStyle, Int32 style, Int32 exStyle, Int32 x, Int32 y, Int32 width, Int32 height, String name, IntPtr parent, HwndWrapperHook hooks) at System.Windows.Interop.HwndSource.Initialize(HwndSourceParameters parameters) at System.Windows.Window.CreateSourceWindow(Boolean duringShow) at System.Windows.Window.CreateSourceWindowDuringShow() at System.Windows.Window.SafeCreateWindowDuringShow() at System.Windows.Window.ShowHelper(Object booleanBox) at System.Windows.Window.Show() at System.Windows.Window.ShowDialog()
My understanding is this is some kind of out of memory exception, specific to allocation of
windows resources. What is the possible reason of this and how can I debug it?
I have reviewed the topic suggested by @Thili77 (this one). I used GDIView and task manager to look at the consumed handles during our app performing (Handles, USER Objects and GDI objects in taskmgr), and it doesn't look like they are growing. My next test is to try to run it for a day without VS (previously it was running under VS host process) and check whether this still happens. I'm still looking for any advices or tips if anybody has any
It happens on a new clean PC without hosting VS. The handles, USER Objects and GDI Objects are OK during crash. When the PC in a crashed state, nothing works properly - looks like the handles are really leaked, but ProcMon doesn't show big numbers for these values.
Also weirdly this always happens around 7-8 pm, when there is nobody in the office and it doesn't matter when I started the app run. It is already a third crash like that. Coincidence? Only thing that I've notice I find weird is a big number of page faults for the app, that grows constantly. Could this be related? Does not appear anymore, see Update #3
Next are the details of a crash I experience. The system is x86, app is x86, W7 SP1.
The current state that is shown on the screenshots are exactly right after the crash, with windbg that pauses the process.
For some reason now the exception has different message:
The operation completed successfully. But it still the same Win32Exception coming from the same piece of code.
I also need to pinpoint that I'm running with reduced amount of desktop heap and with AppAnalyzer Basic options on - in order to make the fault more frequent (which seems to work). The time assumption was indeed a coincidence, no time related shared theme noticed anymore.
From my experience I received that type of exception in case your UI thread hangs up and other threads continue placing messages to main application UI dispatcher. So in the some period of type the message queue is full and than you will recieve this exception.
To debug that you may need find your thread 1(which is UI) in VS during debug session and monitor it's activities. Maybe there is some infinite waiter on some external event or etc.
Looks like an issue which was not resolved on purpose by Microsoft, check this Connect link, in which it was stated:
We appreciate the feedback. However, this issue will not be addressed in the next version of WPF. Thank you. –WPF Team.
A workaround is provided, it might help:
You can work around this bug by adding the following code to your thread proc:
Dispatcher dispatcher = Dispatcher.CurrentDispatcher; dispatcher.BeginInvokeShutdown(DispatcherPriority.Normal); Dispatcher.Run();
This asks the dispatcher associated with the thread to shut down right away.