Crash with Win 10 Version 216.07 and COM

After installing Windows 10 update 1607 and Visual Studio 2015 Update 3 yesterday I have a reproducible (as in 90%) crash in XTP in the destructor of

    ~CXTPComInitializer()
    {
        if(S_OK == m_hr || S_FALSE == m_hr)
        {
            CoUninitialize();
        }
    }

I get an GPF when XTP calls CoUninitialize during the program shut-down. 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
ToolkitPro1720vc140UD.dll!CXTPComInitializer::~CXTPComInitializer() Line 1286    C++

The m_hr in this case is S_OK which indicates a successful call to CoInitialize in your constructor.

This code is old and the only change was Visual Studio 2015 Upgrade 3 or the most recent Windows update.

I re-compiled XTP after installing the Visual Studio Upgrade.

The check for S_FALSE is correct, and in accordance with what is stated in MSDN.

CoInitialize returns S_FALSE if the thread has already successfully called CoInitialize. In that case it increments only an internal ref count and returns S_FALSE.

CoUnInitialize must be called for S_OK and S_FALSE. Your code is correct.

The crash does not happen when CoUninitialize is called and m_hr is S_FALSE. This decrements the ref count and works. Only in the last call, when m_hr is S_TRUE, the crash happens. Hence my assumption that there is some 'dangling' COM reference that the system tries to free in that call, and this causes the GPF.

I still have no clue about what's causing this. In my small sampe app with only a main dialog and a second dialog, I can repro the crash100% when I just open and close the second dialog (via a button on the first). But that's just a simple XTPResizableDialog init, no markup is used etc.

As soon as I have a free hour I will try if compiling XTP with
#define _ATL_DEBUG_INTERFACES
#define _ATL_DEBUG_REFCOUNT
reveals leaks.

I'm still trying to figure out what's going on. I try to strip down the test app as much as possible in that process.

I have one main dialog (XTPResizeDialog-derived). On that an XTPButton. When I open the specific dialog via this button and close it with ESC, the crash in ~CXTPComInitializer happens 100% of the time.

So I tried another dialog (About box, also XTPResizeDialog-derived) with the same button. NO crash.

I then stripped down the dialog which causes the crash, removing all code not needed, all message handlers, just binimum OnInitDialog DoDataXchange etc. Whatever I did, the crash still happens when I close my application.

I noticed that the address of the crash various between 0x00000000 and 0x00000028, depending on whether or not I enable XTP skinning for my dialog. Maybe a HINT?

Then another weird thing happened. The crash dialog has controls to open File dialogs. When I open a CFileDialog from the crash dialog, and then close both dialogs and the application, the crash in ~CXTPComInitializer does NOT happen.

Start app > Main dialog > open Crash dialog > close > close app > Crash.
Start app > Main dialog > open Crash dialog > open File Dialog > close > close > close app > NO Crash.

Can this be some kind of hook or something in the XTP code that is triggered? It's always the static variable and it crashes when the XTP DLL shuts down, when in the CXTPMarkupType::CClassList::~CClassList() method.

I had hoped that being able to repro it in a small test app would make it easy to find, but I have still no clue. Maxyb this is a bug in the Microsoft UIAutomationCore.dll shipped with the latest Windows update. Or maybe iit just revealed a dangling problem in XTP...

Still researching

MacW wrote: It's always the static variable and it crashes when the XTP DLL shuts down, when in the CXTPMarkupType::CClassList::~CClassList() method.

I'm still trying to figure out what's going on.

Unfortunately it's not easy to strip my test app down. It relies on 9 of my DLLs, a bunch of 3rd party libraries, Open Source frameworks etc...its also multi-threaded. I try to figure out what's causing the "COM leak or whatever"...

I know now that the crash does not happen when I add an extra

OleInitialize(NULL);

into the ExitInstance method of my CWinApp-derived class.

And I have a dialog that causes the behavior 100%, unless I open a CFileDialog from this dialog...when you open a CFileDialog, Windows loads tons of DLLs and whatever and this seems to shuffle something into place which prevents the crash when XTP finally runs its COM cleanup loop.

I really have no idea still.

MacW, does calling "OleInitialize(NULL)" in ExitInstance working consistently for you in all cases? If so, maybe I'll give it a try and see if we get similar results.

