Отладка "Недостаточно памяти для обработки этой команды"

Мы начали испытывать 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()

Мое понимание - это какое-то исключение из памяти, специфичное для выделения windows resources. Какова возможная причина этого и как его отладить?

Обновить

Я рассмотрел тему, предложенную @Thili77 (this one). Я использовал GDIView и диспетчер задач для поиска обработанных ручек во время выполнения нашего приложения (Handles, USER Objects и GDI objects в taskmgr), и похоже, что они не растут. Мой следующий тест - попытаться запустить его в течение дня без VS (ранее он выполнялся в процессе VS VS) и проверить, все ли это происходит. Я все еще ищу любые советы или советы, если у кого-нибудь есть

Обновление # 2 Это происходит на новом чистом ПК без хостинга VS. Ручки, объекты USER и объекты GDI в порядке сбоя. Когда ПК в аварийном состоянии ничего не работает, похоже, что ручки действительно просочились, но ProcMon не показывает большие числа для этих значений. Также странно, что это всегда происходит около 7-8 часов вечера, когда в офисе нет никого, и это не имеет значения, когда я запускал приложение. Это уже третья катастрофа. Совпадение? Единственное, что я заметил, что я нахожу странным, - это большое количество ошибок страницы для приложения, которое постоянно растет. Может ли это быть связано? Больше не отображается, см. "Обновление № 3"

Обновление # 3

Далее приведены сведения об аварии, которую я испытываю. Система - x86, приложение - x86, W7 SP1. Текущее состояние, показанное на скриншотах, находится прямо после аварии, а windbg приостанавливает процесс. По какой-то причине в настоящее время исключение имеет другое сообщение: The operation completed successfully. Но это все тот же Win32Exception, исходящий из одного и того же фрагмента кода.

Мне также нужно указать, что я работаю с уменьшенным количеством кучи рабочего стола и с опциями AppAnalyzer Basic - для того, чтобы сделать ошибку более частым (что, похоже, работает). Предположение о времени было действительно совпадением, и времени, связанного с общей темой, больше не было. Информация о системе Процессы Информация о процессе MyApp

Ответы

Ответ 1

Одна из возможностей заключается в том, что таблица Идентификация утечек таблиц глобального атома. Возможно, вы захотите изучить это как возможную причину.

Если это окажется виновником, одна из возможных причин заключается в том, что приложение не закрывает экземпляры Window. HwndWrapper очищает свой глобальный атом в своем Dispose, что происходит в ответ на WM_DESTROY, что происходит в ответ на вызов Закрыть в окне (или установить DialogResult, который заканчивает закрытие окна если значение изменилось, и окно было показано путем вызова ShowDialog, а не Show). Могут быть и другие возможные причины утечки атома.

P.S. Причина, по которой я подозреваю, заключается в том, что "Недостаточно памяти для обработки этой команды" - это ошибка, которая возвращается, когда RegisterClassEx не может добавить в глобальную таблицу атомов.

Ответ 2

Похож на проблему, которая не была специально решена Microsoft, отметьте эту ссылку Connect, в которой было указано:

Мы ценим обратную связь. Однако эта проблема не будет рассмотрена в следующей версии WPF. Спасибо. -WPF.

Предоставляется обходное решение, это может помочь:

Вы можете обойти эту ошибку, добавив следующий код в поток:

Dispatcher dispatcher = Dispatcher.CurrentDispatcher;
dispatcher.BeginInvokeShutdown(DispatcherPriority.Normal);
Dispatcher.Run();

Это просит диспетчера, связанного с потоком, немедленно закрыть его.

Ответ 3

Из моего опыта я получил этот тип исключения в случае зависания потока пользовательского интерфейса, а другие потоки продолжают размещать сообщения в диспетчере пользовательского интерфейса приложения. Поэтому в течение некоторого периода времени очередь сообщений заполнена, и вы получите это исключение.

Чтобы отладить, вам может понадобиться найти ваш поток 1 (который является пользовательским интерфейсом) в VS во время сеанса отладки и отслеживать его действия. Возможно, на каком-то внешнем событии есть какой-то бесконечный официант.