Vi phạm Truy cập: Đã cố gắng đọc hoặc viết bộ nhớ được bảo vệ

Question

Tôi có ứng dụng winforms aC# (.net 4.0) chạy khá nhiều mỗi ngày trong tuần, 8 giờ mỗi ngày, trên XP SP 3. Hoạt động tốt hầu hết thời gian , đôi khi trong nhiều tháng. Sau đó, nó dường như nhận được trong một chính tả xấu, và một lần một ngày, trong một vài ngày liên tiếp, tại các thời điểm khác nhau, một ngoại lệ vi phạm truy cập đi lên. Tôi đã thử nhìn vào tập tin dump, và bắt ngoại lệ vi phạm truy cập để nhìn vào ngăn xếp; một trong hai cách, tôi nhận được khá nhiều cùng một ngăn xếp:

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) 

Tôi đang gặp khó khăn khi sửa lỗi này vì theo dõi ngăn xếp không phải là rất hữu ích. Đầu tiên, tôi thậm chí không chắc chắn liệu tôi có thể tin tưởng dấu vết ngăn xếp không: chương trình có ở đó (có vẻ như nó đang cố hiển thị một số chú giải công cụ, điều này chắc chắn có thể) do bộ nhớ đã bị hỏng hoặc nếu chương trình thực sự hợp pháp ở đó, nhưng một số bộ nhớ dữ liệu bị hỏng. Thứ hai, giả sử theo dõi stack là chính xác và đáng tin cậy, tôi không thấy một cách để tìm ra những gì đang làm hỏng bộ nhớ ... Chúng tôi không làm bất cứ điều gì phù hợp để kích hoạt vi phạm truy cập ... Nhật ký ứng dụng không hiển thị bất kỳ các ngoại lệ bị bắt trước đó ... nhật ký sự kiện không hiển thị bất kỳ mục nhập nào cùng lúc với vi phạm truy cập ... Bất kỳ gợi ý nào về cách chẩn đoán thêm điều này?

Cập nhật 2011-10-11: Tôi đã bắt ngoại lệ, nhưng xung quanh phương thức Application.Run(). Tại thời điểm đó có vẻ như đã quá muộn để làm nhiều. Chỉ trong trường hợp ngoại lệ này xảy ra do phần cứng/trình điều khiển bị lỗi và không cho biết bộ nhớ của ứng dụng bị hỏng - sẽ có bất kỳ nơi nào khác mà tôi có thể bắt ngoại lệ (và hiển thị nó, nhưng sau đó để ứng dụng tiếp tục)?

Cập nhật 2012-03-04: Tôi lại có ngoại lệ, lần này sau khi hiển thị biểu mẫu khá nhỏ (chỉ chứa hộp văn bản và nút ok). Tôi đã sử dụng TextBox.AppendText(). Tôi chỉ tình cờ duyệt qua số điện thoại comment này cùng một lúc. AppendText() có thể gây ra sự cố không? Khi các vi phạm truy cập 'ban đầu' xảy ra, chúng có xu hướng xảy ra sau khi hiển thị biểu mẫu chứa richtextbox mà tôi cũng gọi là AppendText(). Các âm mưu dày!

Cập nhật 2012-03-06: Tôi đã xóa AppendText và chỉ sử dụng TextBox.Text = thay vào đó, nhưng tôi lại có ngoại lệ vi phạm truy cập một lần nữa. Do đó, AppendText dường như không phải là thủ phạm. Hơn nữa, ngoại lệ xảy ra một lần trên một hộp dev, chạy Windows 7. Vì vậy, nó không có vẻ như ngoại lệ là cụ thể cho Windows XP, hoặc máy tính khác (như một vấn đề bộ nhớ).

Answer 1

tôi đã có thể lặp lại trong các vấn đề nhờ this post. Vì vậy, một trong những công việc xung quanh dường như vô hiệu hoá tất cả các tooltips trong tất cả datagridview sử dụng DataGridView.ShowCellToolTips = false; Tuy nhiên, đây không phải là lý tưởng. A better work-around là để gọi

Application.EnableVisualStyles(); 

before any controls are created in the app.

Tôi đã xác nhận rằng vấn đề xảy ra cho dù DataGridView đang hiển thị chú giải công cụ tùy chỉnh (với CellToolTipTextNeeded) hay không.

Answer 2

Không chắc chắn nếu điều này sẽ được giúp đỡ, nhưng vấn đề này có vẻ là phổ biến trong các phiên bản cũ của. Net và Microsoft thậm chí phát hành một số bản sửa lỗi cho điều đó.

Một trong những sửa chữa ban đầu là như sau,

http://support.microsoft.com/kb/923028

Dưới đây là một số khác. http://support.microsoft.com/kb/975954

Answer 3

