Đã cố đọc hoặc ghi bộ nhớ được bảo vệ. Đây thường là một dấu hiệu cho thấy bộ nhớ khác bị hỏng

Tôi hy vọng ai đó có thể khai sáng cho tôi về những gì có thể gây ra lỗi này:

Đã cố đọc hoặc ghi bộ nhớ được bảo vệ. Đây thường là một dấu hiệu cho thấy bộ nhớ khác bị hỏng.

Tôi thực sự không thể đăng mã vì lỗi này dường như bị ném vào bất kỳ khu vực ngẫu nhiên nào của ứng dụng. Ứng dụng sẽ chạy bất cứ nơi nào từ 12-48 giờ trước khi ném lỗi. Đôi khi, nó sẽ dừng ở một điểm có vẻ ngẫu nhiên và gây ra lỗi ở trên, lần khác toàn bộ ứng dụng dừng lại và tôi nhận được một màn hình có lỗi thông báo "Có lỗi nghiêm trọng trong ... Đây có thể là một lỗi nghiêm trọng lỗi trong CLR hoặc ... "một cái gì đó về PInvoke hoặc thông tin không liên quan khác. Khi điều này xảy ra, tất cả các chủ đề hiển thị bị chấm dứt và không có thông tin gỡ lỗi có sẵn.

Tóm lại, đây là những gì ứng dụng làm:

Đây là một ứng dụng máy chủ đa luồng được viết hoàn toàn bằng C #. Khách hàng kết nối với máy chủ thông qua ổ cắm. Máy chủ chạy một "môi trường" ảo cho các máy khách nơi chúng có thể tương tác với nhau và môi trường. Nó tiêu tốn khá nhiều bộ nhớ nhưng tôi không thấy nó bị rò rỉ. Nó thường tiêu thụ khoảng 1,5 GB. Tôi không nghĩ nó bị rò rỉ vì việc sử dụng bộ nhớ vẫn tương đối ổn định trong toàn bộ thời gian ứng dụng đang chạy. Mã liên tục chạy của nó để duy trì môi trường ngay cả khi khách hàng không làm gì cả. Nó không sử dụng phần mềm của bên thứ 3 hoặc các API khác. Tài nguyên bên ngoài duy nhất mà ứng dụng này sử dụng là kết nối ổ cắm và kết nối cơ sở dữ liệu SQL. Nó chạy trên máy chủ 64 bit. Tôi đã thử gỡ lỗi này trong VS2008 & VS2010 bằng cách sử dụng .net 2.0, 3.5 và 4.

Tôi đã thử tắt tối ưu hóa trình biên dịch và một số bản sửa lỗi nóng microsoft. Dường như không có gì làm cho vấn đề này biến mất. Nó sẽ được đánh giá cao nếu bất cứ ai biết bất kỳ nguyên nhân có thể, hoặc một số cách để xác định những gì gây ra vấn đề.

Tôi vừa gặp vấn đề này trong VS 2013 .NET 4.5 với một MapInfo DLL. Hóa ra, vấn đề là tôi đã thay đổi Nền tảng cho Build từ x86 thành Bất kỳ CPU nào và điều đó đủ để gây ra lỗi này. Thay đổi nó trở lại x86 đã thực hiện thủ thuật. Có thể giúp ai đó.

Tôi cũng gặp phải vấn đề này với Visual Studio (VS) 2010. Thú vị hơn, tôi đã có một vài dự án trong giải pháp của mình (ứng dụng Console, ứng dụng WPF, ứng dụng Windows Forms) nhưng chỉ thất bại khi tôi cài đặt loại "Ứng dụng Console" của dự án là dự án khởi động của giải pháp (Ngay cả đối với những dự án không có mã hoặc bất kỳ tập hợp bổ sung nào được gọi ngoài các dự án mặc định đi kèm với chính mẫu dự án).

