> Please investigate <Attempted to read or write protected memory.> > > Something is amiss with 32-bit SQLite3.DLL I have seen no reason whatsover to believe that the address fault is caused by anything in the sqlite3.dll conveniently built and published at sqlite.org . The fact that some client code, which includes an interface between its own .Net CLR code and that DLL, appears to lead to an address fault only shows that there is something wrong with the whole collection. When, as in this case, string data is being passed between different execution realms, there are well known opportunities for memory management bugs to arise. Interfaces between managed execution environments and native code are notoriously difficult to get right. > What is amiss? > > Identical callback code fails with 32-bit SQLite3.DLL but works with 64-bit SQLite3.DLL. There is little reason to conclude that the callback code seen/run by the sqlite3_exec() function is identical between those cases. Indeed, it **should not be identical** because calling conventions differ between 64-bit and 32-bit code. The issue is: Does the actual callback code (including parameter marshaling) differ as it should and only as it should between the case where a 32-bit sqlite3.dll is used and where a 64-bit sqlite3.dll is used? That is not yet known, and until it is known there is no reason to be suspecting that there is a bug in need of investigation by the SQLite dev team. There is another reason to defer resting suspicion on the SQLite library in this case. The problem is occurring during a callback run by sqlite3_exec(), an API that is much used in the SQLite CLI shell and is undoubtedly tested extensively.