Eu tenho um aplicativo winforms c # (.net 4.0) que roda praticamente todos os dias da semana, 8 horas por dia, em um XP SP 3. Ele funciona bem na maioria das vezes, às vezes por meses. Então parece haver um mau feitiço e, uma vez por dia, por alguns dias seguidos, em vários momentos, surge uma exceção de violação de acesso. Tentei examinar o arquivo de despejo e capturar a exceção de violação de acesso para examinar a pilha; de qualquer forma, recebo praticamente a mesma pilha:

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)

Estou tendo muita dificuldade em corrigir isso porque o rastreamento de pilha não é muito útil. Primeiro, nem tenho certeza se posso confiar no rastreamento da pilha: o programa chega lá (parece que está tentando exibir alguma dica de ferramenta, o que é certamente possível) porque a memória já está corrompida ou se o programa realmente deveria ser legitimamente lá, mas alguma memória de dados está corrompida. Segundo, supondo que o rastreamento da pilha seja correto e confiável, não vejo uma maneira de descobrir o que está corrompendo a memória ... Não estamos fazendo nada consistente para acionar a violação de acesso ... o log do aplicativo não mostra nenhuma outras exceções detectadas antes disso ... os logs de eventos não mostram nenhuma entrada ao mesmo tempo que a violação de acesso ... Alguma dica sobre como diagnosticar melhor isso?

Update 11-10-2011: Eu já estou capturando a exceção, mas em torno do método Application.Run (). Nesse ponto, parece que é tarde demais para fazer muito. Caso essa exceção esteja ocorrendo devido a hardware / driver defeituoso e não indique que a memória do aplicativo está corrompida - haveria outro lugar onde eu pudesse capturar a exceção (e exibi-la, mas deixar o aplicativo continuar)?

Update 2012-03-04: Recebi a exceção novamente, desta vez depois de exibir um formulário bastante trivial (contém apenas uma caixa de texto e um botão ok). Eu estava usando TextBox.AppendText (). Por acaso, eu estava navegando nesteComent ao mesmo tempo. AppendText () pode estar causando o problema? Quando as violações de acesso 'originais' ocorrem, elas tendem a ocorrer após a exibição de um formulário que contém uma caixa de richtext na qual eu também chamo AppendText (). A trama engrossa!

Update 06-03-2012: Eu removi o AppendText e apenas usei o TextBox.Text =, mas recebi a exceção de violação de acesso novamente hoje. Portanto, o AppendText não parece ser o culpado. Além disso, a exceção ocorreu uma vez em uma caixa de desenvolvimento, executando o Windows 7. Portanto, não parece que a exceção seja específica do Windows XP ou de outro computador (como um problema de memória