wpf 如何调试“没有足够的存储空间来处理此命令”
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/41543956/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How to debug "Not enough storage is available to process this command"
提问by Archeg
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.
我们已经开始体验了Not enough storage available to process this command。应用程序是WPF，正常工作几个小时后开始弹出异常。
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?
我的理解是这是某种内存不足异常，特定于windows resources. 这可能是什么原因，我该如何调试？
Update
更新
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
我已经回顾了@Thili77（这个）建议的主题。我使用 GDIView 和任务管理器查看我们的应用程序执行期间消耗的句柄（taskmgr 中的句柄、用户对象和 GDI 对象），看起来它们并没有增长。我的下一个测试是尝试在没有 VS 的情况下运行它一天（以前它是在 VS 主机进程下运行的）并检查是否仍然发生这种情况。如果有人有任何建议或提示，我仍在寻找任何建议或提示
Update #2It 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
更新 #2它发生在没有托管 VS 的全新干净 PC 上。句柄、用户对象和 GDI 对象在崩溃期间正常。当 PC 处于崩溃状态时，什么都不能正常工作 - 看起来句柄确实泄漏了，但 ProcMon 没有显示这些值的大数字。同样奇怪的是，这总是发生在晚上 7 点到 8 点左右，那时办公室里没有人，而我何时开始运行应用程序并不重要。这已经是第三次这样的崩溃了。巧合？我唯一注意到我觉得奇怪的是应用程序的大量页面错误，并且不断增长。这可能有关系吗？不再出现，请参阅更新 #3
Update #3
更新 #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.
接下来是我经历的崩溃的细节。系统是x86，应用是x86，W7 SP1。屏幕截图上显示的当前状态正好在崩溃之后，windbg 会暂停该过程。出于某种原因，现在异常有不同的消息：The operation completed successfully。但它仍然是来自同一段代码的相同 Win32Exception。
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.
我还需要确定我正在运行时减少了桌面堆的数量并启用了 AppAnalyzer Basic 选项 - 以使故障更频繁（这似乎有效）。时间假设确实是一个巧合，不再注意到与时间相关的共享主题。
采纳答案by Xavier
One possibility is that the global atom tablehas run out of available space. There is a limit of 0x4000 string atoms in the table, and there is also a limit on the total amount of space allocated to the table. Window classes are one of the things that go into this table.
一种可能是全局原子表已用完可用空间。表中有0x4000个字符串原子的限制，分配给表的空间总量也有限制。窗口类是进入该表的内容之一。
I have never attempted to debug such an issue myself, but I did find an article about checking for this problem using WinDbg: Identifying Global Atom Table Leaks. You might want to look into that as a possible cause.
我从来没有尝试过自己调试这样的问题，但我确实找到了一篇关于使用 WinDbg 检查这个问题的文章：识别全局原子表泄漏。您可能希望将其视为可能的原因。
If this turns out to be the culprit, one possible cause is that the application is not closing Window instances. HwndWrappercleans up its global atom in its Dispose, which happens in response to WM_DESTROY, which happens in response to calling Closeon the Window (or setting DialogResult, which ends up closing the window if the value changes and the window was shown by calling ShowDialog rather than Show). There may be other possible causes for an atom leak as well.
如果事实证明这是罪魁祸首，一个可能的原因是应用程序没有关闭 Window 实例。HwndWrapper在其 Dispose 中清理其全局原子，这是响应 WM_DESTROY 发生的，WM_DESTROY 发生在响应调用Close窗口（或设置DialogResult，如果值更改并且窗口通过调用 ShowDialog 显示，则最终关闭窗口）而不是显示）。原子泄漏也可能有其他可能的原因。
P.S. The reason I suspect this is because "Not enough storage is available to process this command" is the error that is returned when RegisterClassEx is unable to add to the global atom table.
PS我之所以怀疑是因为“Not enough storage is available to process this command”是RegisterClassEx无法添加到全局原子表时返回的错误。
回答by Alex
Looks like an issue which was not resolved on purpose by Microsoft, check this Connect link, in which it was stated:
看起来是 Microsoft 没有故意解决的问题，请检查此连接链接，其中说明：
We appreciate the feedback. However, this issue will not be addressed in the next version of WPF. Thank you. –WPF Team.
我们感谢反馈。但是，在下一版本的 WPF 中将不会解决此问题。谢谢你。-WPF 团队。
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.
您可以通过将以下代码添加到您的线程过程来解决此错误：
Dispatcher dispatcher = Dispatcher.CurrentDispatcher; dispatcher.BeginInvokeShutdown(DispatcherPriority.Normal); Dispatcher.Run();这要求与线程关联的调度程序立即关闭。
回答by VitaliyK
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.
根据我的经验，我收到了这种类型的异常，以防您的 UI 线程挂断并且其他线程继续将消息放置到主应用程序 UI 调度程序。因此，在某些类型的消息队列已满的时间段内，您将收到此异常。
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.
要进行调试，您可能需要在调试会话期间在 VS 中找到线程 1（即 UI）并监视它的活动。也许在某些外部事件等上有一些无限的服务员。
