Another crash log from a customer led me to find another one of these non-pointer tests. This one is in CXTPDockingPaneTabbedContainer::OnToolHitTest(CPoint point, TOOLINFO* pTI)

            CString strTip = GetSelected()->GetTitleToolTip();

Though in this case, I'm pretty sure it is the same issue I am now trying to fix - the selected pane has been deleted but the m_pSelectedPane pointer still points to the pane. TRACE statements and debugging has shown me the selected pane can get closed and the member still points to it when some paint or mouse message is dispatched to the container.

We have a number of crashes in the customer base for a few years now. Almost always have the same call CJ stack or one closely related to it related to drawing a pane or getting a tooltip from a pane. Here is the most common one:

     ToolkitPro1930vc160x64U.dll!CXTPDockingPane::GetOptions() Line 502    C++
     ToolkitPro1930vc160x64U.dll!CXTPDockingPaneTabbedContainer::IsTitleVisible() Line 577    C++
     ToolkitPro1930vc160x64U.dll!CXTPDockingPanePaintManager::AdjustCaptionRect(const CXTPDockingPaneTabbedContainer *, CRect &) Line 772    C++
     ToolkitPro1930vc160x64U.dll!CXTPDockingPaneOffice2013Theme::DrawPane(CDC *, CXTPDockingPaneTabbedContainer *, CRect) Line 230    C++
     ToolkitPro1930vc160x64U.dll!CXTPDockingPaneTabbedContainer::OnPaint() Line 561    C++

Today I got lucky and attached a debugger while I had release PDB files available and the call stack is the one above. Here is what I found. Notice CJ handles a nullptr m_pLayout:

CXTPDockingPaneManager* CXTPDockingPaneBase::GetDockingPaneManager() const
{
    ASSERT(m_pLayout);
    if (!m_pLayout)
        return NULL;

    ASSERT(m_pLayout->m_pManager);
    return m_pLayout->m_pManager;
}

However, check out the code that crashed us:

DWORD CXTPDockingPane::GetOptions() const
{
    return GetDockingPaneManager()->m_dwDefaultPaneOptions | m_dwOptions;
}

XTPDockingPane.cpp has a lot of calls to GetDockingPaneManager()->SomeMethod(...). So, if the layout is nullptr, CJ handles that and returns nullptr but the code doesn't check the pointer.

Time to edit CJ code again and I hope CJ will address this sort of calls where code calls to get a pointer and does the "GetPointer()->" code pattern when other CJ code apparently knows the pointer being obtained can be null.