Invalid m_pSelectedPane causes abort

It appears to me that the CXTPDockingPaneTabbedContainer can still have a deleted pane stored in its m_pSelectedPane member data. This leads to a crash when an OnPaint message comes through the tabbed container. Our customers reported this when they take remote control of our application via GoToMeeting.com (or the Siemens AppShare application).

Using trace points I have determined that a CXTPDockingPane is getting deleted while it is still in a tabbed container as the m_pSelectedPane. The tabbed container doesn't get deleted but retains the deleted pointer. This appears to occur when loading layouts and is easiest to duplicate by running GoToMeeting.com and then having a remote user take control of the application and exercising the application remotely in such a way that layouts are saved and loaded.

I can also duplicate this directly by placing breakpoints in various code locations such as the pane and tabbed container ctors, dtors and SelectPane methods.

And lucky for me, I found the CodeJock\Samples\DockingPane\PaneSample and I can duplicate it there. I saved two layouts using the sample to layout1.xml and layout2.xml. Then I took remote control of the sample from my other machine using GoToMeeting.com and started selecting the layout load commands. After a couple of selections, I crashed. The call stack looks like the stacks I have been debugging in our app.

Here is the sample's call stack where I have crashed because the IsTitleVisible method has a non-zero m_pSelectedPane, which is no longer valid (the crash is an AV in GetDockingPaneManager in this case though the exact crash depends on the values in memory):

     ToolkitPro1631vc110x64UD.dll!CXTPDockingPaneBase::GetDockingPaneManager() Line 210    C++
     ToolkitPro1631vc110x64UD.dll!CXTPDockingPane::GetOptions() Line 451    C++