I would recommend placing CoUninitialize and GdiplusShutdown calls after cleaning up all XTP resources, right before ExitInstance, as XTP can still hold COM references that will be released only after COM uninitialization in your case, which can lead to unpredicted behavior. Releasing OLE message filter in such a way look more like a hack to me and is error prone, it's better to invest time in making sure all references are released prior to ExitInstance in a natural way than deal with consequences of extra release calls.

This only indicates that there are some dangling COM references which get released after ExitInstance. I cannot know who holds those references as I have no sample that has this issue, it can be both a bug in XTP or the application that uses it. Anywayt with new XTPShutdown function it will be possible to make sure XTP cleanup occurs before COM uninitialization if you call it explicitly.

I have the exact same problem.

This sounds great. I test it as soon as your new release comes out.

17.3 still crashes in the call to

SAFE_DELETE(m_pComInitializer);

in the file XTPMarkupObject.cpp.

I have added a call to XTPShutdown() right before I call CWinApp::ExitInstance() in my derived class.
The crash happens during the shut-down code of MFC, my code is already cleaned up at the time.

it's the static variables XTP uses that are causing this dreadful problem. We need to get this fixed asap.
We waited so long for the 17.3 but the problem still exists in your code.

Please fix or post a work-around in days, not months. Thank you.
I don't care for anything else in XTP unless this reproducible crash is fixed.

We're currently working on a fix, a patch will be provided within a few days.

Hi,

this patch did not fix the problem.

Toolkit pro 17.3, Windows 10 pro 1607, VC 2015 SP3

Applied the patch and rebuilded the library...

Compiled and started your GridSample...

On exit..

Crashes somtimes with this exception (translated from the german output):

Thread 0x1b44 has ended with code 0.
Raised exception: read access violation
"this" was "0xDDDDDE05".

Line 271 in afxtempl.h

...
/*============================================================================*/
// CArray<TYPE, ARG_TYPE> inline functions

template<class TYPE, class ARG_TYPE>
AFX_INLINE INT_PTR CArray<TYPE, ARG_TYPE>::GetSize() const
---here-->>>    { return m_nSize; }
...


Callstack:
>    ToolkitPro1730vc140D.dll!CArray<CXTPReportColumn *,CXTPReportColumn *>::GetSize() Zeile 271    C++
     ToolkitPro1730vc140D.dll!CXTPReportColumns::GetCount() Zeile 349    C++
     ToolkitPro1730vc140D.dll!CXTPReportColumns::Find(int nItemIndex) Zeile 258    C++
     ToolkitPro1730vc140D.dll!CXTPReportRow::GetAccessibleState(tagVARIANT varChild, tagVARIANT * pvarState) Zeile 1788    C++
     ToolkitPro1730vc140D.dll!CXTPAccessible::XAccessible::get_accState(tagVARIANT varChild, tagVARIANT * pvarState) Zeile 888    C++
     [Externer Code]    
     [Unten angegebene Rahmen sind möglicherweise nicht korrekt und/oder fehlen, keine Symbole geladen für oleacc.dll]    
     ToolkitPro1730vc140D.dll!CXTPControl::OnExecute() Zeile 573    C++
     [Externer Code]    
     GridSample.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Zeile 26    C++
     [Externer Code]    


And way more often crashes this way:

Thread 0x1140 ended with code 0.
..\..\Source\Common\XTPApplication.cpp(72) : atlTraceGeneral - Codejock XTP application shutting down ...
Exception raised at 0x69BDA0C9 (UIAutomationCore.dll) in GridSample.exe: 0xC0000005: Read access violation at position 0x00000008.

In file XTPSystemHelpers.h line 1289
...
    ~CXTPComInitializer()
    {
        if(S_OK == m_hr || S_FALSE == m_hr)
        {
---here--->            CoUninitialize();
        }
    }
...

Callstack:
     UIAutomationCore.dll!69bda0c9()    Unbekannt
     [Unten angegebene Rahmen sind möglicherweise nicht korrekt und/oder fehlen, keine Symbole geladen für UIAutomationCore.dll]    
     [Externer Code]    