Sau sự thay đổi cuối cùng đã giúp tôi đinh xuống vấn đề: Đến bất động sản dự án của dự án giao diện điều khiển ứng dụng (Hoặc, chọn tập tin dự án trong solution explorer và nhấn Alt+ Entertổ hợp phím) -> Đến Debugtab -> Di chuyển đến Enable Debuggersmục trong cửa sổ bên phải -> Kiểm tra các Enable unmanaged code debugginghộp kiểm tra như trong ảnh chụp dưới đây -> Click vào Floppynút trên thanh công cụ để tiết kiệm tài sản của dự án. Nguyên nhân gốc rễ tại sao nó xảy ra vẫn chưa được biết đến với tôi. Điều duy nhất tôi quan sát được là có rất nhiều bản cập nhật Windows đã được cài đặt trên máy của tôi vào đêm hôm trước, phần lớn được cấu thành từ các bản cập nhật văn phòng và cập nhật hệ điều hành (Hơn một tá bài viết KB).

Cập nhật : VS 2017 trở đi, tên cài đặt đã thay đổi như trong ảnh chụp màn hình bên dưới:

Cuối cùng đã theo dõi điều này với sự giúp đỡ của WinDBG và SOS. Vi phạm truy cập đã bị ném bởi một số DLL không xác định. Hóa ra một phần mềm gọi là "Nvidia Network Manager" đã gây ra sự cố. Tôi đã đọc vô số lần vấn đề này có thể gây ra bởi tường lửa hoặc phần mềm chống vi-rút, tôi không sử dụng vì vậy tôi đã loại bỏ ý tưởng này. Ngoài ra, tôi đã giả định rằng đó không phải là môi trường vì nó xảy ra trên hơn 1 máy chủ sử dụng phần cứng khác nhau. Hóa ra tất cả các máy tôi đã thử nghiệm này đều đang chạy "Trình quản lý mạng NVidia". Tôi tin rằng nó cài đặt với phần còn lại của trình điều khiển bo mạch chủ.

Hy vọng rằng điều này sẽ giúp được ai đó vì vấn đề này đã gây khó chịu cho ứng dụng của tôi trong một thời gian rất dài.

Vấn đề có thể là do các nền tảng xây dựng DLL hỗn hợp trong dự án. tức là Bạn xây dựng dự án của mình thành Bất kỳ CPU nào nhưng có một số DLL trong dự án đã được xây dựng cho nền tảng x86. Những điều này sẽ gây ra sự cố ngẫu nhiên do ánh xạ bộ nhớ khác nhau của kiến ​​trúc 32 bit và 64 bit. Nếu tất cả các DLL được xây dựng cho một nền tảng, vấn đề có thể được giải quyết.

Cố gắng chạy lệnh này

thiết lập lại winh

Nguồn: https://stackoverflow.com/a/20492181/1057791

Lỗi này không nên xảy ra trong mã được quản lý. Điều này có thể giải quyết vấn đề:

Truy cập Visual Studio Debugger để bỏ qua ngoại lệ này:

Tools menu ->Options -> Debugging -> General -> Uncheck this option "Suppress JIT optimization on module load"

Hy vọng nó sẽ giúp.

Tôi đã chạy vào, và tìm thấy một giải pháp cho ngoại lệ này ngày hôm nay. Nó đã xảy ra khi tôi đang cố gắng gỡ lỗi một bài kiểm tra đơn vị (NUnit) được gọi là phương thức ảo trên một lớp trừu tượng.

Vấn đề dường như là với cài đặt .NET 4.5.1.

Tôi đã tải xuống .NET 4.5.2 và cài đặt (các dự án của tôi vẫn tham chiếu .NET 4.5.1) và vấn đề được giải quyết.

Nguồn giải pháp:

https://connect.microsoft.com/VisualStudio/feedback/details/819552/visual-studio-debugger-throws-accessviolationexception