>    ToolkitPro1631vc110x64UD.dll!CXTPDockingPaneTabbedContainer::IsTitleVisible() Line 571    C++
     ToolkitPro1631vc110x64UD.dll!CXTPDockingPaneVisualStudio2012Theme::DrawPane(CDC * pDC, CXTPDockingPaneTabbedContainer * pPane, CRect rc) Line 311    C++
     ToolkitPro1631vc110x64UD.dll!CXTPDockingPaneTabbedContainer::OnPaint() Line 552    C++
     mfc110ud.dll!CWnd::OnWndMsg(unsigned int message, unsigned __int64 wParam, __int64 lParam, __int64 * pResult) Line 2460    C++
     ToolkitPro1631vc110x64UD.dll!CXTPDockingPaneTabbedContainer::OnWndMsg(unsigned int message, unsigned __int64 wParam, __int64 lParam, __int64 * pResult) Line 1485    C++
     mfc110ud.dll!CWnd::WindowProc(unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 2137    C++
     mfc110ud.dll!AfxCallWndProc(CWnd * pWnd, HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 290    C++
     mfc110ud.dll!AfxWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 453    C++
     mfc110ud.dll!AfxWndProcBase(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 304    C++
     user32.dll!UserCallWinProcCheckWow()    Unknown
     user32.dll!DispatchClientMessage()    Unknown
     user32.dll!__fnDWORD()    Unknown
     ntdll.dll!KiUserCallbackDispatcherContinue()    Unknown
     user32.dll!NtUserCallHwndLock()    Unknown
     mfc110ud.dll!CWnd::UpdateWindow() Line 138    C++
     mfc110ud.dll!CFrameWnd::OnIdleUpdateCmdUI() Line 2154    C++
     mfc110ud.dll!CMDIFrameWnd::OnIdleUpdateCmdUI() Line 248    C++
     mfc110ud.dll!CWnd::OnWndMsg(unsigned int message, unsigned __int64 wParam, __int64 lParam, __int64 * pResult) Line 2460    C++
     ToolkitPro1631vc110x64UD.dll!CXTPCommandBarsSiteBase<CMDIFrameWnd>::OnWndMsg(unsigned int message, unsigned __int64 wParam, __int64 lParam, __int64 * pResult) Line 200    C++
     mfc110ud.dll!CWnd::WindowProc(unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 2137    C++
     mfc110ud.dll!AfxCallWndProc(CWnd * pWnd, HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 290    C++
     mfc110ud.dll!AfxWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 453    C++
     mfc110ud.dll!AfxWndProcBase(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 304    C++
     user32.dll!UserCallWinProcCheckWow()    Unknown
     user32.dll!CallWindowProcW()    Unknown
     ToolkitPro1631vc110x64UD.dll!CXTPHookManager::HookWndProc(HWND__ * hWnd, unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 267    C++
     user32.dll!UserCallWinProcCheckWow()    Unknown
     user32.dll!DispatchMessageWorker()    Unknown
     mfc110ud.dll!AfxInternalPumpMessage() Line 183    C++
     mfc110ud.dll!CWinThread::PumpMessage() Line 900    C++
     mfc110ud.dll!CWinThread::Run() Line 629    C++
     mfc110ud.dll!CWinApp::Run() Line 780    C++
     mfc110ud.dll!AfxWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpCmdLine, int nCmdShow) Line 47    C++
     Pane.exe!wWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpCmdLine, int nCmdShow) Line 26    C++


We are using 16.3.1 and I have searched the release notes for later releases and see no mention of this issue being resolved.

What I have not figured out is how a call to a pane's destructor is made without the parent container getting another pane selected in its place or the parent container being destroyed too. When I crash, the tabbed container is still valid and it has a valid hWnd (hence the response to WM_PAINT).

Perhaps int the layout code there is a missing reference counting problem on the pane or tabbed container.

Can someone at CodeJock verify this problem and let me know if there is a fix in hand, and if so, what it is so we can determine what we should do? We are about to release so I can't move to a newer toolkit now but I will readily modify the code until we can get a new release.

I don't recall why but when I first was told of this by a customer I suspected the Windows 8.1 uiautomation.dll and/or combase.dll - probably because on my Win 7 box I don't see combase.dll in the process. Now I am debugging CCmdTarget::ExternalAddRef/Release and I see calls made to the tabbed container. Some calls are for the fact that it is a drop target but those references balance out (observed when the tabbed container calls Register). But then I set a conditional breakpoint for when the ref cnt exceeded 4. I see calls being made for the IAccessible interface. It sure looks like some of those ref counts are not released on Win 8.1. The elevated count causes the tabbed container to not get deleted when the layout calls DeletePane.

I have not determined for sure if it is the MS dll leaking since I can't shut down due to the crash. It seems prudent for CJ to ensure the deleted docking pane is properly disconnected from the tabbed container since the tabbed container doesn't add ref the selected pane it is storing.

I had sent a query to Microsoft regarding those two Dlls an dof course Microsoft denied any knowledge of the DLLs causing issues on Win 8. My combase.dll version is 6.3.9600.17415 and uiautomation version is 7.2.9600.17415.

Debugging the pane sample on my Win 7 box, I don't detect any calls from combase to CCmdTarget::ExternalQueryInterface.

I see that the m_bEnableActiveAccess member is false when the tabbed container's OnGetObject is called.I think I'll remove that handler from the message map and see what happens.

Unfortunately people rely on uiautomation to drive our app (from .NET for automatic testing procedures). So even though I tested the theory that not giving out the IAccessible interface "fixed" the problem, it isn't the solution.

According to the CJ ref guide, DeletePane is called to destroy the pane. Even though DeletePane is a virtual method defined by the pane base class, CXTPDockingPaneTabbedContainer overrides it but doesn't make it virtual.

So I either have to modify that class and make it virtual, or I go into the layout object's Free class and call DestroyWindow. I did that and it avoids the crash.

I also noted in the sample that the "DockingPane" menu is a command bar and it too gives out an IAccessible interface. So I went into the MFC oleunk.cpp file and set a conditional breakpoint in ExternalAddRef to watch the ref count there. Each time I click the menu, a keyboard hook implemented by uiautomation starts querying and add ref'ing the interface. Disable the break point and then click and dismiss the menu for a while then enable the breakpoint and look at the ref count. The count just keeps increasing and increasing reaching the hundreds quite quickly. Hence I believe my suspicion that on Windows 8.1, Windows is leaking reference counts is correct.

The change to call DestroyWindow keeps the app from crashing and I don't really have another ideal on what else can be done. So either edit the tabbed container's include file to make DeletePane virtual and override the class and implement DeletePane to call DestroyWindow and then the base class DeletePane, or modify the Free method and call DestroyWindow before calling DeletePane (order is important since DeletePane can cause a pane to be deleted if the ref count is not going crazy). Note the "accessible" object isn't really the tabbed container but the container still gets a lot of references on it too.