Registered File Association no longer working in MFC App after porting to 64 bits?

John Wilk 0

Our application has stopped working when a user double clicks on a data file that has been registered with the shell. When the user double clicks the data file the application is still opened by windows and the '/dde' command line argument is received, but no WMDDE messages are received. I'm expecting and had been recieving a WMDDE_EXECUTE message with the file path and name.

John Wilk 0 Reputation points

2023-02-02T21:52:40.04+00:00

Is there a way to change the timing of the DDE messages? My fear is that it is taking to long for the application to start between the application starting and the applicaiton's message pump being up and running. I'm not seeing any of the DDE messages when it the application starts up. I get the FileDDE command line argument but not the WM_DDE_EXECUTE. Nothing has changed in the registry with respect to the application.
David Lowndes 4,711 Reputation points

2023-02-02T23:48:41.79+00:00

You mentioned initially that it stopped working, so presumably it used to work. Has something changed that's had the effect of increasing your application's startup time? If you revert that, does it then work again?
YujianYao-MSFT 4,271 Reputation points Microsoft Vendor

2023-02-03T03:09:27.4166667+00:00

Hi John Wilk,

How to reproduce this problem? It would be great if there was a minimal executable program to reproduce it.

Also, I recommend you to check if some functions are not replaced with x64-friendly versions, because some functions have x64-supported versions.
John Wilk 0 Reputation points

2023-02-03T19:29:25.6833333+00:00

I can send an example program and I have now narrowed it down. I don't think it is a 32 to 64 bit issue and its not a timing issue, when we ported we also switched from Visual Studio 2013 to VS 2017. I just created two identical example programs one in 2013 and one using 2017 and the 2013 version works but the 2017 does not.
David Lowndes 4,711 Reputation points

2023-02-03T23:40:18.8133333+00:00

OK, have you tried building it with 2022?
John Wilk 0 Reputation points

2023-02-04T02:19:35.89+00:00

I did try it in 2022 and it doesn't work either and this is all on Windows 10 things get even wonkier in Windows 11. Funny thing is on Winodows 10 and 2017 using the registry settings of HKCR\Applicaction.Document\shell\open\command\pathtoapplicaion.exe and a ddeexc entry of [open("%1")] works but if you add a /dde argument to the pathtoapplicaiton.exe registry setting it doesn't. This worked in VS 2013. and if you remove the ddeexec entry in the registry and use "%1" instedad off /dde everything works fine. And neither of the first to version work (both 2013 and 2017) work on windows 11. I am forced to believe that DDE is just broken now at least as far as file registrations and double clicking on file are concerned. So I am going to recomend to my company they just drop dde. It would be just nice to know what broke in dde.
RLWA32 40,021 Reputation points

2023-02-04T09:12:21.9333333+00:00

So I am going to recomend to my company they just drop dde.

You are in good company by recommending that its time to abandon DDE. As far back as 2007 Microsoft's Raymond Chen was giving the same advice (Please feel free to stop using DDE) which he repeated in many of his subsequent blog articles.

2 answers

RLWA32 40,021 Reputation points

2023-02-03T09:02:33.9433333+00:00

A general observation is that failures to connect with a started DDE server process are often caused by the manner in which the WaitForInputIdle function determines that the DDE server process is ready for communication to begin. Basically, the DDE Server process has done something during startup to cause WaitForInputIdle to believe that it has gone input idle before it can process DDE messages.

Raymond Chen's blog contains a number of articles about this issue. For example,

Psychic debugging: Understanding DDE initiation

WaitForInputIdle should really be called WaitForProcessStartupComplete

WaitForInputIdle waits for any thread, which might not be the thread you care about

Once you go input-idle, your application is deemed ready to receive DDE messages

On the importance of making sure WaitForInputIdle doesn’t think you’re idle, episode 1

On the importance of making sure WaitForInputIdle doesn’t think you’re idle, episode 2
Please sign in to rate this answer.

0 comments No comments
Sign in to comment
John Wilk 0 Reputation points

2023-02-10T16:29:44.1766667+00:00

Finally figured out the answer and it is, "sort of", a 32-64 bit issue. When run from anywhere but the "C:\Program Files (x86)" directory DDE wont work, at least not for opening a registered file when the application itself hasn't already been opened. When placed in the C:\Program Files (x86) directory, it does work correctly.
Please sign in to rate this answer.

0 comments No comments
Sign in to comment