How do I register a command on the desktop background context menu? (And how do I remove one I don't like?)


To register a command to appear on the context menu for the desktop background, you put it under the predefined shell object Desktop­Background. (For some reason, this predefined object is not on the list of predefined objects, although its existence is betrayed on this page.) As with all progids, simple commands can be registered under the shell key; complex commands can be registered under the shellex key. For example, this registration adds an entry called CharMap that runs, um, CharMap. In case you wanted to be able to launch CharMap right from the desktop context menu.

[HKEY_CLASSES_ROOT\DesktopBackground\shell\CharMap\command]
@="charmap.exe"

Many shell extensions choose to register under Directory\Background, and then perform a test at runtime to see if the directory is the desktop. If so, then they add the extension; if not, they suppress it.

Therefore (reading the contract from the other side), if you want to remove an item that some random third party added to your desktop context menu (for some reason, video card manufacturers love adding stuff to the desktop context menu), you can go spelunking into

HKEY_CLASSES_ROOT\
    DesktopBackground\

and

HKEY_CLASSES_ROOT\
    Directory\
        Background\

When I do this, I prefer not to delete the registry key entirely, because who knows, maybe someday I want to re-enable it. In the case of a context menu shell extension, I disable it by reversibly corrupting the CLSIDs.

HKEY_CLASSES_ROOT\
    DesktopBackground\
        shellex\
            ContextMenuHandlers\
                x{########-####-####-####-############}\
                    @="x{########-####-####-####-############}"

HKEY_CLASSES_ROOT\
    Directory\
        Background\
            shellex\
                ContextMenuHandlers\
                    x{########-####-####-####-############}\
                        @="x{########-####-####-####-############}"

By putting an x in front of the curly brace, I prevent the key name or value from being parsed successfully as a CLSID, but I can easily re-enable the extension by removing the x.

Note that most registrations will not have two CLSIDs. Some will put a CLSID in the key name, and others will put the CLSID as a value under the key. So whichever one you see, stick an x in front.

Comments (31)
  1. skSdnW says:

    And if you are not admin or on a shared machine you can corrupt it by making a broken entry under HKCU\Software\Classes.

    A certain intelligent integrated video card manufacturer adds a context menu entry there and every time you right-click the desktop they load a new instance of one of their support DLLs eating away Explorers virtual address space. I guess they never had Process Explorer open during development...

  2. Luke727 says:

    My eyes, the goggles do nothing!

  3. Brian_EE says:

    Next week's Little Program: Enumerating all the desktop background context menu handlers and letting you pick one to run.

  4. Sven2 says:

    Knowing these two locations, I wonder if there's any problem with changing their access permissions to prevent installers (and updaters) to enter (and re-enter) their entries I don't want?

    Also, is it just me or did the color scheme of the page change from the more readable feces-colored scheme to a standard black-on-white?

  5. Tom says:

    What happened to the look and feel?

  6. Which "charmap.exe" do you want to run?
    The "charmap.exe" from the application directory of "explorer.exe" (which happens to be %SystemRoot%), or the REAL "%SystemRoot%\system32\charmap.exe"

    Kids, you have been warned;-P

  7. Joshua says:

    Amusing that Raymond's custom theme went away and we now have the default blog theme.

    1. At least its font is great. Segoe UI. I personally prefer Open Sans, but no complaints, as long as it isn't Verdana.

    2. DebugErr says:

      I wonder if this "upgrade" destroyed all his images again, which was a reason why he creates HTML renditions of tables, charts, and other things since years.

  8. Piotr Siódmak says:

    Doesn't corrupting the CLSIDs slow down the system?

    1. skSdnW says:

      No Piotr, it should be faster. The shell will read the registry key as normal but the conversion from string to GUID will fail and it does not even try loading a dll.

  9. sense says:

    If I wanted to deal with this, I'd have renamed the dll file. Never trust an unwanted shell extension!

  10. CarlD says:

    Wow - what happened to Raymond's classic blog-post styling? Today this looks like every other MSDN blog.

    1. JanH says:

      It's not perfect, but here's an approximation of the old style until Raymond gets around restoring the old style - if it's still possible with the new blog system:
      https://userstyles.org/styles/121616/the-old-new-thing-classic-style

      1. cheong00 says:

        Try remake the theme with bootstrap 3.3.5 then. That should work on this site. :P

  11. CarlD says:

    Oh - and the URL has changed - the extraneous /b has disappeared. Looks like MSDN blogs were upgraded to a newer version of Community Server?

  12. Nico says:

    I like using the desktop background handler for opening a command prompt (using Shell instead of CLSIDs). Makes opening a command prompt pointing at my desktop folder really easy.

    Also: My poor eyes :( I hope you're able to restore the soothing beige and taupe theme!

    Edit: No more Community Server! Leaving the Email field blank shows a WordPress error at https://blogs.msdn.microsoft.com/oldnewthing/wp-comments-post.php. Sad day.

  13. -1 on the new blog theme.

    It also looks like comments are still open on topics from the last 2 weeks (instead of 1 week)? Now I have to keep 10-12 tabs open to read all of the comments instead of 5-6. #FirstWorldProblems

    1. Jolyon Direnko-Smith says:

      I'd go further: while NOT oldTheme do Dec();

      Also for a minute I thought the blog had disappeared completely because my bookmark included a "/default" tail which yields a super friendly "Oops! That page can't be found" error.

      1. skSdnW says:

        Old URLs without /b/ like http://blogs.msdn.com/oldnewthing are broken now because one of the 30x server redirects adds the /default suffix for some reason...

  14. Something terrible has happened to the stylesheet on this blog.

  15. MacMac says:

    It's a sad day. I guess Raymond will announce he's retiring soon.

    1. DebugErr says:

      It's more like the people who upgraded his blog will retire soon, after he spoke some words of might to them =)

  16. Vulpini says:

    Just to add my own off-topic two cents about the blog change: looks like comment-links are broken again. And even more broken than last time, where you just had to load the address again (anchor was correct): now the comment IDs have changed!

    Old-style comment link from one of your previous posts: http://blogs.msdn.com/oldnewthing/archive/2008/02/04/7439619.aspx#7442093
    New link to the same comment: https://blogs.msdn.microsoft.com/oldnewthing/20080204-01/?p=23583#comment-598013

    Probably not much one can do to fix these links now, short of reverting to the old software (and database) - and that's probably not going to happen.

    And now I have to click a bunch of 'read more' links when browsing old posts... might be time to get into userscripts again.

  17. NewUser123 says:

    Nice, so I can use this to remove that useless "scan with windows defender" option from windows 10 right click context menu ?

  18. sense says:

    And nested comments ... I *hate* nested comments, especially multilevel nested ones.
    It makes reading the "new" comments exceptionally hard.
    Anybody knows of some workaround please?

    1. in dent says:

      Yes nested comments are terrible. I don't like the new old new thing

    2. morlamweb says:

      @sense: I prefer the nested comments, because it makes it easier to follow conversations in the comments section (vs. tracing the @tags and lots of up & down scrolling).

  19. Bob Bobson says:

    > Many shell extensions choose to register under Directory\Background, and then perform a test at runtime to see if the directory is the desktop. If so, then they add the extension; if not, they suppress it.

    Ah, I was wondering why Intel would add their graphics-adapter control panel extension to Desktop\Background; I was wondering if they were daft enough to think that users would actually want it in every folder.

    > When I do this, I prefer not to delete the registry key entirely, because who knows, maybe someday I want to re-enable it. In the case of a context menu shell extension, I disable it by reversibly corrupting the CLSIDs.

    I’ve always used a ‘#’, but it’s the same principal. One thing though; you MUST put it at the BEGINNING of the CLSID; putting it at the end will allow it to continue working.

    (Now if I could just figure out why adding the FastExplorer extension from AllDup to Directory\Background\ShellEx—or DesktopBackground\ShellEx—doesn’t work. I swear it did at one point, but now it refuses to. It only works from Directory\ShellEx or as a flat-command in Directory\Shell. ಠ_ಠ)

  20. GPF says:

    Now THIS was useful! I loaded Code, then deinstalled it because it wasn't for me. It had left a right-click context menu piece saying "Open in Code" quite cheerfully.
    Now it's dead and gone and I am happier now than I was just a few minutes ago.

Comments are closed.

Skip to main content