Toolkit Pro - FIXED: Assert on Shutdown with 20.3

FIXED: Assert on Shutdown with 20.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=24293
Printed Date: 22 December 2024 at 8:26am
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com

Topic: FIXED: Assert on Shutdown with 20.3

Posted By: MarkusA
Subject: FIXED: Assert on Shutdown with 20.3
Date Posted: 01 June 2022 at 5:19am

Hello,

After updating Visual Studio 2022 from Version 17.1.6 to 17.2.2 we get many Debug Asserts on Application Shutdown with Codejock 20.3.0 when your global Markup-Strings are destructed.

Callstack:

>	mfc140ud.dll!CCmdTarget::ExternalDisconnect() Line 455	C++ 	mfc140ud.dll!COleDispatchImpl::Disconnect() Line 441	C++
 	mfc140ud.dll!CCmdTarget::~CCmdTarget() Line 39	C++
 	ToolkitPro2030vc170UD.dll!CXTPCmdTarget::~CXTPCmdTarget()	C++
 	ToolkitPro2030vc170UD.dll!CXTPMarkupObject::~CXTPMarkupObject() Line 731	C++
 	ToolkitPro2030vc170UD.dll!CXTPMarkupString::~CXTPMarkupString() Line 198	C++
 	ToolkitPro2030vc170UD.dll!`dynamic atexit destructor for 'g_xtpMarkStringWrapWithOverflow''()	C++
 	ucrtbased.dll!_execute_onexit_table::__l2::<lambda>() Line 206	C++
 	ucrtbased.dll!__crt_seh_guarded_call<int>::operator()<void <lambda>(void),int <lambda>(void) &,void <lambda>(void)>(__acrt_lock_and_call::__l2::void <lambda>(void) && setup, _execute_onexit_table::__l2::int <lambda>(void) & action, __acrt_lock_and_call::__l2::void <lambda>(void) && cleanup) Line 204	C++
 	ucrtbased.dll!__acrt_lock_and_call<int <lambda>(void)>(const __acrt_lock_id lock_id, _execute_onexit_table::__l2::int <lambda>(void) && action) Line 978	C++
 	ucrtbased.dll!_execute_onexit_table(_onexit_table_t * table) Line 160	C++
 	ToolkitPro2030vc170UD.dll!__scrt_dllmain_uninitialize_c() Line 398	C++
 	ToolkitPro2030vc170UD.dll!dllmain_crt_process_detach(const bool is_terminating) Line 182	C++
 	ToolkitPro2030vc170UD.dll!dllmain_crt_dispatch(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Line 220	C++
 	ToolkitPro2030vc170UD.dll!dllmain_dispatch(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Line 293	C++
 	ToolkitPro2030vc170UD.dll!_DllMainCRTStartup(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Line 334	C++
 	ntdll.dll!_LdrxCallInitRoutine@16()	Unknown
 	ntdll.dll!LdrpCallInitRoutine()	Unknown
 	ntdll.dll!LdrShutdownProcess()	Unknown
 	ntdll.dll!RtlExitUserProcess()	Unknown
 	kernel32.dll!_ExitProcessImplementation@4()	Unknown
 	ucrtbased.dll!exit_or_terminate_process(const unsigned int return_code) Line 144	C++
 	ucrtbased.dll!common_exit(const int return_code, const _crt_exit_cleanup_mode cleanup_mode, const _crt_exit_return_mode return_mode) Line 280	C++
 	ucrtbased.dll!exit(int return_code) Line 293	C++
 	ShortcutBar.exe!__scrt_common_main_seh() Line 297	C++
 	ShortcutBar.exe!__scrt_common_main() Line 331	C++
 	ShortcutBar.exe!wWinMainCRTStartup(void * __formal) Line 17	C++
 	kernel32.dll!@BaseThreadInitThunk@12()	Unknown
 	ntdll.dll!__RtlUserThreadStart()	Unknown
 	ntdll.dll!__RtlUserThreadStart@8()	Unknown

The call to AFXASSUME was added by Microsoft to their CCmdTarget-Implementation with the new MFC Version 14.32.31326 delivered with 17.2.2 (I assume it comes with 17.2.0, but can't verify this). The Version delivered with Visual Studio 17.1.6 (MFC 14.31.31103) does not have this line of code.

This happens because the Markup-Strings were destroyed after COM was unitialized by MFC -> Can be reproduced with your Shortcutbar-Example: Just start a debug of it in Visual Studio 2022 17.2.2 and immediately close the Application via the Close-Button.

Btw. if SkinFramework is used the Application crashes with an Access Violation instead of showing the Debug Assertion because the Skinmanager tries to hook the Debug Assertion Dialog - which might be impossible because most parts of the application should not exist anymore at this time -> Just try to debug your SkinControls Sample and close the Application. This happens at least with the legacy API hook as we can't use the new Detours hook.

Greetings

Markus

Replies:

Posted By: mgampi
Date Posted: 02 June 2022 at 5:40am

+1
We see the same after migration from 19.1 to 20.3

-------------
Martin

Product: Xtreme Toolkit v 22.1.0, new Projects v 24.0.0
Platform: Windows 10 v 22H2 (64bit)
Language: VC++ 2022

Posted By: docontrol
Date Posted: 03 June 2022 at 7:04am

I am seeing the same issue here after an upgrade of VS 2022 17.1.6 to 17.2.3.

Posted By: docontrol
Date Posted: 03 June 2022 at 2:15pm

I received this workaround from Alexander at CodeJock and it solved the problem in my case:

Hello Ronnie,

That was a known issue and it has already been fixed and the fix will be available in the next version.
So you don't wait for the next version you can integrate a simple patch. All you need is to replace the body of CXTPMarkupObject::CXTPMarkupObject(int nFlags) constructor in \Source\Markup\XTPMarkupObject.cpp with the following below code:

{
if (0 == (nFlags & flagNoCom))
{
  EnableAutomation();
#ifdef _XTP_ACTIVEX
  EnableTypeLib();
#endif
}
}

After adding this change don't forget to re-build the configurations you use.
Please confirm if the fix works for you.

Thank you.
Regards,
Alexander

Posted By: bricaro
Date Posted: 07 June 2022 at 10:04am

I can confirm this problem with both 20.3 and 19.3. Implemented the fix, suggested by docontrol, in 20.3 and it solved the problem for me.

Posted By: MarkusA
Date Posted: 07 June 2022 at 11:40am

Thank you for sharing this workaround. Problem solved.

Posted By: MrPhil
Date Posted: 26 October 2022 at 12:13pm

This problem was fixed using the code fix, but has returned. I have not rebuilt ToolkitPro since we fixed the issue.

I was told to expect the update in October. Is that still the case?

Posted By: MrPhil
Date Posted: 07 November 2022 at 3:32pm

After updating to 22.0.0, I still have this issue.

Posted By: astoyan
Date Posted: 06 February 2023 at 10:32am

Thanks everyone who reported this and related issues here and in support. We've added a number of related fixes and all those use cases that were managed to reproduce have been fixed. The fixes will be included into the upcoming v22.1 update that hopefully will be released in February. After you get the update please re-test all use cases when those crashes occurred in your project and provided as much as possible details about the remaining crashes so we can check and fix them quickly.

Thank you.

Regards,

Alexander