У меня есть приложение winforms c # (.net 4.0), которое работает почти каждый день, 8 часов в день, на XP SP 3. В большинстве случаев оно работает нормально, иногда месяцами. Затем кажется, что это плохо, и один раз в день, в течение нескольких дней подряд, в разное время, возникает исключение нарушения доступа. Я попытался просмотреть файл дампа и отловить исключение нарушения прав доступа для просмотра стека; в любом случае, я получаю почти такой же стек:

Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at System.Windows.Forms.UnsafeNativeMethods.CallWindowProc(IntPtr wndProc, IntPtr hWnd, Int32 msg, IntPtr wParam, IntPtr lParam)
   at System.Windows.Forms.NativeWindow.DefWndProc(Message& m)
   at System.Windows.Forms.ToolTip.WndProc(Message& msg)
   at System.Windows.Forms.ToolTip.ToolTipNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
   at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
   at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
   at System.Windows.Forms.Application.Run(Form mainForm)

Мне очень трудно это исправить, потому что трассировка стека не очень полезна. Во-первых, я даже не уверен, могу ли я доверять трассировке стека: попадает ли программа туда (похоже, она пытается отобразить некоторую подсказку, что, безусловно, возможно), потому что память уже повреждена или программа действительно должна быть законно там, но некоторая память данных повреждена. Во-вторых, предполагая, что трассировка стека верна и заслуживает доверия, я не вижу способа выяснить, что повреждает память ... Мы не делаем ничего последовательного, чтобы вызвать нарушение доступа ... Журнал приложения не показывает другие обнаруженные исключения до этого ... журналы событий не отображают никаких записей одновременно с нарушением доступа ... Есть какие-либо советы о том, как дополнительно диагностировать это?

Обновление 2011-10-11: я уже ловлю исключение, но вокруг метода Application.Run (). В этот момент кажется, что уже слишком поздно что-то делать. Просто на случай, если это исключение происходит из-за неисправного оборудования / драйвера и не указывает на то, что память приложения повреждена - есть ли еще место, где я мог бы перехватить исключение (и отобразить его, но затем позволить приложению продолжить)?

Обновление 2012-03-04: я получил исключение снова, на этот раз после отображения довольно тривиальной формы (содержит только текстовое поле и кнопку ОК). Я использовал TextBox.AppendText (). Я просто случайно просматривал этокомментарий в то же время. Может ли AppendText () вызвать проблему? Когда происходят «оригинальные» нарушения доступа, они имеют тенденцию происходить после отображения формы, содержащей richtextbox, в котором я также вызываю AppendText (). Сюжет сгущается!

Обновление 2012-03-06: я удалил AppendText и просто использовал вместо него TextBox.Text =, но сегодня я снова получил исключение нарушения доступа. Таким образом, AppendText не кажется виновником. Кроме того, исключение произошло однажды на устройстве dev, работающем под управлением Windows 7. Таким образом, не похоже, что это исключение относится к Windows XP или другому компьютеру (например, проблема с памятью).