What is the strange garbage-looking string in the "command" value of a static verb?

A customer from a major software vendor asked, “What is the significance of the command value that can be found under HKCR\⟨progid⟩\shell\open\command. It appears to be a copy of the default value, but with the program name replaced with apparent garbage. We’ve seen this both with Microsoft products as well as products by other companies. There is no mention of this value in the documentation on static verbs.”

Name Type Data
(Default) REG_SZ “C:\Program Files\Contoso\CONTOSO.exe” /NOLOGO “%1″
command REG_MULTI_SZ 34GY`{XL?{Y)2S($,PP>c=@0l{Ja0N8KUwy@4JdO /NOLOGO “%1″

The customer didn’t explain why they were interested in this particular registry value. Maybe they thought it was enabling some super magical powers, and they wanted to get in on that action. (If that was the case, then they failed to notice that the same command value also existed in the verb registration for their own program!)

That strange garbage-looking string was placed there by Windows Installer (also known as MSI). It is the so-called Darwin descriptor that Windows Installer uses to figure out what program to run when the verb is invoked by the shell. For compatibility with programs that read the registry directly (because everybody knows that reading the registry is much cooler than using the API), the default value is set to something approximating the local executable’s path. That default value might be incorrect if the application has moved in the meantime, and it might be missing entirely if the application is marked as install-on-demand and has never been used, but at least it keeps those rogue programs working 99% of the time.

Comments (14)
  1. Joshua says:

    As for why programs read the registry for this, in the 1995 era most people were using BC4.51 as the compiler which had 3.51 documentation. The registry was discoverable. The API was not. If you didn't know to use ShellExecute you couldn't find it.

  2. Koro says:

    Given that the registry supports binary values, it seems counterproductive to use something which looks like a Base64-encode of binary data in there.

  3. Antonio Rodríguez says:

    Well, the Classes key of the registry is a mere contract between applications and installers, in one side, and the shell (be it Explorer or whatever the user wants to use) in the other. As such, it's fully documented, and you just linked to it in the article (by the way, the link is broken). I find it legitimate to interpret that contract from the other side. A compressed file manager (as 7-Zip) or an alternative shell are examples of programs that may want to do that for legitimate reasons. As I see it, the default value for MSI managed applications is more than a mere compatibility fix: is necessary to comply with the specification.

  4. WndSks says:

    How did this work in the early days when MSI was not part of the OS? Did shell32.dll get updated by the MSI Redistributable or did it require a Internet Explorer upgrade as well?

  5. alegr1 says:

    The sooner MSI goes away the better. It's one fragile super-slow overdesigned clusterbug.

  6. Daniel says:

    There is an other reason why to modify these entries: Some application that we used regularly did a "Verify if the installation is still OK" check (which checked file associations and entries in the start menu). Each time you started a file by double-click it would reinstall these settings to the same annoying values as during the installation (The point was that I'd rather kept the original associations with a different application. And I used a customized tree structure in the start menu to avoid a single menu with dozens of entries).

    I first just changed the file associations and my start menu manually (since the installer didn't give any options there). –> However as I said, the settings mysteriously kept reappearing. Looking somewhat further I've seen these entries (on those file associations that I kept with the old application). Deleting them solved my problem…

    I agree that's pretty hackish solution. But at least the application stopped bothering me with "I need to reinstall"

  7. Dan Bugglin says:

    @Koro there is text data in there too (the program arguments).

    Of course they could have been separate values.  Would have been easier to parse.

    @alegrl1 I imagine businesses find it invaluable for adminstrating program installs remotely.  Google even provides an MSI'd Chrome for businesses, as an alternative to the Google Update-installed version.

    @Daniel This is likely why newer Windows do not allow programs to set file associations automatically through the registry any more; at least, the old keys don't work.  Setting those associations only triggers Windows to discover that your app is an option to handle those files (and I think Windows 8 displays the notification in the corner when you open a file that has new handlers available for it).

  8. Anonymous Coward says:

    So it didn't occur to you that they might simply be worried or interested?

  9. Joker_vD says:

    @Joshua: Are they the same engineers that think that DEB or RPM packets are good for application installing purposes?

  10. Joshua says:

    @Joker_vD: False equivalence.

  11. alegr1 says:

    > I imagine businesses find it invaluable for adminstrating program installs remotely.

    Ability to install remotely is not a magical property of MSI packages. It's just the remote installation services (Microsoft and ISV) support it. It doesn't make MSI executive any less retarded. Besides from being, in essence, an ultra-slow table-driven glorified UNZIP, there is one thing that tells that MSI executive is very ill-designed – during installation, there is a free-running (polling?) thread, that slows everybody down.

  12. Joshua says:

    @alegrl1: MS will never understand *why* many competent engineers have regarded MSI as ready for the scrap heap.

  13. yuhong2 says:

    @skSdnW: I think it required IE 4.01 SP1 or later with Windows Desktop Update installed which updated shell32.

  14. Phil W says:

    You'll see the same descriptor in COM registration that MSI creates through its Class table, and there's one hidden in MSI-created shortcuts too. After decoding into things like ProductCode and Component guid there are APIs like MsiGetComponentPath() that tell you the target, invoking repair if required.

Comments are closed.