>    ToolkitPro1730vc140D.dll!CXTPComInitializer::~CXTPComInitializer() Zeile 1289    C++
     [Externer Code]    
     ToolkitPro1730vc140D.dll!CXTPMarkupObject::~CXTPMarkupObject() Zeile 626    C++
     ToolkitPro1730vc140D.dll!CXTPMarkupType::~CXTPMarkupType() Zeile 389    C++
     [Externer Code]    
     ToolkitPro1730vc140D.dll!CXTPMarkupObject::OnFinalRelease() Zeile 642    C++
     [Externer Code]    
     ToolkitPro1730vc140D.dll!CXTPMarkupObject::Release() Zeile 648    C++
     ToolkitPro1730vc140D.dll!CXTPMarkupType::CClassList::~CClassList() Zeile 294    C++
     ToolkitPro1730vc140D.dll!CXTPSingleton<CXTPMarkupType::CClassList>::Destroy(void * ptr) Zeile 112    C++
     ToolkitPro1730vc140D.dll!CXTPSingletonPointer::Destroy() Zeile 105    C++
     ToolkitPro1730vc140D.dll!CXTPSingletonPointer::OnApplicationShutdown(CXTPApplication * pApplication) Zeile 123    C++
     ToolkitPro1730vc140D.dll!CXTPObservable<CXTPApplication,IXTPApplicationEvents>::Notify(void(IXTPApplicationEvents::*)(CXTPApplication *) method) Zeile 1395    C++
     ToolkitPro1730vc140D.dll!CXTPApplication::Shutdown() Zeile 75    C++
     ToolkitPro1730vc140D.dll!XTPShutdown() Zeile 93    C++
     ToolkitPro1730vc140D.dll!DllMain(HINSTANCE__ * hInstance, unsigned long dwReason, void * __formal) Zeile 59    C++
     [Externer Code]    

Please keep working on the problem as this release is unusable in the mentioned configuration.

Tom

Hi I tested the patch here and still have the crash.
In my case however I had solved the problem by adding  CoInitialize(NULL) in the application ExitInstance().
With the patch I still need CoInitialize(NULL) to avoid crash.

Cheers
Felipe

Hi,

i tested the new patch with the GridSample and it throws the same exceptions.

So i inspected the code and my findings are:

The CoUninitialize() exception only raises when using ToolkitPro as a DLL. When using a static build
everything works fine so far regarding the CoUninitialize() problem.

You are calling CoInitialize() and CoUninitialize() in the DllMain. Microsoft says: "Because there is no
way to control the order in which in-process servers are loaded or unloaded, do not call CoInitialize,
CoInitializeEx, or CoUninitialize from the DllMain function."

CoInitialize() should be called for every thread. Is this guaranteed when it is only called during the
construction of the markup objects and the singleton approach?

Even in a static build i still get the following error i mentioned in my last post. But i cant reproduce
it as it raises at about every tenth run:

Thread 0x1b44 has ended with code 0.
Raised exception: read access violation
"this" was "0xDDDDDE05".

Line 271 in afxtempl.h

...
/*============================================================================*/
// CArray<TYPE, ARG_TYPE> inline functions

template<class TYPE, class ARG_TYPE>
AFX_INLINE INT_PTR CArray<TYPE, ARG_TYPE>::GetSize() const
---here-->>>    { return m_nSize; }
...


Callstack:
>    ToolkitPro1730vc140D.dll!CArray<CXTPReportColumn *,CXTPReportColumn *>::GetSize() Zeile 271    C++
     ToolkitPro1730vc140D.dll!CXTPReportColumns::GetCount() Zeile 349    C++
     ToolkitPro1730vc140D.dll!CXTPReportColumns::Find(int nItemIndex) Zeile 258    C++
     ToolkitPro1730vc140D.dll!CXTPReportRow::GetAccessibleState(tagVARIANT varChild, tagVARIANT * pvarState) Zeile 1788    C++
     ToolkitPro1730vc140D.dll!CXTPAccessible::XAccessible::get_accState(tagVARIANT varChild, tagVARIANT * pvarState) Zeile 888    C++
     [Externer Code]    
     [Unten angegebene Rahmen sind möglicherweise nicht korrekt und/oder fehlen, keine Symbole geladen für oleacc.dll]    
     ToolkitPro1730vc140D.dll!CXTPControl::OnExecute() Zeile 573    C++
     [Externer Code]    
     GridSample.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Zeile 26    C++
     [Externer Code]    

Hope this helps.

Tom