Crash in XTP after upgrading to VS 2015 Upgrade 3

Hi,

I'm using XTP 17.2 in my application.

Today I have installed Visual Studio 2015 Upgrade 3, and now I have a 100% repro error during shut-down in XXP.

When the destructor of CXTPMarkupObject is running, the call

SAFE_DELETE(m_pComInitializer);

causes a GPF.

Call stack is

UIAutomationCore.dll!69079d89()    Unknown
[Frames below may be incorrect and/or missing, no symbols loaded for UIAutomationCore.dll]   
UIAutomationCore.dll!6905f64d()    Unknown
combase.dll!NotifyInitializeSpies(int,int,unsigned long,long)    Unknown
combase.dll!_CoUninitialize@0()    Unknown
>    ToolkitPro1720vc140U.dll!CXTPMarkupObject::~CXTPMarkupObject() Line 627    C++
ToolkitPro1720vc140U.dll!CXTPMarkupType::~CXTPMarkupType() Line 390    C++
ToolkitPro1720vc140U.dll!CXTPMarkupType::`vector deleting destructor'(unsigned int)    C++
ToolkitPro1720vc140U.dll!CXTPMarkupObject::OnFinalRelease() Line 643    C++
mfc140u.dll!0f954610()    Unknown
ToolkitPro1720vc140U.dll!CXTPMarkupType::CClassList::~CClassList() Line 294    C++
ucrtbase.dll!772b3489()    Unknown
ucrtbase.dll!772b057b()    Unknown
ucrtbase.dll!772b325e()    Unknown
ToolkitPro1720vc140U.dll!__scrt_dllmain_uninitialize_c() Line 395    C++
ToolkitPro1720vc140U.dll!dllmain_crt_process_detach(const bool is_terminating) Line 109    C++
ToolkitPro1720vc140U.dll!dllmain_crt_dispatch(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Line 134    C++
ToolkitPro1720vc140U.dll!dllmain_dispatch(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Line 217    C++
ToolkitPro1720vc140U.dll!_DllMainCRTStartup(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Line 258    C++

Somebody else with this problem? A known issue in XTP?

I have this in two applications, a simple dialog-based application and a complex application. All using multiple threads, lots of other libraries. The CJ samples are usually purpose-built and very simple. They are unfit to verify or reproduce problems in real applications.

I just installed VC 2015 Upgrade 3 and the Windows  2016.7 update. Now I get a reliably crash in about 80% when the XTP DLL shuts down, always when it releases COM pointers in their markup code. I use XTP for almost 10 years now in these two applications.

It crashes when XTP cleans up static objects created by calls like

IMPLEMENT_MARKUPCLASS(NULL, CXTPMarkupObjectProperty, CXTPMarkupObject)

in XTPMarkupBuilder.cpp

The crash happens when Windows releases the XTP DLL, and the DLL runs it's cleanup code. When deleting the static objects,

CXTPComInitializer

crashes when calling CoUninitialize();.

It's always the last object that causes it and in this case, the m_hr is S_OK, which probably means that the matched calls to Coinitialize() and CoUninitialize() have released all but the final reference. Then CoUninitialize() find some markup objects or something to clean up and crashes while doing so.

This may be a bug in Windows 10 anniversary update or XTP, I don't know. I have stripped down my application to the bare minimum, and it still happens. I even have the effect in another application, which also uses XTP and more than one thread.

But reports from my users are coming in from more and more users while Microsoft is shipping nthe Anniversary Update.

Thanks about the theme tip. I'll check that, just to be sure. But I don't use EnableFrameTheme I use skins and related stuff.

My app is rather large, massively multi-threaded and I use XTP for more than six years now. This problem showed up right after installed the anniv. update. I tested in a clean environment with a fresh W10 install. Same problem.

Today I've found a way to reliably trigger the behavior without working with my application for a long time. But I'm still none the wiser. I know the crash happens when the last static CXTPMarkupObjectProperty calls it's dtor and in that calls CoUninitialize() for the main thread of the application. Then UIAutomationCore.dll throws an access violation exception.

So I figure that this must be something in the XAMl render code. I use it in the status bar and in about 50 other places. But in the repro case I have a very reduced function set and maybe this allows me to find out which markup instructions are causing this. So far it looks as if the status bar is updated a few times, the crash happens on exit...

This has to be a dangling COM reference which the last call to CoUninitialize tries to delete and then crashes. Very hard t track down.

Thanks for the suggestion.

I don't have any calls to GetInstanceAddRef in my app. I don't interface directly with the XTP paint manager in my code.

I have now the same effect (crash on exiit) with a pretty simple dialog-based application.

It uses XTP skins and dialog boxes derived from XTPResizeDialog. When I open the main dialog and close it, no crash.

When I show a second dialog with a button on the main dialog => crash on exit while XTP is releasing its static Markup Objects.

Interestingly, the second dialog does not use markup, only the main dialog renders some markup in a static control.

Maybe this smaller test application makes it possible to figure out what exactly is causing this behavior. If I cannot find it today I will re-compile XTP with the ATL debug macros enabled. Maybe I can find the dangling COM reference it creates (or maybe by code, by accident) this way.

Thanks,

I gave your idea a try. No change, unfortunately.
Still the crash when XTP releases it's static COM objects when the DLL is unloaded by Windows.

I have now finished my real work and I may have some time over the weekend to dig further into this.