Crash with Win 10 Version 216.07 and COM
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=23088
Printed Date: 21 November 2024 at 1:35pm
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com
Topic: Crash with Win 10 Version 216.07 and COM
Posted By: MacW
Subject: Crash with Win 10 Version 216.07 and COM
Date Posted: 06 August 2016 at 5:35am
|
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. |
Replies:
Posted By: kstowell
Date Posted: 27 August 2016 at 9:36am
I am not sure but S_FALSE == m_hr doesn't look correct to me, CoUninitialize() should only be called if a call to CoInitialize() returns S_OK? I know S_FALSE indicates it was already initialized. I will need to investigate this further to verify, try changing the code to the following, recompile let me know what your results are:
------------- Kirk Stowell, President and CEO CODEJOCK SOFTWARE SOLUTIONS< |
Posted By: MacW
Date Posted: 27 August 2016 at 10:59am
|
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. |
Posted By: kstowell
Date Posted: 27 August 2016 at 11:47am
|
Ok, it was just a thought, I will have one of our developers take a closer look at this then. Do you have a set of steps we can follow to recreate the problem? ------------- Kirk Stowell, President and CEO CODEJOCK SOFTWARE SOLUTIONS< |
Posted By: MacW
Date Posted: 29 August 2016 at 9:29am
|
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 |
Posted By: Sven
Date Posted: 29 August 2016 at 10:03am
| Are you using COM smart pointers in static objects? In my case (not related to XTP) I had GPFs on exit when a COM smart pointer in a static object was released after CMyWinApp::ExitInstance. |
Posted By: markr
Date Posted: 29 August 2016 at 10:48am
This is also true for the strange crash reports I've received over the years as well. I've never been able to reproduce them in the development environment, but I get them on a semi-regular basis. We don't use skinning - appears to be related to the frame hook in our case. Also, we're linking statically. Recent crashes look like this:
The fact that you can reproduce your crash scenario consistently is encouraging, at least. Maybe it can help lead us to a solution. - Mark R.
|
MacW wrote:Posted By: astoyan
Date Posted: 30 August 2016 at 12:18am
|
Can anybody upload your test application for us to debug or at least if you can add critical changes to any of the sample that we provide and share the patch? We'll try to fix it asap once we have consistent crashing scenario and the code. Regards, Alexander
|
Posted By: MacW
Date Posted: 05 September 2016 at 12:25pm
|
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. |
Posted By: astoyan
Date Posted: 05 September 2016 at 5:11pm
|
It can be an issue with late COM uninitialization because of destructors called from static storage. This caused similar issues with other components. However, good news is that in 17.3 we have finally introduced a single point unitialization function called XTPShutdown which is still called during static storage destruction for backward compatibility, but this time it ensures simlutaneous uninitialization of all global data and allows making this call manually for sensitive applications, e.g. in ExitInstance. Anyway, we still want to pin point all the reported crashes to check their origin and fix whatever is possible. Regards, Alexander
|
Posted By: markr
Date Posted: 06 September 2016 at 3:13pm
|
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. EDIT: It appears that I'm currently calling CoUninitialize in ExitInstance (and CoInitializeEx in InitInstance).
- Mark R.
|
Posted By: Marco1
Date Posted: 06 September 2016 at 4:53pm
FYI, this is how my ExitInstance looks the last years. It didn't change and is running fine:
------------- Product: XTP 18.3.0 on VS 2017 Platform: VS 2017 / Windows 10 (64bit) |
Posted By: astoyan
Date Posted: 06 September 2016 at 9:51pm
|
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. Regards, Alexander
|
Posted By: MacW
Date Posted: 07 September 2016 at 9:07am
I meant adding an extra CoInitialize(NULL) (init not de-init) right before calling ExitInstance of the super class prevented the crash in my both test cases.
In this case the static destructor in XTP runs through as usual but does not no crash. My application shuts down properly, no crashes or anything. I just don't know if this causes any side-effects. I don't call any other XTP cleanup routines. When I add the cleanup stuff you do, there is no difference. The crash still happens without the extra call to CoInitialize. |
Posted By: astoyan
Date Posted: 10 September 2016 at 4:34pm
|
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. Regards, Alexander
|
Posted By: MacW
Date Posted: 18 October 2016 at 8:36am
|
After installing Service Pack 3 of Visual Studio, my trick with the extra OleInitialize in Exitinstance no longer works. XTP crashes during shut-down reliably in CXTPMarkupObject::~CXTPMarkupObject() ... SAFE_DELETE(m_pComInitializer); << Call stack is ntdll.dll!7760e8af() Unknown ntdll.dll!7761ff1f() Unknown combase.dll!74321510() Unknown combase.dll!742e2d0c() Unknown combase.dll!742e29d0() 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!01f44610() Unknown ToolkitPro1720vc140U.dll!CXTPMarkupType::CClassList::~CClassList() Line 294 C++ ucrtbase.dll!74e23489() Unknown ucrtbase.dll!74e2057b() Unknown ucrtbase.dll!74e2325e() 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 207 C++ ToolkitPro1720vc140U.dll!_DllMainCRTStartup(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Line 248 C++ |
Posted By: cpede
Date Posted: 19 October 2016 at 6:55pm
|
I have the exact same problem. If I open a dialog in my program and before exiting, I get the exception. -cpede ------------- Product: Xtreme ToolkitPro (24.0.0) Platform: Windows 10 (x64) Language: Visual Studio 2017 (C++) |
Posted By: astoyan
Date Posted: 19 October 2016 at 10:36pm
|
This issue has been fixed for 17.3. The update is about to be released. Once it's out please re-check it and let me know if it still happens. Regards, Alexander
|
Posted By: MacW
Date Posted: 20 October 2016 at 8:45am
|
This sounds great. I test it as soon as your new release comes out. |
Posted By: TomPP
Date Posted: 05 December 2016 at 11:42am
|
Hi, still crashes for me in i.e. the GridSample of 17.3 on Windows 10 pro 1607 and VC 2015 SP3. Just starting and stopping the sample throws an exception in the CoUninitializelLine. ~CXTPComInitializer() { if(S_OK == m_hr || S_FALSE == m_hr) { CoUninitialize(); } } Next try was the ReportDialog Sample. After exiting the Sample (just start and exit) it shows a lot of memory leaks. ToolkitPro.cpp(59) : atlTraceGeneral - Codejock ToolkitPro Terminating! Detected memory leaks! Dumping objects -> ..\..\Source\ReportControl\XTPReportControl.cpp(5894) : {1744} normal block at 0x00C48500, 160 bytes long. Data: < > 90 FE 8C 02 02 00 00 00 00 00 00 00 00 00 00 00 f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {928} normal block at 0x00C58A18, 18 bytes long. Data: < > 80 03 0D 10 01 00 00 00 01 00 00 00 01 00 00 00 c:\source\vc15 libs\xtreme toolkitpro v17.3.0\samples\reportcontrol\reportdialog\messagerecord.cpp(250) : {927} normal block at 0x00C80C48, 176 bytes long. Data: <L > 4C 17 B7 00 01 00 00 00 00 00 00 00 00 00 00 00 ..\..\Source\ReportControl\XTPReportRecordItem.cpp(1779) : {924} normal block at 0x00C7F2C8, 52 bytes long. ... ... ... f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dumpcont.cpp(23) : atlTraceGeneral - a CCmdTarget object at $00C31F48, 224 bytes long Object dump complete. Das Programm "[9336] ReportDialog.exe" wurde mit Code 0 (0x0) beendet. A simple XTPReportControls in a Dialog or PropertyPage chrashes on exit too. No problems so far in Windows 7 pro. If you need more input, please let me know. Tom |
Posted By: MacW
Date Posted: 13 December 2016 at 4:10am
|
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. |
Posted By: Felipe
Date Posted: 04 January 2017 at 10:12am
|
Same crash here with Windows 10 and v17.3 Please publish a solution or a workaround, we are blocked. |
Posted By: astoyan
Date Posted: 05 January 2017 at 12:21am
|
We're currently working on a fix, a patch will be provided within a few days. Regards, Alexander
|
Posted By: astoyan
Date Posted: 12 January 2017 at 7:37pm
|
The issue has been fixed. The patch for ToolkitPro 17.3 can be downloaded from here - uploads/8199/TID-23088.zip" rel="nofollow - uploads/8199/TID-23088.zip (unidiff log + modified sources included). Please let me know if it works properly or not. Regards, Alexander
|
Posted By: TomPP
Date Posted: 12 January 2017 at 11:09pm
|
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 |
Posted By: astoyan
Date Posted: 13 January 2017 at 12:03am
|
Thank you, Tom, for reporting this quickly. I haven't tested with this particular sample and was able to reproduce the issue right away, it's a good indication it'll be fixed soon, it's just something minor that has been overlooked. Regards, Alexander
|
Posted By: Felipe
Date Posted: 13 January 2017 at 7:01am
|
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 |
Posted By: astoyan
Date Posted: 13 January 2017 at 8:18pm
|
I appreciate everyone's help with debugging the issue. Please try out a new patch with affected source files (previous fix included) - uploads/8199/TID-23088-2.zip" rel="nofollow - uploads/8199/TID-23088-2.zip . Regards, Alexander EDITED: Do not use this patch as it contains a bug. Read my next message for details.
|
Posted By: TomPP
Date Posted: 14 January 2017 at 1:51am
|
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 |
Posted By: astoyan
Date Posted: 14 January 2017 at 10:15pm
|
Hi Tom, You are absolutely right about COM initialization requirements in multi-threaded application. The second patch did not take this requirement into account so it is not correct, I have reverted it in the source code and will ask you and others to use only the first patch - uploads/8199/TID-23088.zip" rel="nofollow - uploads/8199/TID-23088.zip . You are also right about making a call to CoUninitialize from DllMain, however starting from 17.3 you can now control this by calling XTPShutdown from a proper place. As for the crashes that you are still getting, what I think this time it's not because of the bug in the code, it's rather because of the UI Automation library that you're using (I figured it out from the call-stack). What happens is when you start GridSample it does not initialize COM itself, instead some internal XTP classes initialize COM for their own purposes, thus when the application is shutting down XTP classes uninitialize COM which unloads COM libraries completely because there are no other references to COM. However your UI Automation libraries still use COM, because it's how Automation is implemented. So, with COM libraries unloaded the first Automation call leads to undefined behavior, or a crash in this case. Adding CoInitialize call to CGridSampleApp constructor WITHOUT adding CoUnitialize call in its destructor will prevent from COM unloading and fix your crash. Also if you run GridSample without UI Automation attached you won't see the crash. Please let me know if you are able to confirm my theory. Regards, Alexander |
Posted By: sbinder
Date Posted: 20 January 2017 at 8:04am
|
If I call XTPShutdown() in ExitInstance before CWinApp::ExitInstance() is called my application crashs when Windows is trying to (my application prevents it) shut down (Win7, 8.1 and 10)! |
Posted By: astoyan
Date Posted: 21 January 2017 at 12:36am
|
Sbinder, can you please provide a stack trace for the crash? Also please make sure all COM references are released properly in your scenario prior to XTPShutdown call. It is recommended to call it as late as possible. Regards, Alexander
|
Posted By: sbinder
Date Posted: 23 January 2017 at 6:04am
|
Call Stack: XTP0173xd.dll!CXTPSingletonPointer::GetInstance() Line 60 + 0x19 bytes C++
XTP0173xd.dll!CXTPSingleton<CXTPHookManager>::Instance() Line 123 + 0xc bytes C++ > XTP0173xd.dll!XTPHookManager() Line 349 C++ XTP0173xd.dll!CXTPHookManager::HookWndProc(HWND__ * hWnd=0x00111052, unsigned int message=22, unsigned int wParam=1, long lParam=0) Line 435 + 0x9 bytes C++ user32.dll!__InternalCallWinProc@20() + 0x2b bytes user32.dll!UserCallWinProcCheckWow() + 0x30a bytes user32.dll!DispatchClientMessage() + 0xf0 bytes user32.dll!___fnDWORD@4() + 0x49 bytes ntdll.dll!_KiUserCallbackDispatcher@12() + 0x36 bytes win32u.dll!_NtUserMessageCall@28() + 0xc bytes user32.dll!RealDefWindowProcWorker() + 0xba bytes user32.dll!RealDefWindowProcA() + 0x5d bytes mfc100d.dll!AfxUnlockGlobals() + 0xb4 bytes user32.dll!__InternalCallWinProc@20() + 0x2b bytes user32.dll!UserCallWinProcCheckWow() + 0x30a bytes user32.dll!CallWindowProcA() + 0x98 bytes mfc100d.dll!CWnd::DefWindowProcA() + 0x34 bytes mfc100d.dll!CWnd::WindowProc() + 0x52 bytes mfc100d.dll!AfxCallWndProc() + 0xf3 bytes mfc100d.dll!AfxWndProc() + 0xa6 bytes mfc100d.dll!AfxWndProcBase() + 0x5b bytes user32.dll!__InternalCallWinProc@20() + 0x2b bytes user32.dll!UserCallWinProcCheckWow() + 0x30a bytes user32.dll!CallWindowProcA() + 0x98 bytes XTP0173xd.dll!CXTPHookManager::HookWndProc(HWND__ * hWnd=0x00111052, unsigned int message=59, unsigned int wParam=268, long lParam=0) Line 431 + 0x1c bytes C++ user32.dll!__InternalCallWinProc@20() + 0x2b bytes user32.dll!UserCallWinProcCheckWow() + 0x30a bytes user32.dll!DispatchClientMessage() + 0xf0 bytes user32.dll!___fnDWORD@4() + 0x49 bytes ntdll.dll!_KiUserCallbackDispatcher@12() + 0x36 bytes user32.dll!GetMessageA() + 0x53 bytes mfc100d.dll!AfxInternalPumpMessage() + 0x23 bytes mfc100d.dll!CWinThread::PumpMessage() + 0xe bytes mfc100d.dll!CWinThread::Run() + 0x8d bytes mfc100d.dll!CWinApp::Run() + 0x59 bytes mfc100d.dll!AfxWinMain() + 0xef bytes LogoMed.exe!WinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x01a25766, int nCmdShow=1) Line 26 C++ LogoMed.exe!__tmainCRTStartup() Line 547 + 0x2c bytes C LogoMed.exe!WinMainCRTStartup() Line 371 C kernel32.dll!@BaseThreadInitThunk@12() + 0x24 bytes ntdll.dll!__RtlUserThreadStart() + 0x2f bytes ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes |
Posted By: sbinder
Date Posted: 23 January 2017 at 6:05am
|
I call XTPShudown() before CWinApp::ExitInstance(), this is as late as possible. I can't find a unreleased COM-Reference. I get a Debug Assert in XTPSingleton.cpp Line 60: void* CXTPSingletonPointer::GetInstance()
{ ASSERT(!m_bDestroyed); ... |
Posted By: astoyan
Date Posted: 25 January 2017 at 11:27pm
|
I cannot see a XTPShutdown on your stack trace so I assume the error occurs before or after it is called. Are you using SkinFramework? If so, have you tried to unload skin before making a call to XTPShutdown? The best option in this case would be a working sample so that I can see exactly what and how you're doing instead of making and testing guesses. Is it possible for you to make it or modify any existing one? Regards, Alexander
|
Posted By: sbinder
Date Posted: 03 February 2017 at 8:05am
|
I am not using SkinFramework, but I use Mapi and I assume that the problem is related to it. I am currenty missing the time to create an example.
|
Posted By: Don
Date Posted: 07 March 2017 at 3:03pm
|
I recently started to see a crash in my app just like the one described in the original post. I have a Windows 10 laptop that does not have a touch screen. I believe the crash started happening when I installed an app that lets you use an iPad as a second monitor for your PC (duetdisplay). That app seems to install touch input drivers which lets it accept touch screen input from the iPad. I believe that the touch input drivers are the reason for UIAutomationCore.dll appearing in the call stack, and are a factor in causing this crash. I haven't tried the patch posted above, but I thought I'd give you this info in case it would help reproduce the problem.
|
Posted By: rdhd
Date Posted: 23 May 2018 at 12:23pm
|
We have CJ 18.2. And I am getting this same crash issue with the crash in UIAutomation. I have to have an actual ribbon created. So apparently this hasn't been fixed? Any progress on it? UIAutomationCore.dll!std::_Hash<std::_Umap_traits<unsigned long,CApartmentTracker * __ptr64,std::_Uhash_compare<unsigned long,std::hash<unsigned long>,std::equal_to<unsigned long> >,std::allocator<std::pair<unsigned long const ,CApartmentTracker * __ptr64> >,0> >::lower_bound() Unknown
UIAutomationCore.dll!CApartmentTracker::PreUninitialize(unsigned long) Unknown combase.dll!NotifyInitializeSpies(int fInitialize, int fPreNotify, unsigned long dwFlags, HRESULT hrInit) Line 3151 C++ combase.dll!CoUninitialize() Line 3903 C++ > ToolkitPro1820vc140x64U.dll!CXTPMarkupObject::~CXTPMarkupObject() Line 624 C++ ToolkitPro1820vc140x64U.dll!CXTPMarkupType::`vector deleting destructor'(unsigned int) C++ mfc140u.dll!CCmdTarget::InternalRelease() Line 177 C++ ToolkitPro1820vc140x64U.dll!CXTPMarkupType::CClassList::~CClassList() Line 294 C++ ToolkitPro1820vc140x64U.dll!CXTPSingletonPointer::Destroy() Line 120 C++ ToolkitPro1820vc140x64U.dll!CXTPApplication::Shutdown() Line 81 C++ ToolkitPro1820vc140x64U.dll!XTPShutdown() Line 106 C++ ToolkitPro1820vc140x64U.dll!DllMain(HINSTANCE__ * hInstance, unsigned long dwReason, void * __formal) Line 65 C++ ToolkitPro1820vc140x64U.dll!dllmain_dispatch(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Line 195 C++ ntdll.dll!LdrpCallInitRoutine() Unknown ntdll.dll!LdrShutdownProcess() Unknown ntdll.dll!RtlExitUserProcess() Unknown kernel32.dll!ExitProcessImplementation () Unknown ucrtbase.dll!exit_or_terminate_process() Unknown ucrtbase.dll!common_exit() Unknown Edge.exe!__scrt_common_main_seh() Line 262 C++ |
Posted By: rdhd
Date Posted: 23 May 2018 at 5:09pm
|
Notice that the call to Couninitialize is via DllMain. The MSDN says this: Because there is no way to control the order in which in-process servers are loaded or unloaded, do not call CoInitialize, https://msdn.microsoft.com/en-us/library/windows/desktop/ms695279%28v=vs.85%29.aspx" rel="nofollow - CoInitializeEx , or https://msdn.microsoft.com/en-us/library/windows/desktop/ms688715%28v=vs.85%29.aspx" rel="nofollow - CoUninitialize from the https://msdn.microsoft.com/en-us/library/windows/desktop/ms682583%28v=vs.85%29.aspx" rel="nofollow - DllMain function. In my case, the crash doesn't always occur. Could this be a timing issue? The only thread left when I crash is the main thread. I also happen to have a desktop box and one of my monitors (the one the app is on) is a touch screen. I mention that after seeing the reply about using an iPad. We have always called CoInitialize soon after we start up. But it is not during the call to DllMain. I did just add a call to CoInitialize in another class constructor that gets called before the first call CJ makes. That keeps CJ from crashing during shutdown. But that just moved the crash to the CoUninitialze call I added at the same time in the destructor. But that code is called during our DllMain too. Same type of setup CJ has - we have a static object that gets created/destroyed during the dll init phase. Hence, I violated the MSDN rule on calling from DllMain. I only chose it because it was the only way I had to beat CJ and be the first to call CoInitialize. Since CJ is doing this during DLL loading, I really have no other way to beat CJ to the call. I can keep the crash from occurring by not calling the CoUnitialize call I added to compensate for the call to init I added. My best guess is that CJ needs to move this out of the DllMain code path. Why are these markup objects needed during process load time? UIAutomationCore is trying to uninit something called CApartmentTracker. There is a std::map of long to CApartmentTracker*. But I can't tell what it is doing other than trying to load data from an address that is invalid (causes the AV). I have found no documentation on this CApartmentTracker class. But the class code is in uiautomationcore.dll. Is it tracking something in a DLL that has been unloaded?
|
Posted By: TomPP
Date Posted: 24 May 2018 at 5:13am
|
What i found out.... I use a password manager (Sticky Password) to manage my accounts. This manager has an option to integrate via UI Automation. When enabled, this COM error occurs within programs using the CJ Toolkit but in no other software. When disabled, no error occurs at all. This belongs only to Windows 10, with Win 7 everything is fine. Tom
|
Posted By: rdhd
Date Posted: 24 May 2018 at 12:13pm
|
I have modified our application shutdown code run after we exit the process messages loop. We call our own shutdown APIs. I added a call to the CJ shutdown function. So far, that keeps the crash from occurring. I also noticed my (new) box has Win 10 version 1607 on it. I tested another box we use in certification because I should have heard about this issue from testing. No crashes there using my same workflow. But that box has version 1709 on it. I'm updating my box to 1709 after which I will undo my change and see if the crash can be reproduced. Perhaps this is an OS issue that has been fixed.
|
Posted By: rdhd
Date Posted: 24 May 2018 at 3:55pm
|
I had the OS update to 1709. The crash goes away. I have not tried 1803 (our company won't let us have it yet). I suspect some DLL unloading order was changed in the update I applied. So, I plan to still call XTPShutdown() from our shutdown code to prevent
CoUninitialize from being called from CJ's DllMain since that fixes the
issue too. That way any OS or other change that might affect the DLL unloading order won't cause this to show back up.
|
Posted By: Marschos
Date Posted: 25 February 2020 at 10:06am
|
It seems there was a regression from ToolkitPro 19.0 to 19.1 . We had this problem 2018 in November and we fixed it with the manual call to XTPShutdown() in the destructor of our app. Since updating to 19.1 the problem is back and the app crashes on exit. The devices we have the problem on run Windows 10 Enterprise 2016 LTSB(based on 1607) and there is no easy Windows update out of it. The stacktrace looks the same to me:
Is there any way I can help you help me with this?
|
Posted By: rdhd
Date Posted: 25 February 2020 at 5:20pm
|
I don't have 19.1. Try this. Set a breakpoint where you call XTPShutdown. When you get there, set a breakpoint after the call. Also, set a breakpoing inthe CXTPMarkupObject::~ dtor function. Setting that breakpoint eariler won't work for at least with our app, that dtor is called constantly and a lot. A whole lot. When I step across XTPShutdown, the markup dtor is called a number of times. I hit go go go ... and then my breakpoint I set after the shutdown call trips (one line after it for me). Then I go again. No more calls to that dtor are made. If you get another call, then something is wrong such as having some static markup object declared in a DLL or some object that is static in a DLL that contains a markup. Let me know so I'll be on the lookout when I pull 19.1.
|
Posted By: Marschos
Date Posted: 26 February 2020 at 3:42am
|
Thank you for the quick response! We investigated like you suggested and found the problem. In ToolkitPro_v19.1.0\Source\Markup\XTPMarkupBuilder.cpp there is new globals defined via a macro XTP_DECLARE_MARKUP_STRING_CONSTANT(they did not exist in 19.0). Those globals are destructed after the XTPShutdown() call in our App destructor causing the problem. Just for your information, we link the Toolkit as dll. We are going to try to build the toolkit without those globals(if that works) and check if it solves the problem. If there is anything else we can try I am happy for suggestions. Edit: Removing those globals and their use in the file solves the issue with the app crashing on exit. But our application requires them in another place, so this is no solution. We are going to downgrade to v19.0 for now to fix the issue.
|
Posted By: astoyan
Date Posted: 15 June 2021 at 6:18pm
|
The problem with calling uninitializing COM from markup builder static object after XTPShutdown call has been fixed for the final release of v20, however we were not able to reproduce the crashes still. Once v20 is release please retest those use cases and share your results here. Thanks, Alexander
|