> > so it would be educational for you to say why [asking for code "raises doubts"]. > I thought that anyone willing or capable of troubleshooting code will be able to create the code without any problems. > On the other hand, it would make sense to use the same code as myself; therefore, the request for code is valid. Someone capable of seeing what is wrong with some code would likely create code that did not fail, unless they intended to create a specific bug. However, creating an address fault can be done in so many different ways that it would be pure chance if such creation happened to match how some unseen code did so. This is why "show the code" is so much preferred over summary descriptions. > > I can build the app and run it without any address faults > **Thank you** ... I am using Console App(.Net Framework) and 32-bit SQLite3.DLL This might be an parameter marshaling problem, or it could be simply that you have not yet told the auto-magic marshaling builder enough that it knows what to expect. [a] A diligent perusal of the Native Code interfacing docs is indicated. I doubt that your problem is a simple bug in the .Net marshaling code or C# compiler. Debugging at the assembler level would likely be revealing as to what is going wrong, but not how to fix it. Debugging at that level for the working and failing versions, with cross-comparison, would be more interesting. [a. I was surprised at how convenient marshaling setup has become since I last had to do it. Maybe it is not quite as easy as it looks in that post 15 code except when certain defaults are correct. ] > Switching to .Net Core is a sound idea but I need to be working with 32-bit SQLite3 my reasons will be clearer when I provide feedback ... more soon. I am not advocating .Net Core or use of a 64-bit DLL, at least not here. I was trying to get defaults more likely to be favorable because, while I did not see anything wrong popping out of the Delegate declaration, I was less sure as to what might be missing. To me, it seemed too easy.