SQLite Forum

Possible bug: Unable to find an entry point

Possible bug: Unable to find an entry point

(1) By anonymous on 2021-11-23 16:45:24 [link] [source]

Hardware: Raspberry Pi 3 B+
OS: Debian Bullseye ARMv8 (64 bit) from the DietPi org

libSQLite.Interop.dll compiled on above using sqlite-netFx-full-source-

When running a .net 6 (core) app using System.Data.SQLite.Core the following error is encountered on start: Unable to find an entry point named 'SIa069da76968b7553' in shared library 'SQLite.Interop.dll'

When running the same app but with System.Data.SQLite.Core 1.0.115 (previous version) no error is encountered and the app functions normally.

It’s unclear to me if this is a bug in or if I’m doing something incorrect. Just throwing it out there in case it is a bug.


(2) By Larry Brasfield (larrybr) on 2021-11-23 21:08:24 in reply to 1 [link] [source]

... the following error is encountered on start: Unable to find an entry point named 'SIa069da76968b7553' in shared library 'SQLite.Interop.dll'

I am highly skeptical that a name like that is supposed to be exported by that DLL. I've seen many name decoration schemes, but never one that appears to encode a 64-bit number with a prefix. And all the names exported by SQLite.Interop.dll for x86 and amd64 platforms are more ordinary, semi-meaningful-to-humans identifiers.

Do you have any reason, beyond this error message, to believe that the System.Data.SQLite.Core library is, in fact, linked (albeit dynamically) to such an entry point?

(4) By anonymous on 2021-11-24 01:35:58 in reply to 2 [link] [source]

I agree, it seemed quite unusual to me too. But that was the message verbatim.

I have no other reason nor evidence. And admittedly I am in a litter over my head here.

All I know is the same steps taken for two very close versions resulted in one working and one not. The possibility exists that I was just getting lucky with having one working as the following post might suggest.


(3) By mistachkin on 2021-11-23 23:09:35 in reply to 1 [link] [source]

The precompiled managed assemblies within the official NuGet packages are
only intended to be used with the interop assemblies also from those NuGet

(5) By anonymous on 2021-11-24 01:39:10 in reply to 3 [link] [source]

Ah. That is good to know. Thank you!

(6) By webprofusion on 2021-12-20 03:27:33 in reply to 3 [link] [source]


Further to this I can confirm that when upgrading from System.Data.SQLite.Core to and distributing our application to users that the users are frequently encountering the following error (not universally):

System.EntryPointNotFoundException: Unable to find an entry point named 'SIfcfad09d1b0a60ec' in DLL 'SQLite.Interop.dll'.\r\n at System.Data.SQLite.UnsafeNativeMethods.sqlite3_open_interop(Byte[] utf8Filename, Byte[] vfsName, SQLiteOpenFlagsEnum flags, Int32 extFuncs, IntPtr& db)\r\n at System.Data.SQLite.SQLite3.Open(String strFilename, String vfsName, SQLiteConnectionFlags connectionFlags, SQLiteOpenFlagsEnum openFlags, Int32 maxPoolSize, Boolean usePool)\r\n at System.Data.SQLite.SQLiteConnection.Open()\r\n at System.Data.Common.DbConnection.OpenAsync(CancellationToken cancellationToken)\

We have been distributing this app with SQLite for years, generally following the latest System.Data.SQLite.Core

My (unsubstantiated) theory is there could be a particular brand of Anti-Virus that's somehow interfering with the assembly load, or certain users have older SQLite.Interop.dll installed in the GAC and for some reason it's picking that up.

I can confirm SIfcfad09d1b0a60ec is the SQLite.Interop.dll export of sqlite3_open_interop in

 [DllImport("SQLite.Interop.dll", EntryPoint = "SIfcfad09d1b0a60ec")]
    internal static extern SQLiteErrorCode sqlite3_open_interop(
      byte[] utf8Filename,
      byte[] vfsName,
      SQLiteOpenFlagsEnum flags,
      int extFuncs,
      ref IntPtr db);

(7) By tsuckow on 2022-03-06 04:37:44 in reply to 6 [link] [source]