Nó có thể là phần cứng. Nó có thể là một cái gì đó phức tạp ... nhưng tôi sẽ cố gắng đề xuất rằng ở đâu đó mã luồng của bạn không bảo vệ một số bộ sưu tập (chẳng hạn như một từ điển) với một khóa thích hợp.

Hệ điều hành và gói dịch vụ nào bạn đang chạy?

Tôi đã gặp vấn đề này gần đây khi tôi thay đổi máy chủ phát triển cho một dự án. Tôi đã gặp lỗi này trên dòng mã nơi tôi đã khai báo một biến OracleConnection mới.

Sau khi thử nhiều thứ, bao gồm cài đặt hotfix, tôi đã thử thay đổi các tham chiếu Oracle.DataAccess và System.Data.OracleClient trong dự án và nó đã hoạt động!

Khi một dự án được chuyển sang một máy mới, tôi khuyên bạn nên gia hạn tất cả các tài liệu tham khảo được thêm vào trong dự án đó.

Bạn đã thử tắt DEP (Ngăn chặn thực thi dữ liệu) cho ứng dụng của mình chưa?

Tôi phải đối mặt với cùng một vấn đề. Mã của tôi là .NET dll (tiện ích mở rộng AutoCAD) chạy bên trong AutoCAD 2012. Tôi cũng đang sử dụng Oracle.DataAccess và mã của tôi đã ném ngoại lệ tương tự trong ExecuteNonQuery (). Tôi may mắn giải quyết vấn đề này bằng cách thay đổi phiên bản .net của ODP mà tôi đang sử dụng (nghĩa là 2.x của Oracle.DataAccess)

Vấn đề này gần như là một vấn đề đơn giản. Mã là xấu. Nó hiếm khi là các công cụ, chỉ từ một phân tích thống kê. Hàng triệu người đang sử dụng Visual Studio mỗi ngày và có thể một số ít đang sử dụng mã của bạn - bit nào của mã đang được thử nghiệm tốt hơn? Tôi đảm bảo rằng, nếu đây là một vấn đề với VS, có lẽ chúng tôi đã tìm thấy nó.

Điều mà câu nói có nghĩa là, khi bạn cố truy cập vào bộ nhớ không phải của bạn, thường là do bạn đang thực hiện nó với một con trỏ bị hỏng, xuất phát từ một nơi khác. Đó là lý do tại sao nó nêu rõ chỉ dẫn.

Với lỗi bộ nhớ, việc bắt lỗi hiếm khi ở gần nguyên nhân gốc của lỗi. Và các hiệu ứng là chính xác những gì bạn mô tả, dường như ngẫu nhiên. Bạn sẽ chỉ cần nhìn vào các thủ phạm thông thường, như:

• con trỏ chưa được khởi tạo hoặc các giá trị khác.
• viết nhiều hơn vào một bộ đệm hơn kích thước của nó.
• tài nguyên được chia sẻ bởi các chủ đề không được bảo vệ bởi mutexes.

Làm việc ngược từ một vấn đề như thế này để tìm ra nguyên nhân gốc rễ là vô cùng khó khăn khi có rất nhiều điều có thể xảy ra giữa việc tạo ra vấn đề và phát hiện vấn đề.

Tôi chủ yếu tìm thấy nó dễ dàng hơn để có một cái nhìn vào những gì là tham nhũng (nói, một con trỏ cụ thể) và sau đó làm thủ công phân tích tĩnh của mã để xem những gì có thể đã bị hỏng nó, kiểm tra thủ phạm thông thường như trình bày ở trên. Tuy nhiên, ngay cả điều này sẽ không bắt được chuỗi vấn đề dài.

Tôi không đủ quen thuộc với VS để biết nhưng bạn cũng có thể muốn xem xét khả năng sử dụng công cụ theo dõi bộ nhớ (như valgrind cho Linux) để xem liệu nó có thể phát hiện bất kỳ vấn đề rõ ràng nào không.

