I cannot repro it on my machine, but the assertion suggests that the error happens when a memory object is being deleted, so it's not something you want to ignore. Perhaps this is a case of double-deletion (which
should not happen since we only use smart pointers in JSON parser).

Can you reply with a call stack and/or full repro case?

You're not doing anything wrong, as you said yourself this is similar to the unit tests we have (negative_get_field_object etc.)

That stack trace is all too familiar to me -- the layout of standard strings vary between runtime binaries for different configurations. If I were a betting man, I'd bet that you have a mix of release and debug binaries in your execution folder.

First, though, build your project using /MDd -- Casablanca has not been tested as a static library, so we don't know that it works that way.

Second, if that doesn't help, make sure that you know that all your binaries are either debug or release binaries in the directory where you application is run from. Each time I've seen this, it's been because I've somehow managed to use a Release DLL with
a Debug DLL or EXE.

Once I switched my project to /MDd it didn't throw assertion error anymore but if I switched both to /MTd it was still failing. You can repro this issue with default console app and the two statements in the original post.

Will this cause the application to be dependent on re-distribuable binaries? That would really increase download size. Would it make more sense to use /MTd and /MT so that there is no binary dependency at run-time?

Making static linking work is on our list, but not as high up as many other things. Mostly, this is due to a testing resource constraint -- supporting static linking doubles the number of configurations we have to validate.

The X64 release Casablanca DLL is < 600KB, not tiny, but not extremely large, either. Given how interconnected all the pieces in the library are, static linking is likely to add a significant portion of that to your application size.