BUG: DCOM95 MTA Clients May Block Broadcast DDE Messages

 Last reviewed: March 2, 1998
Article ID: Q181949
The information in this article applies to:
  • Microsoft OLE Libraries 4.0 included with: 

        - Microsoft Windows 95

SYMPTOMS

Due to a bug in the RPC runtime DLLs that ship with DCOM951.1, MTA clients that do not service the message queue may block the global broadcast of DDE messages. When a user double-clicks on a desktop icon, the program associated with the icon may be blocked from launching and Windows Explorer may hang.

CAUSE

A top-level window is created by the RPC runtime on the MTA client thread that called CoCreateInstance(Ex), but the window is not destroyed when the API returns. The client thread has no obligation to service the message queue under the MTA programming model. If it does not, this top-level window causes global DDE broadcast messages to block.

RESOLUTION

To work around this bug, you need to make the client's MTA thread behave like an STA thread (that is, it must service the message queue). If it is blocking on a win32 handle, it must call the MsgWaitForMultipleObjects() API to simultaneously dispatch windows messages. See the REFERENCES section for an article that explains how to do this.

STATUS

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

MORE INFORMATION

A thread initializes COM libraries for the Single Threaded Apartment(STA) by calling CoInitializeEx(0, COINIT_APARTMENTTHREADED), or simply CoInitialize() or OleInitialize(). This type of thread must service the message queue for the following two reasons:

  • COM creates a hidden top-level window when a thread calls the APIs mentioned above. A thread must always service the message queue if it creates top-level windows. If it does not, the thread can block the global broadcast of messages by any application using the SendMessage API.
  • Incoming calls into the apartment are delivered as messages posted by COM to this hidden window. If the thread does not service the message queue, it will not receive incoming calls.

A thread initializes COM libraries for the Multi Threaded Apartment(MTA) by calling CoInitializeEx(0, COINIT_MULTITHREADED). This type of thread does not need to service the message queue, because incoming calls into this type of apartment are delivered through RPC runtime threads and not through windows messages. COM does not create any windows when the thread calls CoInitializeEx(0, COINIT_MULTITHREADED). The RPC runtime creates hidden windows as needed to facilitate calls. The RPC runtime does this on its own threads and it services the message queue. However, due to the bug described in this article, the RPC runtime creates a window on the client's thread and does not destroy this window when the call completes. If the client does not service the message queue, this top-level window will block global broadcasts.

REFERENCES

For additional information, please see the following article in the Microsoft Knowledge Base: 

   ARTICLE-ID: Q136885
   TITLE     : INFO: OLE Threads Must Dispatch Messages

Keywords          : LeTwoCom
Issue type        : kbbug

================================================================================

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: March 2, 1998
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.