Psychic debugging: Understanding DDE initiation
You too can use your psychic powers to debug the following problem:
We have a problem with opening documents with our application
by double-clicking them in Explorer.
What's really strange is that if we connect a debugger to Explorer
and set a breakpoint on kernel32!CreateProcessW,
then wait a moment after CreateProcess returns,
then hit 'g',
then the document opens fine.
But if we don't wait, then the application launches but the
document does not open.
Instead, you get the error message "Windows cannot find
'abc.lit'. Make sure you typed the name correctly,
and then try again."
Here is the command we are executing when we run into this problem:
"F:\Program Files\LitSoft\LitWare\LitWare.exe" /dde
What is wrong?
If you've been reading carefully and paid attention to the explanation of
how document launching via DDE works,
then you already know what the problem is.
Recall that launching documents via DDE is done by first
looking for a DDE server and if none is found, launching
a server manually and trying again.
The command line above was clearly registered as the
command associated with a
ddeexec.
There are two giveaway clues.
First is the fact that the document name itself is not present anywhere
on the command line.
(This couldn't be a direct execution because the program wouldn't know
what document it's supposed to be opening!)
But the
giveaway clue is the phrase /dde on the command line.
Clearly, something is going wrong when Explorer attempts the
second DDE conversation to open the document.
The fact that making Explorer wait a few seconds fixes the
problem makes the cause obvious:
The DDE server is being slow to get itself initialized and listening.
Explorer launches the server and tries to talk to it,
but the server is not yet ready and therefore doesn't respond to
the DDE initiate.
But how do you fix this?
The shell assumes that a DDE server is ready to accept connections
when it goes input idle.
Once WaitForInputIdle on the DDE server returns,
Explorer will make its second attempt at initiating a DDE conversation.
The fix is for the application to get its DDE server up and running
before it starts pumping messages.
My guess is that the application moved its DDE server
to a background thread to improve startup performance,
since the DDE server is not involved in normal program operation.
Too bad the program forgot to get the DDE server up and running
prior to going input idle when the /dde flag is passed.
The one time it's important to have the DDE server running and it
misses the boat.
Moral of the story:
If you're going to act as a DDE server,
make sure you do so before your primary thread starts pumping messages.
Otherwise you have a race condition between your application startup
and the shell trying to talk to it.
