BUG: CSharedFile::Detach() Does Not Call GlobalUnlock()

• The Microsoft Foundation Classes (MFC) included with: - Microsoft Visual C++, 32-bit Edition, versions 2.0, 2.1, 2.2, 4.0,

       4.1, 4.2, 5.0
  

SYMPTOMS

Under the Checked build of Windows NT or a diagnostic utility you receive an error similar to this one:

   BASE: GlobalFree called with a locked object.

   User Breakpoint called from code at: 0x77f2706f

CAUSE

The CSharedFile class maintains a global memory block. As soon as an HGLOBAL is allocated by a CSharedFile object (or specified in a call to SetHandle), it calls GlobalLock to lock this memory block.

If the CSharedFile object is destroyed, then a call to GlobalUnlock() and GlobalFree() will correctly unlock and free the global memory block. However, if a call to Detach() is made to retrieve the HGLOBAL, then the handle returned is still locked. There is no call to GlobalUnlock() made to match the call to GlobalLock().

The memory block referenced by the HGLOBAL cannot be moved because it has a positive reference count. Also, if an attempt is made to free the HGLOBAL by way of a call to GlobalFree(), the symptoms given in this article will occur.

RESOLUTION

After calling CSharedFile::Detach(), you can unlock the global memory block by making a call yourself to GlobalUnlock(). Because this workaround is dependent on the implementation of CSharedFile(), you should be sure to use conditional compilation for this block of code as demonstrated here:

   CSharedFile file;

   // Do stuff to fill in the CSharedFile

   HGLOBAL hGlob = file.Detach();
   #if _MFC_VER <= 0x0421
     ::GlobalUnlock(hGlob);
   #endif

STATUS

Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available.