The Case of the Three Second Delay (a.k.a What is SFTDDE?)
A while back I encountered an issue that forced me to become introduced to the DDE Launcher used by App-V (SFTDDE.) A customer was encountering an issue where, no matter how much they tuned their terminal servers, even with pre-cached virtual applications; Office applications appeared to always have a three second delay when they double-clicked on an Office document associated with a virtualized instance of Office. Regular launches of these applications (from the shortcut) did not encounter this delay.
What is DDE?
DDE (Dynamic Data Exchange) is one of the oldest IPC (Interprocess Communication) mechanisms in Windows. Since it relies on using the Windows message layer for functionality it still works even though it has been superceded by many far superior technologies. The factor involved in this particular App-V scenario is whether DDE (Dynamic Data Exchange) has been enabled for the application. The main difference between double-clicking a document or launching the application then loading the document when DDE is enabled is that SFTDDE.EXE is used as a DDE launcher instead of SFTTRAY.EXE.
Investigating the customer’s issue found that there was indeed a three-second delay and a Process Monitor trace revealed it:
Double-clicking and triggering the SFTDDE.EXE process:
0 7:47:03.3683129 AM sftdde.exe 848 Process Start SUCCESS Parent PID: 2844
Then the SFTTRAY Start:
3007 7:47:06.1107902 AM sfttray.exe 3408 Process Start SUCCESS Parent PID: 848
By default in App-V when sequencing Office, DDE is enabled. When setting up a file type association that requires DDE support, the client uses a DDE Launcher command. It pulls the command based on the value specified in the following registry location:
The default value is “C:\Program Files\Microsoft Application Virtualization Client\sftdde.exe” “<APP>” <DDE>
If present, the strings <APP> and <DDE> will be replaced with the app’s name and version and the DDE app name, respectively.
When virtualizing Office with App-V, the sequencer enables DDE functionality by using the SFTDDE launcher for each application. One important item to consider is that when double-clicking on a file where the association is with SFTDDE rather than SFTTRAY, App-V will act as a DDE client and sends DDE message broadcast to all open windows. If an instance of word is open, then it will reply back and that instance of WinWord will open the file – regardless of the version of the winword.exe process running. If not, it will trigger the SFTRAY command to launch.
Is this why my Custom File Type Associations Don’t Work Sometimes?
Yes. This explains why in some cases you may have a local or virtualized instance of Microsoft Word 2003 running side by side with Microsoft Word 2010 running local or virtualized. Let’s say you have the .DOC extension associated with Microsoft Word 2003 and the .DOCX extension is associated with Microsoft Word 2010. If Microsoft Word 2010 is currently running and you double-click on .DOC file, it will still open in the existing Winword.exe process (which in this case would be Microsoft Word 2010.)
Why sometimes a delay?
The delay occurs when there is one or more hung top-level windows on the system. When using ShellExecute or ShellExecuteEx to open a document in its associated application and the file is registered to use DDE, the shell will first try to establish a DDE conversation with a running instance of the application by broadcasting a DDE initiation message to all top-level windows.
The DDE initiation message is broadcasted by calling SendMessageTimeout with a 3 second timeout. When there is a hung top-level window when the DDE message is sent, SendMessageTimeout will be blocked until the message is handled by the hung window or the timeout expires. Once the timeout expires, the shell will launch the application associated with the document.
Should I remove this?
For Office, it would be a bad idea. Every trigger of a document double-click will spawn an SFTTRAY launch of the Office application chosen. I have had many customers remove the DDE section, and have %1 as the only option. The DDE message broadcast does not happen and a new instance of the application opens the file. Eventually they restore the functionality and live with the DDE delay.