> > [interop library developers] would be the appropriate recipients. > To my mind, that does not make sense. > > 1. Any such problems is likely to be picked up by the infinitely more interop library users than sqlite users. > 2. If the interop library has a flaw, it would manifest itself with the first callback and not the 4th. The error arises during the 4th callback consistently irrespective of the number of columns i.e. the size of data in the sqlite3 pointer. Disregarding the hyperbolic "infinitely more", what makes you think my hypothetical interop bug is subject to more exposure instances than your hypothetical SQLite bug involving use of a C callback? I cannot see a reason to believe such, knowing that SQLite's use, and use of its sqlite3_exec() function, are ubiquitous. I see less evidence that callbacks into managed code from unmanaged code are used much, particularly from 32-bit DLLs. Regarding failure on "the 4th callback": All that this demonstrates is that a side-effect is at work rather than simple wrong computation. Side-effects, especially when they involve memory corruption, have a wild variety (or even a near-infinite variety) of manifestations. Knowing this, I see no reason to deduce anything from this delayed failure other than that it is a side-effect. (That is why I suggested heap checking awhile ago.) Furthermore, any reasoning as to what the delayed failure implies will apply equally to any subset of the subject code, what you wrote, the interop layer, or the SQLite library. > ... NOT in any way pointing fingers It is too early to do that. But deciding where to invest effort hunting for this bug is not premature. Looking within the SQLite library is counter-indicated. > The problem exists? Where does that leave me? It leaves you with one fewer option than you had once imagined for solving your problem. CLR/C interop has been operable for many years now. You may need to use P/Invoke differently if you insist on using the 32-bit sqlite3.dll, as distributed. It would not be difficult to write some C# code not relying on a callback as sqlite3_exec() does for query results. That is merely a convenience function; it can be replaced with sqlite3_prepare() and sqlite3_step(). > SQLite should at least investigate. On what basis? Do you insist that there is a significant likelihood that such investigation will lead the SQLite dev team investigator(s) to making some improvement in the library? That is highly doubtful given that sqlite3_exec() is a legacy function, with an interface frozen for a few more decades. Do you realize that most of the team members primarily use Unixen machines? Regardless of the moral or self-interest imperative you perceive on behalf of the SQLite dev team, I can predict that they are not going to go figure out why .Net interop is failing for you, and they certainly are not going to fix it. So you are on your own unless you can prevail upon the InteropServices library developer(s) to investigate what goes wrong with your simple sample code.