"Unhandled Exception: System.AccessViolationException: Attempted
to read or write protected memory. This is often an indication that
other memory is corrupt”
This issue shouldn't happen in managed code. You can try setting Visual Studio Debugger to bypass this exception:
Tools menu ->Options -> Debugging -> General -> Uncheck this option "Suppress JIT optimization on module load"
Also you can check this case about some instruction, which discussed the similar issue to yours.
http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/6adca20b-649f-41a4-8fa1-09534882d76c
The problem is typically caused by some component (typically unmanaged, but can also be a bad P/Invoke signature) that corrupts the program's memory. You often see differences between debug and release builds because debug builds contain extra metadata to assist in debugging. In debug mode, the corruption will kill some debug metadata, which will only cause you to see spurious debugging information, but not cause the program to crash. In release, the debug data is not present and the error overwrites critical data such as return addresses, which will cause the program to crash. You will also see small changes (like changing compiler optimizations, or re-ordering instructions) cause code to start working. What you've done is mask the problem. The memory corruption is still occuring, it's just not occuring to a critical piece of memory such as a return address. You will likely see it re-appear later as you continue modifying the code.
This is honestly a brutal class of problems to diagnose because they're only present when you don't have debug information. Some suggestions:
1. Try turning on all optimizations, run the program under the debugger, and see if the error occurs. (Typically all optimizations are turned off in debug mode so that debugging is easier.) This will at least give you a way to reproduce the error when you have more debug information. This honestly won't help you a whole lot because by the time you crash, the method call that corrupted the memory is long gone.
2. Look at all unmanaged code that you're calling: COM objects, C/C++ DLLs, Win32 calls, etc. Check the P/Invoke signatures and COM interop thunks for all unmanaged code to verify that they're correct. Don't trust P/Invoke signatures that you find on the 'net. They're not always correct. Verify for yourself that your data types and parameter orderings are correct.
3. Try removing the unmanaged code (stub out the calls) and see if the problem goes away. If it does, investigate the component to verify that it is free of memory leaks. (Note that you might only be masking the problem as you re-arrange code.)
4. Try running your code under a unmanaged memory checker like Compuware BoundsChecker, which will look for memory leaks and access violations. This will likely give you some hints as to which unmanaged component is misbehaving.
This issue shouldn't happen in managed code. You can try setting Visual Studio Debugger to bypass this exception:
Tools menu ->Options -> Debugging -> General -> Uncheck this option "Suppress JIT optimization on module load"
Also you can check this case about some instruction, which discussed the similar issue to yours.
http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/6adca20b-649f-41a4-8fa1-09534882d76c
The problem is typically caused by some component (typically unmanaged, but can also be a bad P/Invoke signature) that corrupts the program's memory. You often see differences between debug and release builds because debug builds contain extra metadata to assist in debugging. In debug mode, the corruption will kill some debug metadata, which will only cause you to see spurious debugging information, but not cause the program to crash. In release, the debug data is not present and the error overwrites critical data such as return addresses, which will cause the program to crash. You will also see small changes (like changing compiler optimizations, or re-ordering instructions) cause code to start working. What you've done is mask the problem. The memory corruption is still occuring, it's just not occuring to a critical piece of memory such as a return address. You will likely see it re-appear later as you continue modifying the code.
This is honestly a brutal class of problems to diagnose because they're only present when you don't have debug information. Some suggestions:
1. Try turning on all optimizations, run the program under the debugger, and see if the error occurs. (Typically all optimizations are turned off in debug mode so that debugging is easier.) This will at least give you a way to reproduce the error when you have more debug information. This honestly won't help you a whole lot because by the time you crash, the method call that corrupted the memory is long gone.
2. Look at all unmanaged code that you're calling: COM objects, C/C++ DLLs, Win32 calls, etc. Check the P/Invoke signatures and COM interop thunks for all unmanaged code to verify that they're correct. Don't trust P/Invoke signatures that you find on the 'net. They're not always correct. Verify for yourself that your data types and parameter orderings are correct.
3. Try removing the unmanaged code (stub out the calls) and see if the problem goes away. If it does, investigate the component to verify that it is free of memory leaks. (Note that you might only be masking the problem as you re-arrange code.)
4. Try running your code under a unmanaged memory checker like Compuware BoundsChecker, which will look for memory leaks and access violations. This will likely give you some hints as to which unmanaged component is misbehaving.
No comments:
Post a Comment