BUG: DDEML: Advise Stop Causes Disconnect

The Dynamic Data Exchange Management Library (DDEML) may unexpectedly terminate an existing conversation when the client attempts to end an advise loop by calling DdeClientTransaction with the wType parameter set to XTYP_ADVSTOP.

This behavior might occur when a server is maintaining a hot-link advise loop with a client and is sending updates very rapidly. In addition, the client must initiate the advise loop by requesting that the server wait for acknowledgements before posting the next data item. (This is done by ORing the XTYPF_ACKREQ flag with the XTYP_ADVSTART flag in the wType parameter of DdeClientTransaction.)

If the above situation exists, it is possible for a client to stop the advise loop before it has acknowledged the receipt of the last data item. If this happens, the DDEML receives notification to end the advise loop before it receives the final acknowledgement from the last data update that it sent. In this situation, DDEML responds to the notification to end the advise loop by cleaning up the internal data structures that it was using to keep track of the conversation. The problem occurs when, after cleaning up the internal data structures, it receives the final acknowledgement for the last data update. Since it has just destroyed all records of the conversation that the acknowledgement belongs to, it treats this message as a spontaneous message generated by the client. Because a spontaneous message violates the DDE protocol, it terminates the conversation.

This problem is a race condition and, therefore, this behavior may not occur all of the time. The problem may also surface after you make minor changes to the application code or after you upgrade an operating system (such as adding a service pack).

This problem only occurs if the XTYPF_ACKREQ flag is used to request that the client wait for acknowledgements before sending the next data update. If the client is capable of keeping up with the server, this problem can be avoided by not using this flag.

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.

The following sequence of messages occur if the problem arises (these could be viewed using Spy++):

... If this problem does not occur, the last two messages would take place in reverse order, with the WM_DDE_ACK occurring prior to the WM_DDE_UNADVISE.