I’m suffering a frustrating error for the last two weeks in a vb.net application developed for my company.
The application consists of a basic interface (Windows Form Application) to get some data (file paths and coordinates) and then processes a lot of information coming from a steel structure modelled in an external application called Staad.Pro (very common in the Oil & Gas sector) and from several Excel files.
So it gets external information from two sources:
The application has been used satisfactorily for three years. I recently made some changes to introduce the background process of the data and the definition of the configuration for every project company using an external Excel file, which was previously defined at code level.
This configuration file is read directly in Excel opening an application instance (Excel), while the others Excel files are opened using ADO as I said previously. At the same time, the configuration file path is defined in a single text file, that it is always used by the application to read that path, which content can be modified using the application through an OpenFileDialog
object.
I specify in particular those points because they are the changes I made before the error occurrence. There have been also two weeks of inactivity because of my holidays, during which some Windows updates have been released (I suppose some of them are related to the popular ransomware Wannacry and Petya).
So the error message I get running the application in VS Community 2015 is the following:
An unhandled exception of type 'System.AccessViolationException' occurred in mscorlib.dll.
Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
It appears when the application opens the second ADO connectionn to an Excel file with the following code:
cnn1.Open("Provider=Microsoft.ace.OLEDB.12.0;" &
"Data Source=" & rutaarchivo & ";" &
"Extended Properties=""Excel 12.0;HDR=Yes"";")
The first connection is closed and the corresponding object is set to Nothing
. I changed the way of access to this file trying to understand the error, avoiding ADO, but the error arises again in a later connection to another Excel file with ADO, that is again the second ADO connection after the changes.
The error arises randomly, in such a way that when the project is just opened in VS Community 2015 and then it is run for the first time, no error appears (usually), but it does after a second execution.
Other times the error arises at the call to the subroutine that makes the ADO connection to the Excel file, not at the code of the subroutine itself, with a different message:
Managed Debugging Assistant 'FatalExecutionEngineError' has detected a problem in (path).
Additional Information: The runtime has encountered a fatal error. The address of the error was at 0x79f387d1, on thread 0x168c. The error code is 0xc0000005. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.
When looking for an error pattern I found another error that appears when I use for the second time the same type of object of the library openstaad.dll, with the following message:
An exception of type 'System.Runtime.InteropServices.COMException' occurred in Microsoft.VisualBasic.dll but was not handled in user code Additional information: La memoria está bloqueada. (Excepción de HRESULT: 0x8002000D (DISP_E_ARRAYISLOCKED))
I’ve found two main articles on the internet about this error (System.AccessViolationException):
Programs randomly getting System.AccessViolationException
https://www.codeproject.com/Questions/106826/OpenFileDialog-OleDbConnection-AccessViolationExce
I’ve tried to reinstall Access Database Engine, to define the environment variable that is mentioned and to change the .NET Framework version. Nothing works.
Any help to solve this problem will be appreciated.
Alberto Ruiz
I experienced the same error recently after the second use of an Microsoft.ACE.OLEDB.12.0 connection, to MS Access in this case.
What helped for me was wrapping the connection in a new Thread.
For example: if your problematic code that opens the connection is in method OpenExcel
you could do the following:
(new Thread(() => OpenExcel())).Start();
Hope this helps.
User contributions licensed under CC BY-SA 3.0