Are DDE and WM_COPYDATA related as IPC mechanisms?


A customer liaison asked whether DDE and the WM_COPY­DATA message were related as IPC mechanisms. Specifically, are they dependent on each other, or are they independent?

The two communications mechanisms are independent. I mean, sure, they are related in the sense that they both use window messages, but there is no cross-dependency between them. You can use one without the other, and neither depends on the other.

In practice, you are likely to see one or the other, but not both. Very old programs will use DDE, because DDE was invented first. Newer programs will use WM_COPY­DATA and ignore DDE because you are free to stop using DDE.

The customer liaison explained that the customer has a very old suite of applications which they are trying to migrate off their Windows Server 2003¹ systems to Windows Server 2008 R2, but the programs are getting into a hung state after an extended period of use. Looking at the memory dumps (filled with many ancient components, some provided from a third party, for which they have no symbols), reveals that two of the processes appear to be stuck sending a WM_COPY­DATA message. The customer claims that their programs communicate with DDE, not WM_COPY­DATA, which led to the customer liaison asking if DDE and WM_COPY­DATA were somehow interdependent.

The two are not interdependent. They are two different ways of performing inter-process communication. Fortunately, WM_COPY­DATA is easier to debug than DDE because WM_COPY­DATA is a synchronous message. If a WM_COPY­DATA is stuck, you can extract the window that is the target of the message, get the thread responsible for that window, and then study that thread to see why it is not responding.

My guess is that the customer has existing code that has taken a lock (let's call it Lock A), and then did something that processes inbound sent messages, say entering a message loop or sending a cross-thread message. While the thread is pumping messages or waiting for the cross-thread Send­Message to complete, another thread sends a WM_COPY­DATA message, and now the window procedure is being re-entered. The WM_COPY­DATA message tries to take a different lock (let's call it Lock B), and blocks. Meanwhile, the owner of Lock B wants to take Lock A, and we now have a deadlock. Reason: Pumping messages (or sending messages between threads) while holding a lock creates a lock inversion opportunity. Inspection of the stuck stack would reveal whether any window procedure re-entrancy is active.

This is a timing bug that could be the sort of thing exposed by a change in OS.

Bonus trivia: A colleague tells me that the WM_COPY­DATA message was originally added in order to support the 32-bit version of MS Mail on the initial builds of Windows NT. Obviously, other people found other uses for the message since then.

¹ That is not a typo. They are running on a 13-year-old operating system which exited extended support over a year ago.

Comments (21)
  1. kantos says:

    The source OS of Win2003 didn’t surprise me so much as the target. If you’re going to update a program to work on a new OS… why not just go to the latest? Going to an OS that is no longer in mainstream support seems counter-intuitive to me. I realize that there is always an issue of Time, Money, People in getting things ported… but still.

    1. Nick says:

      If we’re very lucky, it’s because they’re taking small steps rather than one giant leap and that this is just the beginning of their modernization process. I doubt we’re that lucky though and look forward to the blog post in 2022 talking about migrating away from Windows Server 2008 R2 to Windows Server 2012 R2.

      1. kantos says:

        Once you make it past Server 2008 you’ve already made the NT6.0 leap and that’s the big one. The rest shouldn’t be too hard in theory. Is it marginally more than NT6.1? Yes, but not enough to justify holding yourself back when the overall benefit is much larger. But I suspect you’re correct and they are doing this out of an overabundance of caution.

      2. Joshua says:

        Porting an old version of our app form Windows Server 2003 to Windows Server 2008 R2 required exactly 1 hitpoint provided you were willing to turn UAC completely off. Windows Server 2008 R2 is the last OS on which you can do that reasonably without breaking too much.

        We did eventually track down the UAC problems one by one. The final solution was don’t install in program files anymore to keep away from folder redirection. (Even that ancient version already didn’t require any privileges; however it still depends pretty hard on the classical model of filesystems, that is all programs see exactly the same version of the disk.) We were forced out of Program Files on Windows Server 2003 x64 for the same reason.

        1. DWalker07 says:

          Yuck. I would hate to have to rely on programs that don’t work well when things are installed in Program Files directory (or the x86 one).

          I recently dealt with a program that wanted to install into the root of C, requiring a path with no spaces (and even documenting this fact, like “We don’t understand how to use paths properly and we can’t be bothered to learn”). I decided not to use that program at all.

          1. Joshua says:

            The problem *is* folder redirection. The program gets upset when it hands off files to other arbitrary programs and they can’t find them because they have manifests that result in different folder redirections. I asked for a flag I could set on a folder to exempt it (like registry has) and was refused.

        2. kantos says:

          Use handles, then folder redirection isn’t an issue? Regardless you’ll still have to deal with the problem. Moving things around is just delaying the inevitable, better to fix it properly now particularly since Server 2008 R2 only has 3 years of support left.

          1. Joshua says:

            Try convincing Microsoft and Adobe to make a way to open documents given a handle. Go ahead, just try it.

        3. ender says:

          How does (not) installing to Program Files affect folder redirection? System32 will be redirected to SysWow64 for 32-bit programs regardless of where they’re installed (there’s no redirection for Program Files), and folder virtualization only affects programs that don’t have Vista manifest.

          1. Joshua says:

            Easy. I don’t place any files in system32 or syswow64. Folder redirection works fine for OS-provided files.

    2. Pierre B. says:

      My guess is they have a park of servers with different OS. The fact that Server 2003 is no longer supported is probably what is forcing them to upgrade that program. I’d guess they kept the old servers around for so long because that program would not run on newer versions. Now, they decided they have to face the music a figure out what was the source of the incompatibility.

  2. I was once asked step in on a project to migrate a networking process written in C++ from a 2000 box to 2008. The process would always stop exchanging networking traffic after a few minutes on the new box. Investigations revealed that the original programmer seemed to take MSDN’s “don’t do this” warnings as a best practices guide, and it wasn’t clear how the networking code worked at all, except by pure dumb luck. At least it was easy to fix.

  3. DWalker07 says:

    And the customer decided RECENTLY to move to Windows Server 2008 R2, which is also an older operating system? There are newer server operating systems! Server 2008 R2 has only about 3 more years of extended support; mainstream support has already ended.

    They could have gone to Windows Server 2012… if their programs would have run, that is.

    1. DWalker07 says:

      … And, of course, there’s always Windows Server 2016… now that we are in the year 2017…

  4. Paul Topping says:

    If DDE messages are async, wouldn’t that be a reason to use them over WM_COPYDATA in applications where asynchronicity is desired?

    1. Klimax says:

      IIRC if any other DDE user misbehaves it will freeze your instance even if bad apple is not target.
      There might be other problems including performance.

  5. MarcK4096 says:

    Given how some of Raymond’s posts discuss events that occurred way in the past, I didn’t think twice about the reference to Server 2003. I just assumed this was a story from 2009.

  6. 640k says:

    Not really free to stop using DDE if you are depending on stuff that use DDE, like parts of windows, please remove it altogether, asap.

    Can other mail app developers also request new messages that will be added to the OS?

    1. Explorer stopped requiring DDE over two decades ago.

      1. 640k says:

        ShellExecuteEx still rely on DDE.

        1. ShellExecute uses DDE when the application being launched says, “Please use DDE.” It will not use DDE if it isn’t explicitly requested. And you aren’t required to use DDE to interact with the shell. Your app can continue to pretend that DDE simply doesn’t exist.

Comments are closed.

Skip to main content