Đó không phải là dễ dàng để theo dõi/sửa chữa vì tất cả các thông tin khá "chung chung" vì vậy đây là một số gợi ý chung:

• Liệu nó luôn luôn xảy ra trên cùng một máy?
  NẾU có, thì có thể đáng để kiểm tra máy (kiểm tra bộ nhớ, vv chạy từ một đĩa CD Linux khởi động hoặc tương tự) và/hoặc chạy nó trên một máy khác để xem nó có thay đổi không ...

• Ngoại lệ dường như xảy ra khi hiển thị chú giải công cụ ... có thể cho biết sự cố với trình điều khiển cạc đồ họa ...chọn trình điều khiển khác và/hoặc độ phân giải màn hình khác v.v ... và xem điều gì xảy ra

• Bạn đang sử dụng một số thư viện của bên thứ ba phải không?
  NẾU vì vậy có thể đáng để kiểm tra chúng về các vấn đề bộ nhớ không được quản lý (ví dụ với bộ nhớ bộ nhớ ...). Kiểm tra với các nhà cung cấp (s) cho dù có phiên bản mới hơn vv
  Tôi đã có một cái gì đó trước đây một cái gì đó tương tự và nó bật ra được một rò rỉ bộ nhớ không được quản lý bên trong một số thư viện bên thứ 3 (chẩn đoán thông qua bộ nhớ profiler) ... Tôi kiểm tra với nhà cung cấp và có phiên bản cố định chạy trơn tru kể từ khi ...

Answer 4

Tôi đã quan sát vấn đề này khi gọi vào trình bao bọc C# của bên thứ ba cho một tệp C. Tôi vô hiệu hóa DEP cho C# dll, sử dụng tiện ích editbin.exe/NXCOMPAT: NO {dll name} và dường như đã khắc phục vấn đề.

Tôi CLR phải thực hiện kiểm tra bổ sung khi DEP được bật và dll C có thể đang làm điều gì đó mà CLR coi là hỏng bộ nhớ và ném lỗi này.

Bạn có thể đọc thêm về điều này tại, http://blogs.msdn.com/b/ed_maurer/archive/2007/12/14/nxcompat-and-the-c-compiler.aspx

Answer 5

Gần đây chúng tôi cũng có một AccessViolationException khi thực hiện TextBox.AppendText(). Sau khi cố gắng tái tạo vấn đề, chúng tôi nhận ra rằng TextBox không phải là vấn đề. Trong trường hợp của chúng tôi, đó là tính năng kéo và thả.

Dưới đây là một dự án tối thiểu (một mẫu với một TextBox) sẽ tái tạo các ngoại lệ:

using System; 
using System.Windows.Forms; 

namespace TestTextBoxAccessViolation { 
    public partial class Form1 : Form { 


     public Form1() { 
      InitializeComponent(); 
     } 

     private void Form1_DragEnter(object sender, DragEventArgs e) { 
      e.Effect = DragDropEffects.Copy; 
     } 

     private void Form1_DragDrop(object sender, DragEventArgs e) { 
      e.Data.GetData("DragImageBits"); 
      Form1 f = new Form1(); 
      f.textBox1.Text = "Keep resizing this window and you'll get an AccessViolationException after a while"; 
      f.Show(); 
     } 
    } 
} 

Kết luận: Không sử dụng "DragImageBits".

Answer 6

Tôi đã bị hành vi tương tự như OP. Tôi đã sửa đổi một phần của phần mềm và thêm hai phương pháp PInvoke (để cải thiện giao diện người dùng). Thật không may, tôi bắt đầu nhận được các tin nhắn tương tự như OP. Khi nhìn qua các câu trả lời, tôi tìm thấy Raja Hindustani. Khi bình luận ra hai phương pháp PInvoke, vấn đề dường như đã biến mất.

Answer 7

Tôi thấy rằng sự cố này xảy ra (sự cố) không chỉ trong WPF mà còn cho WinForms. Vấn đề của tôi liên quan đến OpenFileDialog. Thật khó để nói nguồn gốc của vấn đề là gì, nhưng vẫn có vẻ như dll Microsoft liên quan đến OpenFileDialog có lỗi (đối với tôi, đó là ComDlg32.dll)

Cách duy nhất tôi có thể gọi hàm ShowDialog() là để bọc nó trong sự kiện và gọi với sự giúp đỡ của

this.BeginInvoke(
     new Action<YourObject, EventArgs>(YourObject_FileDialogOpened), new object[] 
                 { YourObjectInstance, e }); 

nơi "this" là một Điều khiển (ví dụ: Biểu mẫu).

BeginInvoke (...) cho phép bạn gọi sẽ được xử lý theo cách thích hợp.

Sự cố sẽ không xuất hiện nếu bạn sử dụng cuộc gọi của OpenFileDialog dưới sự kiện nhấp nút hoặc bất kỳ trường hợp tương tự nào khác.