When building from the source zip, I don't get a compatible library. This must mean the nuget packages are built from a different set of source...

Makes it rather difficult to support other platforms. Guess I'll just have to go back to for freebsd

(8) By cguardia on 2022-04-13 01:53:36 in reply to 7 [link] [source]

Same error here. Any update?

(9) By anonymous on 2022-04-22 22:04:36 in reply to 8 [link] [source]


(10) By mistachkin on 2022-04-23 17:11:37 in reply to 9 [link] [source]

Per my previous reply (see #3 above), this is by design.

(11) By anonymous on 2022-04-29 15:09:06 in reply to 10 [link] [source]

for me, these are my test results:

  • v1.0.115.0 seems to work without exception
  • v1.0.115.5 runs into this exception

so, the System.EntryPointNotFoundException at "SQLite.Interop.dll" might be introduced with some of last changes?

(12) By Paul Smith (PaulSmith) on 2022-05-01 07:09:45 in reply to 11 [link] [source]

I had the same problem, so I uninstalled v1.0.115.5, and installed Now I get this exception:

System.IO.FileLoadException HResult=0x80131040 Message=Could not load file or assembly 'System.Data.SQLite, Version=, Culture=neutral, PublicKeyToken=db937bc2d44ff139' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

I'd be grateful for any help with this.



(13) By anonymous on 2022-06-01 08:37:39 in reply to 12 [link] [source]

This simply means that the newer version i still referenced somewhere in your code

(14) By anonymous on 2022-06-13 11:29:10 in reply to 6 [link] [source]

I don't understand why these SQLite.Interop.dll builds now use "encoded" entry point names. Just use plain english e.g. sqlite3_open_v2 or whatever.

The newer versions which use these encoded entry points means the DLLs become useless for any use-cases outside of the "official" System.Data.Sqlite assembly.

There are more use-cases for the SQLite.Interop.dll files than the maintainers perhaps realised.

(15) By jaymac on 2022-07-12 15:04:10 in reply to 14 [link] [source]

We too are desperate to see this fixed. Surely this is a backwards compatibly bug / oversight and not intentional, right?

I've spent much of a morning trying to guess the mangled name of sqlite3_create_window_function. Looking at the code it looks like it should be exported cleanly, but clearly it is not.

If you compare:

dumpbin /exports SQLite.Interop.dll

(on a Win64 machine) between and (both from the official nugets) (perfect!)

Dump of file SQLite.Interop.dll

File Type: DLL

Section contains the following exports for SQLite.Interop.dll

00000000 characteristics
5ED282B6 time date stamp Sat May 30 16:58:46 2020
    0.00 version
       1 ordinal base
     387 number of functions
     387 number of names

ordinal hint RVA      name

      1    0 000380D0 _interop_compileoption_get@4
      2    1 000380F0 _interop_compileoption_used@4
      3    2 00038040 _interop_libversion@0
      4    3 00038030 _interop_sourceid@0
      9    4 000378E0 _sqlite3_backup_finish_interop@4
     17    5 00037D00 _sqlite3_bind_double_interop@12
     20    6 00037CC0 _sqlite3_bind_int64_interop@12
     25    7 00037C50 _sqlite3_bind_parameter_name_interop@12
     35    8 00037880 _sqlite3_blob_close_interop@4
     44    9 00037F10 _sqlite3_changes_interop@4
     47    A 00038050 _sqlite3_close_interop@4
     57    B 000373B0 _sqlite3_column_database_name16_interop@12
     58    C 00037410 _sqlite3_column_database_name_interop@12
     61    D 00037AF0 _sqlite3_column_decltype16_interop@12

... 106 7F 00088820 sqlite3_create_module_v2 107 80 0006C1F0 sqlite3_create_window_function (THIS IS WHAT I NEED!) 109 81 000D3B10 sqlite3_data_count ... 386 181 00042380 sqlite3session_patchset_strm 387 182 00043B80 sqlite3session_table_filter


    3000 .data
    1000 .gfids
   27000 .rdata
    8000 .reloc
    1000 .rsrc
  107000 .text (broken)

Dump of file SQLite.Interop.dll

File Type: DLL

Section contains the following exports for SQLite.Interop.dll

00000000 characteristics
62979CAB time date stamp Wed Jun  1 18:06:51 2022
    0.00 version
       1 ordinal base
     206 number of functions
     206 number of names

ordinal hint RVA      name

      1    0 00057EA0 SI02815e94e2c315f7
      2    1 000586A0 SI039413da2b10b773
      3    2 00090410 SI054e3c8468772b2b
      4    3 001500B0 SI0628e029b7e108db
      5    4 001197F0 SI077534168313d3ed
      6    5 0004A300 SI0938f783b19237a0
      7    6 00053990 SI0a886fd4c720116f
      8    7 0011AD00 SI0bdc6d0c384d2e10
      9    8 000457E0 SI0ce1fad4c4f4a7fb
     10    9 00119F40 SI0cff507887d45bcd
     11    A 000580D0 SI0d6b1c4a8f9f99d4
     12    B 0008E370 SI0da8b85fb82501d5

.. 194 C1 00042CC0 SIf7e752fd3d0936c7 195 C2 0011A610 SIfc766c3d655f3fe2 196 C3 000453B0 SIfd60417394c54f67 197 C4 000F1FD0 SIfdd143ea824fb4f0 198 C5 0011BE60 SIff65f01991d44537 199 C6 00018DC0 sqlite3_cryptoapi_init 200 C7 00026870 sqlite3_fts5_init 201 C8 00026880 sqlite3_fts_init 202 C9 0001DFC0 sqlite3_percentile_init 203 CA 0001C4B0 sqlite3_regexp_init 204 CB 00019FA0 sqlite3_sha_init 205 CC 000193C0 sqlite3_totype_init 206 CD 00042C20 sqlite3_vtshim_init


    7000 .data
    1000 .gfids
   12000 .pdata
   43000 .rdata
    2000 .reloc
    1000 .rsrc
  154000 .text

(16) By mistachkin on 2022-07-12 18:53:41 in reply to 15 [link] [source]

Follow up to #3:

The precompiled interop assemblies within the official NuGet packages are
only intended to be used with the managed assemblies also from those NuGet

(17) By jaymac on 2022-07-12 19:17:23 in reply to 16 [link] [source]

That somewhat misses the point. We are using them from the managed assemblies, but happened to have added support for custom aggregate-window functions

so need the following to be callable

    private static extern SQLiteErrorCode sqlite3_create_window_function(
        IntPtr db, byte[] strName, int nArgs, int nType, IntPtr pvUser,
        SQLiteCallback fStep, SQLiteFinalCallback fFinal, SQLiteFinalCallback fValue, SQLiteCallback fInverse, SQLiteDestroyCallback fDestroy);

to work... just as it was in older versions like

(18) By mistachkin on 2022-07-12 19:31:09 in reply to 17 [link] [source]

I understand what you are saying; however, I think a better solution would be
for me to enhance the SQLiteFunction class to support window functions.

(20) By jaymac on 2022-07-12 19:37:50 in reply to 18 [link] [source]

By all means, that would be great! I spent a fair day or two building that functionality (always tricky to toenail things in like that) - and would love it to be core

Still I really can't understand why you would expose mangled names, when you used to support readable ones.

I call that a backward compatibility break, and limits how people can extend the great work of this library (as we have done).

(22) By jaymac on 2022-07-12 21:29:32 in reply to 20 [link] [source]

In maybe? :)

