BUG: DDEML: Advise Stop Causes Disconnect (165305)


The information in this article applies to:

  • Microsoft Platform Software Development Kit (SDK) 1.0
This article was previously published under Q165305

SYMPTOMS

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.

CAUSE

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).

RESOLUTION

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.

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

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

... 
WM_DDE_DATA          <Server posts Data>
					
WM_DDE_ACK           <Client acknowledges receipt>
					
WM_DDE_DATA          <Server posts Data>
					
WM_DDE_UNADVISE      <Client posts a notification to stop the advise loop>
					
WM_DDE_ACK           <Client acknowledges receipt of last data>
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.
Modification Type:MinorLast Reviewed:7/11/2005
Keywords:kbbug kbDDE kbprogramming kbUser KB165305
©2004 Microsoft Corporation. All rights reserved.