View Ticket
Not logged in
Ticket UUID: 0027a394f96d2d50430433add813fbb68123554a
Title: System.AccessViolationException when Open database with in memory connection string
Status: Closed Type: Incident
Severity: Important Priority: Medium
Subsystem: Native_Assembly Resolution: Unable_To_Reproduce
Last Modified: 2015-12-05 01:04:17
Version Found In:
User Comments:
anonymous added on 2015-09-03 10:13:40:
I just upgraded via nuget from to

Opening database with "FullUri=file::memory:?cache=shared;" connection string give me System.AccessViolationException 

Build with x64

mistachkin added on 2015-09-04 20:28:01:
I'm unable to reproduce this issue using Visual Studio 2012 and the primary
NuGet package (with Id = "System.Data.SQLite").

What version of Visual Studio are you using?  Which NuGet package(s) are you

Is it possible that another component is corrupting the heap in your process?

anonymous added on 2015-09-05 15:46:37:

I'm using visual studio 2015 community
nugget package System.Data.SQLite.Core
.Net Framework 4.6 Debug Mode x64

At this moment I revert back to 1.0.96 and it works again (lucky I have backup)
I run it with windows forms
I don't think any other component can corrupt, I mean the older version is working so...

Do you maybe make a change on Open method between 1.0.96-1.0.98 ?

mistachkin added on 2015-09-07 00:40:20:
Can you capture a stack trace?

Is there an example database schema and/or
C# program that demonstrates the issue?

anonymous added on 2015-09-07 10:13:41:

Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

   at System.Data.SQLite.UnsafeNativeMethods.sqlite3_open_interop(Byte[] utf8Filename, Byte[] vfsName, SQLiteOpenFlagsEnum flags, Int32 extFuncs, IntPtr& db)
   at System.Data.SQLite.SQLite3.Open(String strFilename, String vfsName, SQLiteConnectionFlags connectionFlags, SQLiteOpenFlagsEnum openFlags, Int32 maxPoolSize, Boolean usePool)
   at System.Data.SQLite.SQLiteConnection.Open()
   at System.Data.Common.DbConnection.OpenAsync(CancellationToken cancellationToken)
   at System.Data.Common.DbConnection.OpenAsync()
   at CodeKamer.DataExpressAPI.SqLiteAPI.<Connection>d__13`1.MoveNext() in C:\Apps\Work\CodeKamer\CodeKamer.DataExpress\CodeKamer.OracleExpressAPI\SqLiteAPI.cs:line 129
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.Start[TStateMachine](TStateMachine& stateMachine)
   at CodeKamer.DataExpressAPI.SqLiteAPI.Connection[T](String connectionString, Func`2 transformConnection)
   at CodeKamer.DataExpress.FormGrid.<buttonSqlLiteInMemoryExecute_Click>d__126.MoveNext() in C:\Apps\Work\CodeKamer\CodeKamer.DataExpress\CodeKamer.OracleExpress\FormGrid.cs:line 2029
   at System.Runtime.CompilerServices.AsyncVoidMethodBuilder.Start[TStateMachine](TStateMachine& stateMachine)

I try to reproduce the issue also by creating new project, seems the error not easy to reproduce, maybe you see something from stack trace?

mistachkin added on 2015-09-07 17:14:42:
I'm unable to reproduce this issue locally.  Perhaps the issue is with the
CodeKamer.DataExpressAPI component, which I do not have access to?

anonymous added on 2015-09-11 05:47:30:
The code it self nothing really fancy

public static async Task<T> Connection<T>(string connectionString, Func<SQLiteConnection, Task<T>> transformConnection)
            T result = default(T);
            using (SQLiteConnection connection = new SQLiteConnection(connectionString))
                    //This where exception thrown   
                    await connection.OpenAsync();                  

                    result = await transformConnection(connection);

            return result;

mistachkin added on 2015-09-11 20:50:34:
Does the access violation also occur for 32-bit (i.e. if the Prefer32Bit project
option is set)?

mistachkin added on 2015-09-11 21:32:59:
I've tried using the provided sample code to reproduce the issue; however, I'm
still not seeing the exception.

anonymous added on 2015-09-15 05:52:11:

I can't use x86 for as I'm using CefSharp at this moment which require me to always use x64.

I will wait for the next release and test it again...