Stream Deck software and Omea Reader

February 13, 2023 6:39 PM

Can you help me debug an obscure Windows issue relating to a delay when when opening URLs from a program when the Stream Deck software is running? It's related to DDE.

I use an ancient program called JetBrains Omea Reader as an RSS reader. It's long been abandoned and unmaintained but it's a .NET 2.0 application so I figure it should continue working fine.

I recently started using a Stream Deck. However, whenever its software is open, there is an extremely annoying ~1 second delay when clicking a link in Omea before Firefox activates and opens the tab. The delay is not present when the Stream Deck software is not running.

Doing some digging in the Omea logs, whenever it is asked to open a link there are several lines like

13.02.2023 18:13:30.711 [N] [UIM]: Error making a DDE conversation to the Browser at "iexplore" on topic "WWW_OpenURLNewWindow" with command "https://example.com",,0. Could not start the DDE conversation. A client's attempt to establish a conversation has failed.
13.02.2023 18:13:30.931 [N] [UIM]: Error making a DDE conversation to the Browser at "iexplore" on topic "WWW_OpenURL" with command "https://example.com",,0. Could not start the DDE conversation. A client's attempt to establish a conversation has failed.
13.02.2023 18:13:31.150 [N] [UIM]: Error making a DDE conversation to the Browser at "iexplore" on topic "WWW_OpenURL" with command WWW_OpenURL. Could not start the DDE conversation. A client's attempt to establish a conversation has failed.

This, I believe, is standard behavior. Something inside the guts of Windows or the .NET stdlib tries to establish communication with a running Internet Explorer, and when that fails it launches the browser process -- in my case Firefox but I've verified that it makes no difference with Chrome set as the default browser. These are expected to always fail.

I did some digging and found an ancient tool called DDESpy that can show DDE errors in realtime. When the Stream Deck software is not running, all three messages appear nearly instantly:

Task:0x3918 Time:84456171 Error: #400a = No_conv_established
Task:0x3918 Time:84456171 Error: #400a = No_conv_established
Task:0x3918 Time:84456187 Error: #400a = No_conv_established

However, when it is running, there's a few hundred millisec timeout between them:

Task:0x3918 Time:84504187 Error: #400a = No_conv_established
Task:0x3918 Time:84504406 Error: #400a = No_conv_established
Task:0x3918 Time:84504625 Error: #400a = No_conv_established

This leads me to believe that the Stream Deck software for some reason is hogging/blocking the DDE message pump, which as I understand it is a global system resource. I have no idea why it would, because nothing uses DDE these days, but it could be deep in a dependency that it uses.

My questions:

- How can I make the Stream Deck stop doing this?
- How can I tell the guts of Windows not to try to use DDE for https: and http: url-handlers?
- Has anyone else experienced this and know of any solution?

System info:
Windows 11
Omea Reader 2.2
Stream Deck 6.0.4


[Rant: I keep buying these productivity gadgets only to find that the software is, without fail, a steaming pile of shit. Why has the art of writing software been lost?]

posted by Rhomboid to Computers & Internet (4 answers total)

First thing I do when Windows starts to lag badly is find out whether something is just brutally consuming all available CPU. In my experience, USB devices can do this if the cable connection is flaky, because this can generate connect/disconnect interrupts at a pace insane enough to bog down the kernel.

I keep buying these productivity gadgets only to find that the software is, without fail, a steaming pile of shit

Doctor, it hurts when I do this?

For what it's worth, I absolutely agree with you about the apparently inevitable shitfulness of productivity gadget software. To my mind this is all of a piece with the apparently inevitable shitfulness of "enhancement" products generally, especially those targeting Windows, and on the whole I think that my personal policy of assiduously avoiding all such products has saved me far more time and aggravation than any of them even promise to do. If the marketing guff for anything describes it as "easy" or "smart" then it almost always goes instantly on my Do Not Want pile.

I also have a lot less faith than you do that the act of writing commercial software has ever risen to the level of art; nothing of value has been lost :-)
posted by flabdablet at 8:28 PM on February 13, 2023

Also I feel like this is the perfect question for Raymond Chen. If anyone around here is friends with him, could you... *looks down at ground and nervously fidgets* help a guy out.
posted by Rhomboid at 8:50 PM on February 13, 2023

So DDE used to work by broadcasting messages to all top-level (application) windows and seeing who responded, so there are infinite chances for apps to screw it up for everyone.

The nice thing about non obfuscated .net apps is you can decompile them pretty cleanly to see what they are doing with something like dnSpy. You can even modify and rebuild stuff which is pretty cool. Having a quick peek at Omea reader it looks like you can edit this file in notepad:

C:\Users\Rhomboid\AppData\Local\JetBrains\Omea\OmniaMea.ini

Find the [General] section and change AllowBrowserDde to 0

[General]
AllowBrowserDde=0

If that doesn't work, you should be able to nuke the registry folder HKEY_CLASSES_ROOT\https\shell\open\ddeexec - I promise the only thing it will break is DDE control of Internet Explorer.
posted by samj at 2:39 AM on February 14, 2023

Holy shit, yes, setting that to 0 fixed it. Amazing! I had even looked over that ini file for anything relevant but my eyes must have glossed over that.

It was a stupid little delay but it was driving me crazy, and now I no longer have to feel bad about buying a piece of kit that makes me feel bad while using it. Again, thanks.
posted by Rhomboid at 9:38 AM on February 14, 2023