Crash in XTP after upgrading to VS 2015 Upgrade 3
Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Toolkit Pro
Forum Description: Topics Related to Codejock Toolkit Pro
URL: http://forum.codejock.com/forum_posts.asp?TID=23087
Printed Date: 23 December 2024 at 10:20pm
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com
Topic: Crash in XTP after upgrading to VS 2015 Upgrade 3
Posted By: MacW
Subject: Crash in XTP after upgrading to VS 2015 Upgrade 3
Date Posted: 05 August 2016 at 2:48pm
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?
|
Replies:
Posted By: markr
Date Posted: 05 August 2016 at 7:00pm
|
Just curious - are you able to reproduce this problem in any of the samples?
- Mark R.
|
Posted By: MacW
Date Posted: 11 August 2016 at 7:11am
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.
|
Posted By: MacW
Date Posted: 18 August 2016 at 2:33am
|
The problem seems to happen only on computers with Windows 10 anniversary update installed.
|
Posted By: MacW
Date Posted: 22 August 2016 at 10:12am
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.
|
Posted By: markr
Date Posted: 22 August 2016 at 1:48pm
|
Interesting - so far I can't reproduce this problem in my applications, which make extensive use of XTP frame themes, markup, and threading. All tests on Windows 10 Anniversary Edition (at least so far) have been fine.
I have no idea if it applies to your scenario in any way, but I've found that it's very important to balance calls to EnableFrameTheme(TRUE) and EnableFrameTheme(FALSE). In the past if I failed to do so, I'd experience odd crashes similar to what you're seeing.
- Mark R.
|
Posted By: MacW
Date Posted: 22 August 2016 at 2:02pm
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.
|
Posted By: cpede
Date Posted: 24 August 2016 at 3:44am
|
Just a wild suggestion. I experienced crashes while exiting my app. I found out that it was very important to match the calls to:
CXTPPaintManager::GetInstanceAddRef() |
and
CXTPPaintManager::ReleaseInstance() |
-cpede
-------------
Product: Xtreme ToolkitPro (24.0.0)
Platform: Windows 10 (x64)
Language: Visual Studio 2017 (C++)
|
Posted By: MacW
Date Posted: 24 August 2016 at 5:01am
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.
|
Posted By: cpede
Date Posted: 24 August 2016 at 5:36am
|
Well it sounds very much like the problem I had. I made a control panel applet, basically a dialog based app. When I opened the dialog and closed it - no problems, but if I opened a dialog from within the main dialog it crashed on exit. Then I added the two call around the main call to the main dialog, and then it worked?
-cpede
-------------
Product: Xtreme ToolkitPro (24.0.0)
Platform: Windows 10 (x64)
Language: Visual Studio 2017 (C++)
|
Posted By: MacW
Date Posted: 25 August 2016 at 10:23am
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.
|
|