AccessViolationException using System.Data.OleDb #981
Comments
Dotnet-GitSync-Bot
added
area-System.Data
untriaged
|
I wonder whether you could get more callstack out of a native debugger? Probably this is all there is, but worth a try? |
|
@danmosemsft Here is the output from windbg command window: .net core 3.1 sample project including foxpro-Database attached: Visua FoxPro oledb driver downloaded from: Please let me know if you need further infos. |
|
From the source code it seems you're tryjng to update "da" object after using block is closed? Could you place it inside using block and try again plz? using (OleDbConnection oledbConn = new OleDbConnection(@"Provider=vfpoledb;Data Source=d:\temp\dbfile.dbf;Collating Sequence = machine;")) {
oledbConn.Open();
using (OleDbDataAdapter da = new OleDbDataAdapter($"select * from dbfile.dbf", oledbConn)) {
OleDbCommandBuilder cb = new OleDbCommandBuilder(da);
da.InsertCommand = cb.GetInsertCommand();
DataTable dt = new DataTable();
da.Fill(dt);
var customerRow = dt.NewRow();
//Fill columns
dt.Rows.Add(customerRow);
da.Update(dt);
}
} |
@cheenamalhotra: aah, sorry. my mistake while formatting the code in github. initial comment was updated and thanks for the hint. |
|
I tested using a LocalDB database and OLE DB Driver for SQL Server and got a error too. "Provider=MSOLEDBSQL;Server=(localdb)\MSSQLLocalDB;Database=SarathlalDb;DataTypeCompatibility=80;Integrated Security=SSPI; " System.AccessViolationException: 'Attempted to read or write protected memory. This is often an indication that other memory is corrupt.' |
|
On testing same application with .NET Framework (tested 4.0-4.8), I see below exception:
Which is expected exception and gets errors back from Native DLL. Whereas in .NET Core, the HRResult itself is not retrieved and Native DLL fails with reported exception from
On comparing OleDbCommand.cs for .NET Core and .NET Framework reference, I see 1 difference which I'm not sure how relevant it is: In .NET Core: runtime/src/libraries/System.Data.OleDb/src/OleDbCommand.cs Lines 583 to 587 in 4f9ae42 In .NET Framework reference (link): new public OleDbDataReader ExecuteReader(CommandBehavior behavior) {
OleDbConnection.ExecutePermission.Demand();
IntPtr hscp;
Bid.ScopeEnter(out hscp, "<oledb.OleDbCommand.ExecuteReader|API> %d#, behavior=%d{ds.CommandBehavior}\n", ObjectID, (int)behavior);
try {
_executeQuery = true;
return ExecuteReaderInternal(behavior, ADP.ExecuteReader);
}
finally {
Bid.ScopeLeave(ref hscp);
}
}
@stephentoub @roji would that be related to user's issue? Could someone give it a try? |
|
I believe the problem is related to this https://github.com/dotnet/corefx/issues/42596 |
|
Could you also provide a repro with provider MSOLEDBSQL with LocalDB where you experience this? |
|
In .Net Core 3.0 or 3.1 with 1 parameter works, but with 2 or more parameters error occurs. Following example: |
In the testapp I haven't considered the database scheme because I thought it is unnecessary. In our production app the row is correctly filled of course. I hope this helps for debugging and research. |
|
I believe I am seeing this as well. I'm porting this (working...well it was under .NET Framework) to .NetCore. I'm connecting to a very old AccessDB via OLE40 (this application is "glue" between that file and an SQL Server Database I use EF to talk to). Inside of a timed event I call some stored queries in the .mdb file, and that works just fine. Later on however, I get the same exception being reported here on the call to ExecuteReader(). This is my first mucking with .netcore, so bear with me. EDIT/ADD: Later or earlier makes no difference. Any call to this query fails., even if I use a pooled connection. |
|
@ajcvickers @cheenamalhotra @ David-Engel @cheenamalhotra @ danielSt-dev @JoeHz: Is there any way we can prioritize the solution of this problem, I think it's a major problem as it apparently affects System.Data.OleDb with any database. |
|
@maryamariyan @divega @cheenamalhotra @danmosemsft @saurabh500 @msftgits |
|
@jader1313 do you mind adding your test case in a PR to OLEDB here and confirming the difference in behavior by running your test case in the two different frameworks (.net core and .net framework)? Here is a doc page showing how to build and run tests on the runtime repo and to run in different frameworks: |
|
@maryamariyan I tried to run the tests but I am getting the following error: [05/02/2020 9:59:42.882 ] ---------- Discovery started ----------
But i have: C:\Projetos\DotNet\Desenvolvimento\DotNetCore\runtime.dotnet Ambiente de runtime: Host (useful for support): .NET Core SDKs installed: .NET Core runtimes installed: |
|
@jader1313 The error you are getting while running the tests is probably because you didn't follow all of the steps in order to run them. What we do is that we will build a special SDK during our regular build in the repo, and then we will use that one to run our tests, but looks like you didn't do that and only installed a 5.0 sdk which is not enough. In order to be able to run our tests please run the following commands from a command prompt: That should get the tests from that test project to run. If you want to add test cases and re run the tests, you only have to run that last command, no need to re run the first two which will take longer. |
|
@jader1313 I just realized our official builds on dotnet/runtime don't build for netfx any longer. However you can still follow @joperezr instructions to run any dotnet/runtime test for .net core. In order to run your test against both netfx and netcoreapp you would need to add your test in the release/3.1 branch in dotnet/corefx repo. You can run the tests to make sure that there is a change in behavior between .net core and .net framework. Read this two pages to learn how to run tests: What you can also do is to write a console app targeting both netcoreapp and netfx that exercises your test case and share if there any behavioral differences. |
|
@maryamariyan I had already executed the instructions on the website https://github.com/dotnet/runtime/blob/master/docs/workflow/building/libraries/README.md but I followed the instructions suggested by @joperezr again and got the following results: Discovering: System.Data.OleDb.Tests (method display = ClassAndMethod, method display options = None) === TEST EXECUTION SUMMARY === In Visual Studio / Test Explorer when running RUN ALL TESTS the result is 91 NOT RUN TESTS Output:
|
|
But the test I would create would be an adaptation of this code: |
|
@jader1313 I believe we already have tests on the repo exercising the code path you are sharing: |
|
@maryamariyan I redid the previous test with LocalDB and realized that it passes in .Net Core x64 but presents the error in x86. |
|
@maryamariyan I prepared a complete solution to carry out the tests, just being able to access a LocalDB. Attached below. There are 2 projects: Running: |
|
Could you please inform me that you managed to reproduce the problem? |
|
My experience with using the MS Access OleDb driver aligns with what @jader1313 is saying:
Switching to the x64 driver unblocks me for the moment, but I agree that the .NET Core x86 implementation should be fixed due to the fact that it's a pretty fundamental flaw. |
|
@FreddyD-GH thanks for your confirmation. @maryamariyan as I was unable to run the System.Data.OleDB tests, I took the test you mentioned (https://github.com/dotnet/runtime/blob/master/src/libraries/System.Data.OleDb/tests/OleDbCommandTests.cs#L137-L175) and adapted my project to run it. When running on x86 it shows ERROR. |
|
Thank you both for the complete description of the issue. Currently investigating, will give an update in a bit. |
|
@ericstj @maryamariyan @saurabh500 From what I saw the correction was implemented. Only in v5.0? How do I force a project to use that version of the .Net Core to test? We need this fix in version 3.1, is it possible? |
|
??? |
|
TargetFramework = ??? |
|
@jader1313 I haven't had a chance to see if the fix works yet, but I think what we want to do is install the latest version of the System.Data.OleDb nuget package from the nightly package source (https://dotnetfeed.blob.core.windows.net/dotnet-core/index.json). For example, using the dotnet CLI: If you have a chance to try this before I do, I'd appreciate knowing if that package fixes your issue. Edit: It should still work on .NET Core 3.1, as far as I know. |
|
@jader1313 Try the feed that @FreddyD-GH has provided to get the nightly nuget package build of System.Data.OleDb. That should have the fix. Also we haven't fixed the x86 problems completely and there is some more work that needs to be done. However I am not sure whether you are going to hit those issues or not. At this point, I know that in the internals of System.Data.Oledb, there were some x86 based structs which are being incorrectly used on x64 causing this issue. I will be migrating those structs soon too. |
|
In initial tests the reported problem was resolved.
|
|
Thanks @jader1313 I will be looking into these issues. |
|
@saurabh500 In the project we are working on (https://github.com/tombrothers/VfpClient), running the tests, 360 tests showed only 1 error in x86 in command: transaction.Rollback(); Exception thrown: 'System.Data.OleDb.OleDbException' in System.Data.OleDb.dll |
|
@saurabh500 I need this one in 3.1 too, please! |
|
@jader1313 Right now I am not comfortable taking the fix for this issue to servicing. |
|
Also I can only propose a servicing fix, but then the approvals are subject to quality bar and risk evaluation. |
|
@saurabh500 I understand what you are saying, but we are working to port an EF6 provider Fox Pro (https://github.com/tombrothers/VfpEntityFrameworkProvider2) to the .Net Core. Fox Pro only has a 32-bit OleDB driver (VfpOleDB). With corrections # 981 and # 32573 all tests of VfpClient (https://github.com/tombrothers/VfpClient), which is used by the provider, passed successfully. I understood that there are other x86 fixes to be implemented, but with the implementations of these 2 issues they solve our problems 100% and would allow us to complete the EF Core provider for Fox Pro. |
|
People who are working on EntityFrameworkCore.Jet (CirrusRedOrg/EntityFrameworkCore.Jet#34) will probably need these implementations in 3.1 as well, as they should encounter the same errors. @FreddyD-GH @lauxjpn @bubibubi |
|
I'm noticing a lot of comments wanting these fixes in .NET 3.1. Not to speak for anyone else, but I believe what people really care about is having these fixes integrated AS SOON AS POSSIBLE, more so than the .NET Core 3.1 compatibility (it already has, as it's already a separate NuGet package that targets .NET Standard 2.0). As mentioned, these bugs hit EntityFramework providers pretty hard if they rely on System.Data.OleDb. I think the main goal is to have EFCore 3.1 providers be unblocked on .NET Core PRIOR to the release of .NET 5 (as I assume there will be a coinciding EntityFramework Core release). If the EFCore 3.1 provider doesn't work BEFORE EFCore 5.0 is released, that's not exactly a great scenario for end users. @saurabh500 I understand that your hesitation about not including this fix in your "servicing" release. However, is it possible that System.Data.OleDb could publish a "preview" release of the NuGet package at the same time? For example, push two package updates: version 4.7.1 (which does not contain this fix), and a version 4.8.0-preview1 (which DOES include the fix). |
|
Nightly builds of this package are published out of master for anyone that would like to pick up changes. They will also be published to nuget.org following the .NET 5 release schedule (monthly previews). You can see the nightly build here:https://dnceng.visualstudio.com/public/_packaging?_a=package&feed=dotnet5&package=System.Data.OleDb&protocolType=NuGet&version=5.0.0-preview.3.20160.5 |
|
@ericstj Thanks, that information is helpful to know. Is there any good documentation where I can find out more about how the release schedule works? In particular, I'm a little confused when you say that that packages will be published to nuget.org as monthly previews, but it looks like there have been no preview packages for System.Data.OleDb in the last 4 months. |
|
While reading about this issue, I vaguely remembered that I stumbled over a similar exception some time ago. I wrote a little bit about it on StackOverflow two years ago. While I wrote at the time, that this is an ACE issue, it might could be an OLE DB related issue as well. I was able to replicate it again today with EntityFramworkCore.Jet using the x64 I had no issues using the x64 @saurabh500 This might be worth looking into in conjunction with #32509.
Let's cross our fingers (the risk evaluation bar is known to be high). Though in this case, users should not have been easily able to fix these issues by themselves, so an approval might be possible. |
Right, the first preview for net5 hasn't shipped yet, it's underway but has not released. It's not as simple as just build/publish as things need to sync up with Visual Studio. If you want simple / fast, use the packages from the nightly build feed. @leecow @jamshedd do you have any public facing docs around the schedule of net5 previews? |
|
@ericstj Ahhh, now I think I am understanding how it works. That is very unfortunate for the libraries that ship as separate NuGet packages. Regardless, thanks for clarifying. |
|
Nothing public-facing at the moment. I'll work with the blog writing folks and perhaps work something into the Preview 1 post. |
|
@saurabh500 I think @FreddyD-GH idea of a nuget package of System.Data.OleDB 4.8 Preview would solve the issue. |
|
Yeah that has always been the plan. The changes will automatically ship in the next Nuget release for System.Data.OleDb. |
That should be good enough. |
ajcvickers
removed
the
untriaged
ghost
locked as resolved and limited conversation to collaborators
Hi all,
we get a AccessViolationException when using System.Data.OleDb with "Microsoft OLE DB Provider for Visual FoxPro 9.0" (vfpoledb) after inserting a new row with a DataTable and OleDbDataAdapter.Update().
associated Code:
We ported the code from classic .Net Framework (4.8) where the code works without a problem.
The text was updated successfully, but these errors were encountered: