Maybe I'm just confused (or sleep deprived!) but I don't see how this is a bug necessarily. You allocate memory pre-main() via invoking string constructors, via your static object. So if you check for leaks at the end of main(), you're not going to see that memory freed. You have to check for leaks after static destruction occurs, which is the purpose of the _CrtSetDbgFlag() call; if you don't get a report at program exit, it means you have no leaks - which, in this case, is exactly what I'd expect, after you've seen that result from other tools.

In almost every other case, I would say you're right. But the problem is this is an infrastructure library that many people will be using. I can imagine people using the CRT leak detection tools and seeing those two 'leaks' and assuming I'd been too lazy to clean up a trivial memory leaks. It's a professionalism issue IMHO. My other motivation is that if you don't REALLY know what is causing the leak, you could be masking much bigger problems later. Because I root caused it, changed the code, and it fixed it legitimately - I can NOW say with 100% confidence that it wasn't a real bug and have left it. But before, when I didn't know 100%, I was acting on faith. And in my experience, faith tends to blow up on you at 1am the night of code freeze.

Further, the MS documentation EXPLICITLY calls out the STL containers as having had this problem fixed. This is one case it's clearly not fixed. I'll be submitting a bug tomorrow on it.

That and it's just good nerdy fun to sort these things out. Now I can run all the configurations of my program without a peep out of the leak reporter and say that 'it doesn't leak' without the 'well, besides this leak that's not really a leak'.

Thanks guys for all the help!