View Ticket
Not logged in
Ticket UUID: 9ac9862611f9e8eaa06fa9024418d6f0e591b967
Title: Wrong processor architechture detected in System.Data.SQLite.dll while running out of visual studio
Status: Closed Type: Incident
Severity: Important Priority: NextRelease
Subsystem: Integration_Via_PInvoke Resolution: Workaround
Last Modified: 2013-07-15 18:48:16
Version Found In:
User Comments:
anonymous added on 2013-04-10 08:28:16:
We’re using SQLite in a mixed environment. The host application is written in Delphi and compiled as 32-bit process. This application calls .Net code that uses SQLite.

The .Net assemblies are currently compiled using architecture “AnyCPU”. If I start the main application itself all is working correct. The environment variable “PROCESSOR_ARCHITECTURE“ is set to „x86“.

If I start the same host application out of visual studio running on a x64 OS the variable is set to “AMD64” (in my case) which is not correct for the currently running process.

The method UnsafeNativeMethods.PreLoadSQLiteDll(..) uses this environment variable to determine the architecture and tries to load the needed assembly.

The only thing to do is to check whether the currently running process is a 32-bit or 64-bit process, isn't it?

It would be possible to use the properties “Is64BitOperatingSystem” (true in my case) and “Is64BitProcess” (false in my case). Both are set correct even if visual studio starts the process.

If you’ll use these properties it would be possible to use SQLite out of visual studio having a x86 host application and an “AnyCPU” compiled assembly that references SQLite started on a 64-bit OS.

mistachkin added on 2013-04-10 11:18:34:
First, I've never seen the PROCESSOR_ARCHITECTURE environment variable set to
the wrong value.  Is it possible that some other component in the process is
setting it?

Second, if you are running a pure managed executable assembly on an x64 machine,
the environment variable should indeed be "AMD64".  In that case, you'll want to
make sure that both the x86 and x64 SQLite interop assembly files are available
and are deployed to the correct directories within the application binary

Since the PROCESSOR_ARCHITECTURE environment variable value itself is used to
help construct the final file name for the SQLite interop assembly, simply using
a binary (yes/no) check for a 64-bit process will not be a drop-in replacement,
nor should it be necessary in this case.

Finally, if the PROCESSOR_ARCHITECTURE environment variable is indeed being set
to the wrong value for the process by the operating system (i.e. due to a bug),
it can be easily overridden by the application prior to loading the
System.Data.SQLite assembly, for example:

        Environment.Is64BitProcess ? "AMD64" : "x86");

However, it should be noted here that assuming a 32-bit process is "x86" (or
that a 64-bit process is "AMD64") may not always be true, due to things like
32-bit ARM, etc.

anonymous added on 2013-04-10 11:29:45:
Please take a look at the following blog entry - it describes exactly my problem:

mistachkin added on 2013-04-10 11:40:35:
That may be caused by this:

Or it could just be an issue with Visual Studio.  Either way, my original
comments are still valid.

mistachkin added on 2013-07-15 09:23:22:
I've now seen this issue occur from within Visual Studio 2012 running on a 64-bit
Windows 7 machine.  It appears to require the "Prefer 32-bit" project option to
be enabled.

This appears to be a bug in the operating system and/or Visual Studio.

mistachkin added on 2013-07-15 09:28:59:
Screenshots with proof of issue added.

mistachkin added on 2013-07-15 18:48:16:
Workaround implemented by check-in [f54929f54e] on trunk.  This will be in the
next release,