BUG: You receive a "BASE: GlobalFree called with a locked object" error message when you try to free a global memory that is attached to a CSharedFile object

Under the Checked build of Windows NT or a diagnostic utility you receive an error similar to this one: The Checked build of Windows NT causes a Hard-Coded breakpoint to occur, which generates a message similar to this one:

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.

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:

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.