Mã có thể xác minh sẽ không thể làm hỏng bộ nhớ, do đó, có điều gì đó không an toàn đang diễn ra. Bạn có đang sử dụng bất kỳ mã không an toàn ở bất cứ đâu, chẳng hạn như trong xử lý bộ đệm? Ngoài ra, những thứ về PInvoke có thể không liên quan, vì PInvoke liên quan đến việc chuyển đổi sang mã không được quản lý và liên quan đến việc sắp xếp.

Đề xuất tốt nhất của tôi là đính kèm với một cá thể bị sự cố và sử dụng WinDBG và SOS để tìm hiểu sâu hơn về những gì đang xảy ra tại thời điểm xảy ra sự cố. Điều này không dành cho người yếu tim, nhưng tại thời điểm này, bạn có thể cần phải tìm ra các công cụ mạnh hơn để xác định chính xác điều gì đang xảy ra.

Ok, điều này có thể khá vô dụng và chỉ đơn giản là giai thoại, nhưng ...

Ngoại lệ này đã bị ném một cách nhất quán bởi một số thư viện Twain32 mà chúng tôi đang sử dụng trong dự án của tôi, nhưng sẽ chỉ xảy ra trong máy của tôi.

Tôi đã thử rất nhiều giải pháp được đề xuất trên internet, nhưng không có kết quả ... Cho đến khi tôi rút điện thoại ra (nó được kết nối qua USB).

Va no đa hoạt động.

Hóa ra các thư viện Twain32 đang cố liệt kê điện thoại của tôi là một thiết bị tương thích với Twain và một cái gì đó trong quá trình đó đã gây ra ngoại lệ đó.

Đi nào ...

Tôi đã gặp lỗi này khi sử dụng pinvoke trên một phương thức có tham chiếu đến a StringBuilder. Tôi đã sử dụng hàm tạo mặc định mà dường như chỉ cấp phát 16 byte. Windows đã cố gắng đặt hơn 16 byte vào bộ đệm và gây ra lỗi tràn bộ đệm.

Thay vì

StringBuilder windowText = new StringBuilder(); // Probable overflow of default capacity (16)

Sử dụng công suất lớn hơn:

StringBuilder windowText = new StringBuilder(3000);

trong trường hợp của tôi, tập tin đã được mở và do đó bị khóa.

Tôi đã nhận được nó khi cố tải một tệp Excel bằng LinqToExcel cũng được mở trong Excel.

đây là tất cả những gì tôi đã làm

    var maps = from f in book.Worksheet<NavMapping>()
                select f;
    try {
        foreach (var m in maps)
            if (!string.IsNullOrEmpty(m.SSS_ID) && _mappings.ContainsKey(m.SSS_ID))
                _mappings.Add(m.SSS_ID, m.CDS_ID);
    } catch (AccessViolationException ex) {
        _logger.Error("mapping file error. most likely this file is locked or open. " + ex);
    }

Tôi đã gặp lỗi tương tự trong một dự án tôi đang làm việc với VB.NET. Kiểm tra "Kích hoạt khung ứng dụng" trên trang thuộc tính đã giải quyết nó cho tôi.

Tôi cũng có vấn đề này . Tôi đã chạy các giải pháp khác nhau cùng một lúc bằng cách sử dụng visual studio, khi đóng các giải pháp khác và chỉ chạy giải pháp đích, nó hoạt động tốt mà không gặp lỗi đó.

Đã gặp lỗi này một cách ngẫu nhiên trong VS1017, khi cố gắng xây dựng một dự án đang xây dựng hoàn toàn tốt vào ngày hôm trước. Khởi động lại PC đã khắc phục sự cố đã hoạt động (Tôi cũng đã chạy lệnh sau đây, không chắc chắn nếu nó được yêu cầu: Netsh winock reset)

