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:
A Staad.Pro file, through the library openstaad.dll,distributed with
Staad.Pro.
Some Excel files, through the ADO Connection and Recordset objects.
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.
Related
I have an old Access solution that includes opening a connection and inserting some lines in a SQL database. I had to make a very small change that had nothing to do with that connection. After the change I compacted the database.
The solution works normally for me, but the person that normally runs it is getting the Run-time error I outlined in the subject. I had another user try and also got this error. It seems I am now the only one that can run this, yet I did nothing to the code or the access db as a whole that I can see explaining this.
The button they press that triggers the error:
Sets a variable as ADODB.Connection
Defines the connection string
ERROR TIME: Then it runs a function that executes a stored procedure using that connection. The error point is showing as occurring at the top of that function, when it attempts to CreateObject("ADODB.Command").
Run-time error '429': ActiveX component can't create object
Can anyone offer anything as to why this user that could work with it suddenly can't despite the same security, same machine, etc.
Sigh... Thanks for the responses. It turns out to be our security software and the fact that I moved the solution to a different location. Out of sight out of mind. I forget that I have some exemptions setup for myself, so I didn't see how it could be that. I just need to learn to check that stuff first.
I am trying to create a word document using visual basic. I have found that this can be done using the Microsoft.Office.Interop.Word objects.
I have found some tutorials online (https://support.microsoft.com/en-us/kb/316384) about how to create a word document programmatically.
I have created a simple windows form application. When a button is clicked the word document will be created. I made sure to add the reference to Microsoft.Office.Interop.Word in my application.
My problem is that an error keeps getting thrown at this point:
app = New Microsoft.Office.Interop.Word.Application
The error is:
COMException occurred
A first chance exception of type 'System.Runtime.InteropServices.COMException' occurred in mscorlib.dll
Additional information: Retrieving the COM class factory for component with CLSID (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) failed due to the following error: 80080005 Server execution failed (Exception from HRESULT: ox80080005 (COE_SERVER EXEC FAILURE)).
I have read that the following needs to be done, so I have made sure that word 2013 is installed on my machine and I have set the target CPU to x64 inside the application's properties.
If anyone has any insight to what I am missing or if I am doing something wrong I would appreciate the help.
Update:
I have tested my code on another machine and it works. So the source of this error is not the code.
Update: Pt. 2
I've been doing some more research (http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Windows+Operating+System&ProdVer=5.2&EvtID=10010&EvtSrc=DCOM&LCID=1033) and I believe I may be getting closer to the source of the problem. I've gone into the registry and it seems that the local server it is failing to communicate with is pointing to WINWORD.exe which makes sense. What does not make sense is that it is looking for the wrong WINWORD.exe. I am going to try and fix this so it is pointing to the WINWORD.exe for Word 2013 instead of Word 2010.
Solution
What ended up fixing my problem was preforming a quick repair on office. I went to control panel, programs and features, selected office, pressed the change button, and selected quick repair. Do not know what caused things to get messed up, but this did fix my problem.
Where do you run the code? Is it a Windows service or ASP.NET application?
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article.
You may find existing threads with the same issue described:
System.Runtime.InteropServices.COMException (0x80080005): Retrieving the COM class factory for component with CLSID
Office Automation in .NET - COMException 80080005
Word Automation with ASP.NET
Finally, if all the mentioned information is not relevant to your case I'd suggest repairing Office. It looks like something is wrong with its windows registry keys.
Good morning.
I'm in the process of writing a vb.NET forms application that will read in a selection of .xlsX files and import their contents into a SQL2012 database. Because the files are in different folders and are all formatted differently, I'm having to write it so that each folder's contents is handled by its own dedicated module. However, one thing that's common across each folder is the process that I need to go through, which is to open each file, read its contents into a DataTable, carry out any manipulation required (i.e. removing empty rows) and then run a SqlBulkCopy to load the data into SQL before moving the original file into an archive location.
So far, so good. I've written and successfully run three of these modules, but the fourth one is giving me the error that's detailed in the Title of this post - the exception is thrown at the point where I'm trying to open the connection string to the Excel object. Again I stress that I've done this three times before, and each time has been successful.
Also, I've noticed that the exception only occurs when running the code in Debug mode. If I run it in Release mode it works without any complaints.
I'm developing this application in a 64-bit environment (VS2010 on Windows 8.1), but targeting the application to x86. I'm happy to continue writing in Release rather than Debug mode, but I'm curious as to why it works in one but not the other and I'd like to be able to code for both modes if at all possible.
TIA
I developed a small application which accesses a MS access database on my computer using VB.net. I developed the program on windows xp 32 bit. At the moment I am using windows 7 64 bit and the program simply will not run. I get a null reference exception when I try to do anything to the database. I have narrowed this down i THINK to the db provider. I was using Provider=Microsoft.Jet.OLEDB.4.0; and tried using Provider=Microsoft.ACE.OLEDB.12.0;. Neither seems to work. The path to my database is 100% correct. This is the error I am getting:
Null reference exception was unhandled.
Object reference not set to an instance of an object.
Like I say the program runs fine on the windows xp machine. If it helps the access database file extension is mdb.
No DLL exist for 64 bit access to Access database files so you must go to the project properties and on the "Compile" tab go to "Advanced Compile Options" and set "Target CPU" to "x86" I hope this helps.
I was having the exact same problem, except writing to a SQL 2008 DB. VS2008, VB.net code with framework 3.5, Windows 7 64-bit. Code runs fine on XP.
John R's answer provided the right solution: changing the project's advanced compile options to set "Target CPU" to "x86".
This problem can have more symptoms than originally described. I'll generalize them:
Accessing ACCESS isn't the only problem; it happens with SQL (at least MS SQL 2008) too.
Some of the DB calls can and do work. It's as if the calls set you up for failure, but the point of failure happens later, at a random point in your program.
The point of failure I saw was during a subroutine call. (just a normal call to a subroutine I created in VB.) Putting a try-catch block around the call wouldn't catch the error though.
Here's the strangest part: Previous to the errant subroutine call, the code had a HANDLED exception. Ironically, the exception was EXACTLY what was being thrown at the errant call. When I "tweaked" the code to avoid the prior exception, NO exception was thrown at the errant call; the VB program JUST QUIT WITH NO ERROR! It appears that whatever code is having the problem, it is reusing the last handled exception. This would mean that if your code previously had an "index out of bounds" or "divide by 0" error, this is what you'd (probably) see when the code barfs (because of no 64-bit dll.) So this problem can masquerade as a whole bunch of errors!
Doesn't sound like a Provider error because the Jet part is fine. Make sure your Data Source path is correct. If you have it in your Projects folder on VS and are using a full path it may need to change because of how the file system is set up with Users vs Documents and Settings.
My Application (Vb.net, Access 2003/2007) is to scan Access Database files for activex controls and to generate report accordingly.
Problem:
Getting an error like:
"Insufficient memory to continue the execution of the program."
The above error occurs while scanning for older version of Access files like prior to office 2000.
And the line of code where I get this is as follows:
Dim oForm As Access.Form
Dim oAccess as Access.Application
oForm = oAccess.Forms(objForms.Name)
But it opens the file and form as well.
Need Help:
Whether it is possible to read the file (Access Forms and Reports) or not?
Please provide me reference or any solution.
You appear to doing COM automation of Access to open the forms and then cycle through their controls looking for certain properties.
Another solution would also involve automating Access, but it wouldn't require actually opening the form, and that's the undocumented Application.SaveAsText command. You'd do something like this:
Application.Saveastext acForm, "dlgWebBrowser", _
"C:\Output\dlgWebBrowser.txt"
You would then have to figure out how ActiveX controls are described in that file. If that file looks like the code for a VB form, that's because that's precisely what it is.
The example above had an IE web browser control on it, and after a dump of OLE data, it had this in it:
OLEClass ="Microsoft Web Browser"
Class ="Shell.Explorer.2"
GUID = Begin
0x54c1ea41936d2046b9dc5b29905976e3
End
I would expect that all ActiveX controls will have an OLEClass, but I non-native avoid ActiveX controls on principle because of the problems they can cause if not properly installed when you try to run the app.
In fact, that could be the source of the problem -- if you open the Access form on a machine that doesn't have the relevant ActiveX control registered, it's going to fail, and the form won't open.
My bet is that Application.SaveAsText is going to sidestep that problem entirely, since the form doesn't have to be opened.
I've seen behaviour very similar to this before. Access 97 files will sometimes report an 'out of memory' error if you try to open them on a computer with more than (I think) 1Gb of RAM. The error doesn't always manifest itself immediately - sometimes the project can appear to run normally but crash when you try to open a particularly large object.
In the case where we did run into this the users were running an old Access 97 database on new XP machines they'd been upgraded to with modern amounts of RAM. Tech support for the company tried everything they could think of - including complete office reinstalls, applying all patches etc. but eventually had to resort to removing RAM from the computers - whereupon the errors went away and everything was rock solid again. I am uncertain as to the exact cause, but it will be connected with memory management in the Access 97 file format (I believe the error is on MSDN somewhere but I wasn't directly involved with Tech support hunting the solution down - I'd just written the application many years before)
I'd suggest you're only way out is to use a special, low memory, PC to run the application.