I'll try static linking, but I guess it will not solve the problem: I'm 100% sure that the main application does not use boost.regex (I've checked with dependancy walker).

It still might be that you have two versions of boost on your system, one being used at compile time, the other at runtime. In my experience, many obscure errors result from something like that. If it is not boost, check all other libraries you are using in your program.

Next step: Use some memory checking library (hope there is something like that for windows...). Memory which is corrupted by the application can also give extraordinary results.

If this still yields no findings, gradually remove all calls to the 3rd party software or replace the function calls by calls to dummy functions. Somewhere between the current state and that initial commandline exe the regex behavior will return to normal. This will give you a hint where to look closer or what/whom to ask in more detail.

Try to reproduce the problem with something you can publish. If you find no way to reproduce the problem without the 3rd-party software, contact the vendor.

Thanks for the hints!

I've checked with Microsofts TR1 implementation, and I get the same wrong result, so the problem is not Boost, but the 3rd party application.

From an older project, I remembered that the application's libs use _HAS_ITERATOR_DEBUGGING=0 and _SECURE_SCL=0, but that wasn't enough.

If anyone had an idea which #defines and #includes are _not_ allowed for boost::regex (or std::tr1::regex), that would be great!

But you're right: as it's not a Boost-specific problem, I'll try to get help from the application's vendor.

Regards,
Carsten