I was writing recently about an MFC bug in CDatabase class in Visual Studio 2012. In the meanwhile I have stumbled upon an even greater bug (check this report on Connect for the details): when the OpenEx function fails (wrong credentials, service not reachable, machine is shot down etc.) it corrupts memory. What happen next is chance. I don’t know when a fix will be available, but until that happens there is a workaround for this. Just like for the previous bug, you have to derive CDatabase and override OpenEx method, copying the original implementation from the MFC sources and adding one more line to null the pointer to already released memory. So, I’ll extend my previous CDatabaseEx class to the following implementation:

, , , , , Hits for this post: 10885 .
Trackback

3 comments untill now

  1. Gravatar

    You need to modify the code as follows as well at line 47/48:

    if(!Connect(dwOptions)) {
    m_blobConnect.pbData = NULL;
    return FALSE;
    }

    Otherwise, a failure to connect for reasons other than an exception being caught will also null out the data.

  2. Gravatar

    Thanks for pointing that out.

  3. Gravatar

    If you call OpenEx() with lpszConnectString pointing to an empty string,
    the MFC will open a dialog to let the user choose a new connection.

    If that dialog is closed with “Abort” then there will still be a memory
    corruption!

    I got around this bug with this check:

    if( m_strConnect.GetLength() > 0 ) // yet another workaround…
    {
    DATA_BLOB connectBlob;
    connectBlob.pbData = (BYTE *)(LPCTSTR)m_strConnect;
    connectBlob.cbData = (DWORD)(AtlStrLen(m_strConnect) + 1) * sizeof(TCHAR);
    if (CryptProtectData(&connectBlob, NULL, NULL, NULL, NULL, 0, &m_blobConnect))
    {
    SecureZeroMemory((BYTE *)(LPCTSTR)m_strConnect, m_strConnect.GetLength() * sizeof(TCHAR));
    m_strConnect.Empty();
    }
    }

    regards
    Dirk

Add your comment now