(23.1) By mistachkin on 2022-08-19 05:55:39 edited from 23.0 in reply to 22 [link] [source]

Yes, that is the plan.

Per #24 (below):

The feature is now present on the trunk in the System.Data.SQLite repository.

Could you please test it out and let me know of any problems you encounter?

(19.1) By Larry Brasfield (larrybr) on 2022-07-12 19:44:52 edited from 19.0 in reply to 17 [link] [source]

Joe has stated a true fact which is relevant to your "need". What you need to do is ensure that the correct DLL is loaded. This will necessitate more than merely naming "SQLite.Interop.dll" in the attribute. When a DLL to be loaded is specified without an absolute path, it is loaded according to a set of rules which you can lookup and exploit to solve your problem. First among those rules is that if the named DLL can be found in the same directory as the .exe which began the process, that will be loaded. (This is called "side-by-side" loading.)

What will not solve your problem is noisily hoping/wishing that what once happened to work for you will continue to work for you. If you were not taking care to get the correct DLL loaded, it was only an accident that one was found and loaded which happened to work. Taking such care is your job.

(Added via edit:) Taking care to ensure the correct DLL is loaded is established good practice even if somebody obviates your need to explicitly load a DLL or name mangling is done differently. The reason that side-by-side loading was added to the DLL locating algorithm was that problems such as are evident in this thread had proved to be very troublesome using the previous DLL loading rules.