Câu trả lời của tôi phụ thuộc rất nhiều vào kịch bản của bạn, nhưng chúng tôi đã gặp sự cố khi nâng cấp ứng dụng .NET cho máy khách> 10 tuổi để họ có thể làm cho nó hoạt động trên Windows 8.1. Câu trả lời của @ alhazen là loại trong sân bóng chính xác đối với tôi. Ứng dụng này dựa vào DLL của bên thứ ba mà khách hàng không muốn trả tiền để cập nhật (Pegasus / Accusoft ImagXpress). Chúng tôi đã nhắm mục tiêu lại ứng dụng cho .NET 4.5 nhưng mỗi lần thực hiện dòng sau chúng tôi lại nhận được AccessViolationException was unhandledthông báo:

UnlockPICImagXpress.PS_Unlock (1908228217,373714400,1341834561,28447);

Để khắc phục, chúng tôi đã phải thêm sự kiện hậu xây dựng sau vào dự án:

call "$(DevEnvDir)..\tools\vsvars32.bat"
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\amd64\editbin.exe" /NXCOMPAT:NO "$(TargetPath)"

Điều này chỉ định rõ ràng việc thực thi là không tương thích với Ngăn chặn thực thi dữ liệu. Để biết thêm chi tiết xem tại đây .

Trong một số trường hợp, điều này có thể xảy ra khi:

obj = new obj();
...
obj.Dispose();  // <-----------------    Incorrect disposal causes it
obj.abc...

Trong trường hợp của tôi, tôi đã phải tham chiếu thư viện C / C ++ bằng P / Invoke, nhưng tôi phải đảm bảo rằng bộ nhớ được phân bổ cho mảng đầu ra bằng cách sử dụng fixed:

[DllImport("my_c_func_lib.dll", CharSet = CharSet.Ansi)]
public static extern unsafe int my_c_func(double input1, double input2, double pinput3, double *outData);

    public unsafe double[] GetMyUnmanagedCodeValue(double input1, double input2, double input3)
    {
        double[] outData = new double[24];

        fixed (double* returnValue = outData)
        {
            my_c_func(input1, input2, pinput3, returnValue);
        }

        return outData;
    }

Để biết chi tiết, vui lòng xem: https://www.c-sharpcorner.com/article/pointers-in-C-Sharp/

Điều này đã xảy ra với tôi khi tôi gỡ lỗi ứng dụng C # WinForms của mình trong Visual Studio. Ứng dụng của tôi thực hiện các cuộc gọi đến nội dung Win32 thông qua DLLImport, vd

[DllImport("Secur32.dll", SetLastError = false)]
private static extern uint LsaEnumerateLogonSessions(out UInt64 LogonSessionCount, out IntPtr LogonSessionList);

Chạy Visual Studio "với tư cách là Quản trị viên" đã giải quyết vấn đề cho tôi.

Tôi đã có thông báo lỗi tương tự:

System.AccessViolationException: Đã cố đọc hoặc ghi bộ nhớ được bảo vệ. Đây thường là một dấu hiệu cho thấy bộ nhớ khác bị hỏng.

Trong trường hợp của tôi, lỗi đã biến mất sau khi dọn dẹp và xây dựng lại giải pháp.

Trong trường hợp của tôi, tiện ích FTDI FT Prog đã gặp lỗi khi quét các thiết bị USB. Rút tai nghe Bluetooth của tôi khỏi PC đã khắc phục sự cố.

Tôi nhận được thông báo lỗi này trên biểu thức lambda đang sử dụng Linq để lọc một bộ sưu tập các đối tượng. Khi tôi kiểm tra bộ sưu tập tôi nhận thấy rằng các thành viên của nó không có dân cư - trong Localscửa sổ, việc mở rộng chúng chỉ hiển thị "...". Cuối cùng, vấn đề nằm ở phương thức lưu trữ ban đầu đã tạo ra bộ sưu tập - Dapper đang cố gắng tự động ánh xạ một thuộc tính của một đối tượng lồng nhau. Tôi đã sửa lỗi truy vấn Dapper để xử lý đa ánh xạ và nó đã sửa lỗi bộ nhớ.