A solution for Memory Corruption exceptions caused by P/invoke in. net

1. Problem Reproduction

In the previous practice of reducing. Net memory usage, I shared with you the use of P/invoke technology in. Net to call the unmanaged code written in C ++.Code. Although the performance and memory usage are good, in the next few weeks, some colleagues' machines often encounter exceptions and cause applications.ProgramCrash, especially on some machines with better configurations. Therefore, the log record is improved, and the most caught exceptions are:

"Attempted to read or write protected memory. This is often an indication that other memory is too upt ."

Then, when debugging, the following exception cannot be directly thrown:

No meaningful information can be found based on this exception, but it is obvious that the problem lies in the called unmanaged code.

Solution 2

According to the problem prompted earlier, I checked in Google and found an articleArticleP/invoke and memory related issues this article pointed out: Because. NET is sensitive to memory crash exceptions, P/invoke is the most prone to memory exceptions. "Attempted to read or write protected memory. this is often an indication that other memory is too upt "is largely caused by the P/invoke unmanaged code, which is prone to the following two situations:

• The wrong pointer is passed in.
• An exception occurs in the unmanaged internal code, or an error occurs in the memory access within the method.

When a parameter is passed to an unmanaged method in a program, it uses string as the parameter, and the return value is brought out in the parameter by stringbuilder as the type, the Return Value of the function indicates whether the method is successfully executed. The passed value is correct. The stringbuilder of the outgoing value has allocated enough space when it starts calling.

So I started to check whether an exception exists in the unmanaged code. So I started to try catch on each method in C ++ to check whether exceptions can be caught and try to recover, the application is not suspended, but the exception handling in C ++ is not similar. net, the memory is damaged, and it is very difficult to recover from it, causing the program to crash directly. Since I am not familiar with C ++, many methods have been written after I take a book temporarily, so in order to completely solve this problem, I went to consult my colleagues who know C ++ well and found no problems.

After struggling for a while, I finally thought about whether there was a problem in concurrency, because this exception is easy to generate during continuous requests, and it is easy to generate on a machine with better configuration. So I want to lock the access to the method. At the beginning, I thought about adding a lock to C ++. Later I thought about how to apply a lock directly to the place where the P/invoke method is called. Therefore, the solution is simple. define a global lock.

 
Public static volatile objectSeculock =New Object();
 

Then, lock all the calls to the methods in the same Unmanaged DLL, and solve the problem.

Lock(Severcallback. Seculock) {emgfindsecu ("300", Result );}
 

Cause 3

Because I have defined a global set variable in an unmanaged DLL, multiple methods will query or modify the global variable. In some specific situations, two unmanaged methods in the same dll will be called at the same time, so that these two methods will operate on a collection object at the same time, then the above exception will be thrown in C ++, after the exception is caught, it seems that the recovery is not good, so it will directly cause the application to crash. Therefore, when applying P/invoke, if the above exception information is displayed, It is not prevented to lock methods that may operate on the same set object in the unmanaged DLL method. At a certain time point, only one of these methods is allowed to operate on it.

P/invoke is. net is a very powerful feature that enables us to efficiently interoperate with non-managed code and is easy to use, but it is also prone to exceptions during use, not only are these exceptions hard to handle and recover, but in most cases our applications will crash directly. I hope this article will help you solve similar problems in. Net P/invoke.