Stack unwinding...
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=13394
Printed Date: 23 December 2024 at 3:32pm
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com
Topic: Stack unwinding...
Posted By: Alex
Subject: Stack unwinding...
Date Posted: 11 February 2009 at 4:09pm
|
Hello,
I have problems to find the root of certain exceptions in my prog.
I can reproduce that (mis)behavior easily with one of your samples, lets say the RibbonSample.
When I add this piece of code :
void CMainFrame::ShowCustomizeDialog(int nSelectedPage)
{ CXTPCustomizeSheet cs(GetCommandBars()); UINT *test = NULL;
UINT bla; bla = *test;
TRACE( "%d", bla); Visual Studio 2008 catches the exception, but presents me this call stack :
mailto:ntdll.dll!_RtlDeactivateActivationContext@8 - ntdll.dll!_RtlDeactivateActivationContext@8 () + 0x1d463 bytes
mailto:kernel32.dll!_DeactivateActCtx@8 - kernel32.dll!_DeactivateActCtx@8 () + 0x28 bytes mfc90d.dll!AfxDeactivateActCtx(unsigned long dwFlags=0, unsigned long ulCookie=312224264) Line 260 + 0x17 bytes C++ mfc90d.dll!AFX_MAINTAIN_STATE2::~AFX_MAINTAIN_STATE2() Line 63 + 0xe bytes C++ mfc90d.dll!AfxWndProcBase(HWND__ * hWnd=0x001516e4, unsigned int nMsg=514, unsigned int wParam=0, long lParam=9830510) Line 441 + 0x27 bytes C++ mailto:user32.dll!_InternalCallWinProc@20 - user32.dll!_InternalCallWinProc@20 () + 0x23 bytes mailto:user32.dll!_UserCallWinProcCheckWow@32 - user32.dll!_UserCallWinProcCheckWow@32 () + 0xb7 bytes mailto:user32.dll!_CallWindowProcAorW@24 - user32.dll!_CallWindowProcAorW@24 () + 0x5e bytes mailto:user32.dll!_CallWindowProcA@20 - user32.dll!_CallWindowProcA@20 () + 0x1b bytes aimemb.dll!028399b2() [Frames below may be incorrect and/or missing, no symbols loaded for aimemb.dll] aimemb.dll!0286e13f() mailto:user32.dll!_InternalCallWinProc@20 - user32.dll!_InternalCallWinProc@20 () + 0x23 bytes mailto:user32.dll!_UserCallWinProcCheckWow@32 - user32.dll!_UserCallWinProcCheckWow@32 () + 0xb7 bytes mailto:user32.dll!_CallWindowProcAorW@24 - user32.dll!_CallWindowProcAorW@24 () + 0x5e bytes mailto:user32.dll!_CallWindowProcA@20 - user32.dll!_CallWindowProcA@20 () + 0x1b bytes > ToolkitPro1300vc90D.dll!CXTPHookManager::HookWndProc(HWND__ * hWnd=0x001516e4, unsigned int message=514, unsigned int wParam=0, long lParam=9830510) Line 267 + 0x1c bytes C++ mailto:user32.dll!_InternalCallWinProc@20 - user32.dll!_InternalCallWinProc@20 () + 0x23 bytes mailto:user32.dll!_UserCallWinProcCheckWow@32 - user32.dll!_UserCallWinProcCheckWow@32 () + 0xb7 bytes mailto:user32.dll!_DispatchMessageWorker@8 - user32.dll!_DispatchMessageWorker@8 () + 0xee bytes mailto:user32.dll!_DispatchMessageA@4 - user32.dll!_DispatchMessageA@4 () + 0xf bytes mfc90d.dll!AfxInternalPumpMessage() Line 183 C++ mfc90d.dll!CWinThread::PumpMessage() Line 900 C++ mfc90d.dll!CWinThread::Run() Line 629 + 0xd bytes C++ mfc90d.dll!CWinApp::Run() Line 865 C++ mfc90d.dll!AfxWinMain(HINSTANCE__ * hInstance=0x00180000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x00b1604c, int nCmdShow=1) Line 47 + 0xd bytes C++ RibbonSampleD.exe!WinMain(HINSTANCE__ * hInstance=0x00180000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x00b1604c, int nCmdShow=1) Line 34 C++ RibbonSampleD.exe!__tmainCRTStartup() Line 578 + 0x35 bytes C RibbonSampleD.exe!WinMainCRTStartup() Line 403 C mailto:kernel32.dll!@BaseThreadInitThunk@12 - kernel32.dll!@BaseThreadInitThunk@12 () + 0xe bytes mailto:ntdll.dll!___RtlUserThreadStart@8 - ntdll.dll!___RtlUserThreadStart@8 () + 0x23 bytes mailto:ntdll.dll!__RtlUserThreadStart@8 - ntdll.dll!__RtlUserThreadStart@8 () + 0x1b bytes Pretty useless, isn't it ?
Any ideas ?
I am running Vista 64Bit with 12GB Ram powered by an I7 965.
Alex
|
Replies:
Posted By: mgampi
Date Posted: 11 February 2009 at 5:18pm
|
Hi; So first question: Is it a release build or debug? Try to create the CXTPPropertySheetDlg on heap and not on stack. I remember a similar problem I had a few years ago while creating file open dialogs on the stack! Due to low stack size conditions the stack frame was destroyed and the call stack was totally wrong! ------------- 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: Alex
Date Posted: 12 February 2009 at 2:55am
|
In this case it was a Debug build.
And it is the RibbonSample from CodeJock.
|
Posted By: znakeeye
Date Posted: 12 February 2009 at 3:03am
|
Clearly, the following line will cause a crash:
bla = *test; // no comment
To improve debugging, go to "Debug -> Exceptions..." and check the types of exceptions you want to debug. ------------- PokerMemento - http://www.pokermemento.com/ |
Posted By: Alex
Date Posted: 12 February 2009 at 5:36am
|
While unwinding the stack during exception handling, another exception is raised.
See mailto:ntdll.dll!_RtlDeactivateActivationContext@8 - ntdll.dll!_RtlDeactivateActivationContext@8 () + 0x1d463 bytes
It seems that the previous activation context state wasn't restored
properly by one of the exception handlers in the path from the
violation down to the second exception raised in AfxWndProcBase.
Maybe the AFX_MAINTAIN_STATE2 wasn't used...
Alex
|
Posted By: Oleg
Date Posted: 12 February 2009 at 6:19am
|
Alex, so you complain our sources because you referenced to NULL pointer ?
MFC has a lot of bugs too - add "i = 4 / 0" and you will see exceptions. ------------- Oleg, Support Team CODEJOCK SOFTWARE SOLUTIONS |
Posted By: Alex
Date Posted: 12 February 2009 at 7:09am
|
No, of course not.
But how could I find the root of the problem in a release build ?
Keyword : post mortem debugging.
|
Posted By: Alex
Date Posted: 12 February 2009 at 8:27am
|
Here's what I mean :
The first project is a standard RibbonSample purely MFC. The app crashes and the debugger is able to
point me the right place plus the stack looks perfect.
 Here's the same with the RibbonSample :
 Maybe that I am doing something wrong, but where's the magic switch then ??
Best regards,
Alex
|
Posted By: Oleg
Date Posted: 13 February 2009 at 2:47am
|
Hi,
Sorry, I see your point now. but have no idea why Visual Studio behave different :( ------------- Oleg, Support Team CODEJOCK SOFTWARE SOLUTIONS |
Posted By: znakeeye
Date Posted: 13 February 2009 at 2:57am
|
Try removing *.suo and *.user. Also, see my previous post. ------------- PokerMemento - http://www.pokermemento.com/ |
Posted By: Alex
Date Posted: 13 February 2009 at 4:20am
|
>> Try removing *.suo and *.user. Also, see my previous post.
That doesn't help, thanks.
Could it be that something in the hooking mechanism is the cause ?
The problem occurs when I execute the deadly code via the menu or the ribbon bar
command handlers.
I get a clean call stack when I exec the deadly code right after ShowWindow in InitInstance.
Can you reproduce it with your RibbonSample ? ------------- www.ANKHOR.com Product: Xtreme ToolkitPro version 15.2.1 Platform: Windows 7 Ultimate (64bit) Language: Visual C++ 2005 / 2008 / 2010 |
Posted By: znakeeye
Date Posted: 13 February 2009 at 5:14am
|
Hmm... this can't be good. I'm wondering if it could have something in common what I discovered in my popup menu:
http://forum.codejock.com/forum_posts.asp?TID=13381 -
http://forum.codejock.com/forum_posts.asp?TID=13355 - http://forum.codejock.com/forum_posts.asp?TID=13355
That thread won't say much to you, but to summarize; after I upgraded to 13.0 I got a strange stack corruption when showing a context menu - only in Vista.
Do you get this problem in Windows XP too? ------------- PokerMemento - http://www.pokermemento.com/ |
Posted By: Alex
Date Posted: 13 February 2009 at 6:32am
|
I can test it only in a virtual machine, but it works there !!
So there seems to be a problem only under Windows Vista.
Happy debugging ! ------------- www.ANKHOR.com Product: Xtreme ToolkitPro version 15.2.1 Platform: Windows 7 Ultimate (64bit) Language: Visual C++ 2005 / 2008 / 2010 |
Posted By: znakeeye
Date Posted: 13 February 2009 at 6:40am
|
In that case it's probably the same issue I encountered. I had to analyze my code manually, since the stack was all gone...
Let's google "vista" + "null pointer exception" :) ------------- PokerMemento - http://www.pokermemento.com/ |
Posted By: znakeeye
Date Posted: 13 February 2009 at 6:45am
|
Try disabling DEP, and see if it works:
Control Panel / System / Advanced system settings / Advanced tab / Performance Settings / Data Execution Prevention
Also, try fiddling with the security settings in RibbonSample. C++ -> Smaller Type checks, Basic Runtime Checks, Buffer Security Check ------------- PokerMemento - http://www.pokermemento.com/ |
Posted By: znakeeye
Date Posted: 13 February 2009 at 6:51am
|
Another tip! Try including MS symbols:
Tools -> Options -> Debugging -> Symbols: http://msdl.microsoft.com/downloads/symbols - http://msdl.microsoft.com/downloads/symbols ------------- PokerMemento - http://www.pokermemento.com/ |
Posted By: Alex
Date Posted: 13 February 2009 at 7:14am
|
I would be interesting if I am the only guy who has this problem ...
Any developers with Vista out there ???
------------- www.ANKHOR.com Product: Xtreme ToolkitPro version 15.2.1 Platform: Windows 7 Ultimate (64bit) Language: Visual C++ 2005 / 2008 / 2010 |
Posted By: znakeeye
Date Posted: 13 February 2009 at 7:40am
|
I'm running Vista Ultimate at home. Will test this tonight! ------------- PokerMemento - http://www.pokermemento.com/ |
Posted By: znakeeye
Date Posted: 13 February 2009 at 7:56am
|
Hmm, I got an idea! Vista 64 runs DEP (Data Execution Prevention) by default. This is not true in 32-bit systems. But you can enable it: Win+Break, Advanced -> Performance Settings -> Data Execution Prevention -> Turn on DEP for all programs
Restart system and try running your code! (I'm just about to restart here...)
Update: It's still working. Vista issue? ------------- PokerMemento - http://www.pokermemento.com/ |
Posted By: adrien
Date Posted: 15 February 2009 at 11:15pm
|
is the first line a problem?
CXTPCustomizeSheet cs(GetCommandBars()); I find often you can't create a stack-based XTPro object, you have to new it on the heap, else when it calls into the CCommandTarget final release and calls delete this, kaboom. ------------- http://www.wingate.com - http://www.wingate.com |
Posted By: Alex
Date Posted: 16 February 2009 at 4:48am
|
No, I can comment everything out in this method -> same effect.
It would be nice if anybody from codejock could check this problem
and confirm that is it a general problem or a local problem on
my system(s) here
 .------------- www.ANKHOR.com Product: Xtreme ToolkitPro version 15.2.1 Platform: Windows 7 Ultimate (64bit) Language: Visual C++ 2005 / 2008 / 2010 |
Posted By: znakeeye
Date Posted: 16 February 2009 at 9:11am
|
My guess is that it has something to do with Vista x64. Try Vista x86 and see if the problem persists! ------------- PokerMemento - http://www.pokermemento.com/ |
Posted By: Smucker
Date Posted: 16 February 2009 at 11:55am
|
I can reproduce with the ribbon sample on at least one Vista 64 system. I saw this problem in my own project several months ago, but I'm now using static linking of MFC and the toolkit now and haven't seen it since. I try to avoid as much of DLL hell as is reasonably possible. DLLs that have a manifest and are compiled with ISOLATION_AWARE_ENABLED can create multiple activation contexts, so it could be an issue with any DLL that your application uses, or even a DLL that is injected by another application. Or perhaps the toolkit needs itself to be compiled with ISOLATION_AWARE_ENABLED since it hooks LoadLibrary? I set breakpoints at _CreatActCtxW@4 and startup of the ribbon sample created 12 of them (3 for injected DLLs from Fraps and Logitech; everything else was Microsoft). Unfortunately, context activation/deactivation uses cookies instead of the context handles i was tracking, so when I finally crashed, I didn't have enough info to tell which were involved. The discussions I've found have not been very helpful, and MSDN doesn't provide a decent overview of activation contexts. I don't have enough knowledge to go any further. DLL Hell continued, or perhaps it should be renamed to "SXS Hell." ------------- Product: Xtreme Toolkit Pro version 13.2 (Unicode, static build) Platform: Windows 200x/XP/Vista/Win7 (32/64 bit) Language: Visual C++ 9.0 (Studio 2008) |
Posted By: Alex
Date Posted: 26 February 2009 at 6:02am
|
Hello,
It's not the fault of Xtreme Toolkit !!
While disabling concurrent processes after each new debug attempt, I could isolate
Logitech's Setpoint application as the BAD guy.
I will inform them that there's a problem.
Thanks to all for your valuable input and suggestions,
Alex ------------- www.ANKHOR.com Product: Xtreme ToolkitPro version 15.2.1 Platform: Windows 7 Ultimate (64bit) Language: Visual C++ 2005 / 2008 / 2010 |
Posted By: znakeeye
Date Posted: 26 February 2009 at 9:28am
|
Hah! SetPoint is a virus. Just like Norton Antivirus. There are only problems with those two :) ------------- PokerMemento - http://www.pokermemento.com/ |