|
We have been using 17.3, but have recently downloaded 19.2 for eval. In our application, one customer is experiencing a shutdown crash on Windows Data Center 2016. Was able to pinpoint the problem crash to be the shutdown of XTP in all the static markup objects destructors. Specifically, when they call delete on CXTPComInitializer which ends ups calling CoUninitialize() in the destructor of CXTPComInitializer.
I thought that maybe if it is crashing in our application, I could send a sample application to the customer that would have the same basic code path. I sent RibbonMDISample as our application uses the XTP ribbon and it is MDI. Sure enough, the RibbonMDISample program crashes on their system.
After looking at the code, I was surprised at the number of CoInitialize() and CoUnitialize() calls are made on startup and shutdown. Our program already calls AfxOleInit() so I'm not sure why all those calls needed to be there anyway. I didn't see them doing on separate threads and I thought if something was happening on another thread, the thread initialization and shutdown code should call CoInitialize() and CoUninitialize(). Microsoft even has warnings about when to call and not call those functions...certainly not during DllMain()...and probably during C++ runtime init and uninit is probably not good locations either.
So, I decided to build a version of toolkit pro with the CoInitialize() and CoUnitialize() functions commented out in the toolkit pro source code and I rebuilt RibbonMDISample against that version. And...the software didn't crash on the customers environment.
Is there really a good reason for all those CoInitialize() and CoUninitialize() function calls? It doesn't appear to me to be a good reason.Sure...tell the customer that to use the library they have to make the call...
Anybody else see crashes on the CXTPComInitializer destructor?
|