(21) By jaymac on 2022-07-12 20:33:58 in reply to 19.1 [source]

I agree with the point of "having to work carefully to load the right dll".
We do and are. Finding the right dll to side-by-side load is clearly important (we support many OSs for example), but again, we are doing that correctly.

Our issue is in attempting to update the nugets to pull in new SQLite dlls/features - and is focused only on the name mangling (in the correct new dlls).

After a huge amount of manual effort (change mangled name EntryPoint, re-build, run unit test, record failure... repeat 198 times) I failed to find the right entry point.

The closest I got was

    [DllImport("SQLite.Interop.dll", EntryPoint = "SI1f188bbd4af5db07", CallingConvention = CallingConvention.Cdecl)]
    private static extern SQLiteErrorCode sqlite3_create_window_function( ...

which eventually led to:

braycurtis_distance() may not be used as a window function

so must map to one of these, presumably

sqlite3_create_function sqlite3_create_function16 sqlite3_create_function_v2

as opposed to sqlite3_create_window_function.

Is there any way in the source code that would let me reverse the name mangling (I worry I could have made a mistake in the aforementioned process, which was tedious and manual)? Another possibility is that it simply is not exported (which looking at the code I don't see why would be the case).

(24.1) By mistachkin on 2022-10-10 01:54:24 edited from 24.0 in reply to 21 [link] [source]

The feature is now present on the trunk in the System.Data.SQLite repository.

Could you please test it out and let me know of any problems you encounter?

EDIT: Would really appreciate your feedback on this prior to the release.

(25) By anonymous on 2022-10-31 14:44:47 in reply to 3 [link] [source]

Thank you for the answer. I see you reference this in emphatic manner right down the list of conversations. From my point of view, I'm a newbie to things INTEROP like and have absolutely no idea what your reply means. So, just as a matter of info - please consider adding to this reply a section that starts "For those who are in the dark or absolute newbies...this is how you go about getting those interop assemblies FROM THOSE NUGET PACKAGES:" I would greatly appreciate such a basic, down to the children, kind of answer instead of a repeated curt reference to the above. There are those of us who have to occasionally run into things we are totally clueless about and we will probably never touch again in our lives but just have to make it work at that moment because our jobs demand it.

(26) By Chris Locke (chrisjlocke1) on 2022-10-31 15:54:28 in reply to 25 [link] [source]

What OS are you using, and what development package (software) are you using to use SQLite? You mention NuGet packages, so have you downloaded those? What have you tried, what has worked, and what are you struggling with?

(27) By anonymous on 2022-11-16 08:29:37 in reply to 26 [link] [source]

Thanks for the response. I'm using Visual Studio 2019 on Windows 10 on Intel architecture and one of the User Controls forces a need for ANY CPU - otherwise it cannot be used if a specific CPU architecture is selected.

I am currently using Sqlite version 1.0.115 and I have Sqlite.Interop.dll in an x32 and in an x64 directory and it works.

If I try to update to the latest version of System.Data.Sqlite using Nuget ( since that is what is currently installed) I get the dreaded cannot find dll or whatever message ( long time since I looked at it ) - meaning the program is running in either 32bit or 64 bit mode and cannot find the other architecture of sqlite.interop.dll. Please tell me what exactly I should do to make it work. Thanks.