> > There is another reason to defer resting suspicion on the SQLite library in this case. > Hence my request for 'investigating' what appears to be an 'anomaly' as opposed to requesting a 'fix' for a 'bug'. Regardless of what the disappointing behavior is called, it is not in any way a result of any defect in the SQLite library code. The sqlite3_exec() API is a very simple convenience function which has existed in essentially the same form for years. Its use of the callback function pointer is unchanged for 16+ years. This API is used in many places within sqlite3.c to help implement other functionality that is also well tested and in common use. To me, it is barely conceivable that that it would be incorrect under such circumstances. To even suspect a defect there, strong and conclusive evidence would be needed. All that your case shows is that something is going wrong somewhere in a collection of code that includes what you wrote, what the .Net CLR and a .Net library do to effect CLR/C interop, and the SQLite library. Given the testing to which sqlite3_exec() is subjected and the widespread success of its use in many applications, your suggestion that it **might** have a defect, exposed by your code, is very weak and ambiguous evidence. It would be a waste of the SQLite developers' time to debug this problem as part of their work on the SQLite library. (Somebody might do it to see yet another pitfall awaiting those who traipse in the interop realm.) Your expectation that your code should work across multiple platforms is not unreasonable where it is platform-agnostic. However, the transition between the managed environment of .Net CLR execution and the unmanaged execution environments running on the AMD/Intel x64 and Intel/AMD i386+ Windows platforms cannot be achieved by "the same code". An adapter layer is being inserted to do that, and that layer must differ in some way for those unmanaged environments (even if only in code paths taken.) As far as the SQLite dev team should be concerned, that adapter layer is just as much "not SQLite" as the code you wrote. *It is not their problem.* If your interop scenario had worked, I believe that would have been more correct *for the .Net System.Runtime.InteropServices library*. What you are seeing may well be due to a bug **in that library**. I say this because I do not see anything in the documentation for the DllImport functionality to suggest that it should be used differently between the cases where 64-bit versus 32-bit DLLs are called into. You have a fairly simple test case, using a well-proven DLL, that could be of real interest and value to the InteropServices library developer(s). So if you are going to plea for an investigation and eventual fix, they would be the appropriate recipients.