SQLite Forum

SQLite.Interop.dll is not loading due to its dependency binaries are missing in windows server core OS
Login

SQLite.Interop.dll is not loading due to its dependency binaries are missing in windows server core OS

(1) By anurag on 2021-08-24 11:32:10 [link] [source]

I am using System.Data.SQLite.dll(1.0.113.0) which calls SQLite.Interop.dll and have a very simple application just to read and write in a table. The process could not load SQLite.Interop.dll on windows server core 2019(without desktop experience ) due to its dependent DLLs not being present in this version of the operating system. In Windows 10, Windows 7, Windows 2019 server with the desktop experience, it is loaded properly and everything works fine.

Do you know any workaround or any fix to address this issue?

(2) By mistachkin on 2021-08-24 16:28:43 in reply to 1 [link] [source]

Maybe try one of the pre-compiled binary packages instead of the NuGet package?

https://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki

(3) By Keith Medcalf (kmedcalf) on 2021-08-24 22:04:15 in reply to 1 [source]

Use the dependency walker to find out what DLL you are missing and install it.

(4) By anurag on 2021-08-25 10:19:08 in reply to 2 [link] [source]

Thanks for your reply, yes I am using pre-compiled binaries only.

(5) By anurag on 2021-08-25 10:21:32 in reply to 3 [link] [source]

I found the issue by dependency walker tool only and they are system libraries, can't install them manually on the c:WindowsSystem32 folder.

(6) By anurag on 2022-01-07 06:58:59 in reply to 1 [link] [source]

Do we know which all windows system binaries SQLite.Interop.dll uses, I have created a Microsoft support case also, they need this information and also they want to know if windows server without desktop experience is a supported Operating System Platform for Sqlite?

(7) By Keith Medcalf (kmedcalf) on 2022-01-07 19:10:16 in reply to 5 [link] [source]

Finding that they are discontiguous saved segments which ought to be provided by the Operating System is interesting -- failing to mention the name of those saved segments is fatal.

Mayhaps you can specify which DCSS that is claimed to be required is not being found?

(8) By Keith Medcalf (kmedcalf) on 2022-01-07 19:13:17 in reply to 6 [link] [source]

No. This is a Windows thing. SQLite uses the "standared C runtime" and a few "platform specific interfaces", all of which should be present on ANY version of OS/2 New Technology (aka Windows NT aka Windows).

(9) By anonymous on 2022-01-08 09:26:02 in reply to 6 [link] [source]

Do we know which all windows system binaries SQLite.Interop.dll uses ... ?

Just run dumpbin /dependents SQLite.Interop.dll to see the linked DLLs. If you have no MSVC environment ready to run this command, you can also use a simpler tool like pelook (disclaimer: this is a 3rd party closed-source program).

(10) By anonymous on 2022-01-08 14:55:53 in reply to 8 [link] [source]

"standared C runtime" <...> which should be present on ANY version of <...> Windows

Well, depending on how SQLite was linked, it may turn out to depend on a version of C runtime that's not guaranteed by Windows to be present on a given system. The Windows dependency model is "take it with you", including a C runtime, one of many available versions.

Or even many of them in a single process, because different DLLs were linked with different C runtimes. This is part of the reason why SQLite exports its allocator: so that the user would be able to call the correct copy of free() on the pointers allocated by SQLite.

(11) By Keith Medcalf (kmedcalf) on 2022-01-08 18:14:42 in reply to 10 [link] [source]

Well, depending on how SQLite was linked, it may turn out to depend on a version of C runtime that's not guaranteed by Windows to be present on a given system. The Windows dependency model is "take it with you", including a C runtime, one of many available versions.

This is true, if one wants it to be true. It has been possible, however, since the begining of Windows NT (when it was called OS/2 New Technology) and even before, to generate executables that use what is known in patented IBM terminology as "the subsystem runtime" rather than a user conceived runtime.

I always use the subsystem runtime because it is stable. And while Microsoft did remove the system trampoline for a few versions of OS/2 New Technology, they have now put it back, by default, on every system.

Other people may choose to chase a proprietary user mode runtime that is subject to the whims of whomever created it (such as the various MSVC runtimes).

That means that you can either deliberately choose to have problems, or deliberately choose to not have problems.

Microsoft generally prefers the former (using proprietary runtimes from the "runtime of the month club") thus causing those using such ill-conceived "runtime of the month" to believe that there may be compatibility issues from one version of OS/2 New Technology to the next, where there is none. There is simply a change in the "runtime of the month" and the issues are by design.