What you are describing is inexplicable under the assumption that the same SQLite library code runs the same way with or without calling the callback, except for calling the callback. That's the way it ought to work, as long as there is no heap corruption, outside interference with SQLite's data structures that it maintains for connections, or stack corruption or unbounded growth. None of those preconditions can be safely assumed to exist when the behavior you describe occurs. There need be nothing "special" about your unfortunate customer's database other than that, by being different, it helps expose a bug in somebody's code, either yours or SQLite's. It is a fact of programming in near-machine-level environments that programming errors can produce undefined behavior, and such behavior can include an absence of externally visible deleterious effects. Or, with a slight change to where a bad pointer write lands, the undefined behavior can become highly visible and clearly wrong. This is the perspective shift I am urging upon you. Do not insist that, just because you see one component acting badly, there must be a flaw in that component. You say your "callback ... just increments a counter". I dare say it does some other things that you do not see in your C or C++ code (or whatever it is, as yet unstated.) For example, it returns, and that will involve stack cleanup on one or the other end of the call, determined by calling convention. If you misinform the compiler about that, (with a C-style cast or a reinterpret_cast in C++), you may get away with it sometimes and sometimes not. You reiterate what is going wrong, without showing the only code which you claim makes all the difference in whether misbehavior occurs. Given that your callback is so simple, I suggest you share the code for it, all of it, including any macros that affect its definition and the statement(s) you use to install the progress callback. It would be interesting to see what a debug build of SQLite does with your database under the same sequence of operations. Also interesting would be a build of your application that does occasional heap integrity checking, particularly around the time that the misbehaving ANALYZE operation is done. I reiterate my advice to make the callback truly do nothing, and gradually make it do everything you want it to do. (That should not take long given its simplicity.) Even a do-nothing callback may expose a calling-convention mismatch that is blowing up in your problematic case. And please, do just repeat your evidence, as if "971,855,609,341 times!" is the problem. It is a symptom of a problem you have not yet really begun to hunt down or provide any clues with which anybody else can guess where that hunt should proceed.