Where did my mail control panel icon go?


A customer ran into the following problem:

I was trying to add another email account to Outlook, and the instructions say that I should go to the mail icon in the Control Panel, which to my surprise is nowhere to be found! How can I figure out what went wrong?

A little bit of psychic debugging will solve this.

The customer was running Windows Vista, 64-bit edition. On 64-bit versions of Windows XP and Windows Vista, the Control Panel shows only 64-bit control panels. The 32-bit control panels are off in a separate 32-bit control panel, which you can find by clicking the View 32-bit Control Panel Items icon.

The separation of 32-bit and 64-bit control panels is an unfortunate consequence of the rule that 64-bit processes cannot load 32-bit DLLs and vice versa. On 64-bit Windows, Explorer is a 64-bit process, which means that it can't load traditional 32-bit control panels. (Recall that control panel applications run as DLLs inside the host process.) Therefore, Explorer has to pass off the work of working with 32-bit control panel applications to a 32-bit alter ego process.

Fortunately, Windows 7 no longer segregates control panel applications by bitness: They all appear in the main Control Panel. This was done by running a puppet 32-bit copy of the Control Panel behind the scenes and making the puppet do the main Control panel's bidding whenever it needed to access information about 32-bit control panel applications.

"Hey, go enumerate the 32-bit control panel applications for me."

"Hey, go get the icon for this 32-bit control panel application."

"Hey, go launch this 32-bit control panel application."

"Hey, go make me a sandwich."

"Hey, give me a backrub."

Comments (35)
  1. MikeCaron says:

    Obligatory XKCD: http://xkcd.com/149/

    "Hey, go make me a sandwich."

    "No."

    "Sudo, hey, go make me a sandwich."

    "Okay!"

  2. tsrblke says:

    Obligatory XKCD reference: Sudo Make me a sandwhich.  (I assume you were already going there, but I must state teh obvious.)

  3. James says:

    Obligatory question; why does a 32-bit dll need to be loaded just to display shortcuts in the Control Panel? Surely the only point at which the dll needs to be loaded is when the user actually clicks on an item to launch the dialog process.

  4. Anders says:

    Are the sandwich and backrub functions going to be exposed in a public API in future versions of Windows?

  5. Dan Bugglin says:

    @James If the Control Panel API requires that the control panels be loaded when Control Panel is opened, they have to be loaded.  You don't know what black magic they're going to do behind the scenes that completely breaks when you don't load them as they expect.

    At the very least I think you have to load them to get localized names of the panels out of the DLL resources… not sure, I don't do much with DLL resources.

  6. Jules says:

    @James – they aren't shortcuts.  The way the control panel icons are found is by loading all the relevant DLLs (from a list in the registry), asking them how many icons they have and then asking for the details of each one in turn.

  7. Steve Smith says:

    Why does Control Panel expect the user to know whether the widget he/she is going to run to add a mail account is a 32 bit or a 64 bit widget?  

    "Hey, go make me a sandwich"

    "What's the latin name for wheat?"

    "I don't know"

    "Well, go boil your head!"

  8. Alex Grigoriev says:

    @James,

    If I remember correctly, the icon is returned by the DLL callback. Also, all DLLs have to be loaded. It makes that big PITA to uninstall the control panel provider DLL.

    The whole 64/32 bit control panel segregation debacle is just another case of Vista half-assedness. W7 FTW.

  9. Bob says:

    @James: Because the CPlApplet interface allows for dynamic enumeration of Control Panel items. Until you know what's available (remember that icons like "386 Enhanced" didn't appear unless you were actually running 3.x in 386Enh mode), you don't know what icons to load. And since developers would have been quite annoyed if their simple message-based Control Panel applets from 3.1x had to become COM Explorer namespace extensions in 95, they kept the interface around.

  10. Don Reba says:

    @MikeCaron

    runas/user:Administrator Make me a sandwhich!

  11. Ivo says:

    I was bitten by this about a month ago. Had to search the internets for the solution. The whole thing begs the question – why does creating a new account in Outlook involve going to the Control Panel? There are many solutions that are more user-friendly:

    1) Let me create an account in Outlook itself – what's the big deal?

    2) When I try to add an account in Outlook, launch the Control Panel applet for me

    3) If there is simply no way to create a new account while Outlook.exe is running, make a shortcut "Create new account" in the start menu

    4) If the work absolutely has to be done by a 32-bit DLL, make a 64-bit wrapper for it in the Control Panel that can launch the real one with rundll32

  12. Vaidotas says:

    Hey but there is no 32-bit ODBC icon in Administration tools of Control panel in Windows 7 64-bit :).

    So the merge is only in Control panel?

  13. Yuhong Bao says:

    Ivo: You will have to complain to the Outlook team for all this. Office 2010 is 64-bit now anyway, though there is still a 32-bit version.

  14. Adam Rosenfield says:

    It's always bothered me that if I haven't opened the Control Panel in a while, it takes a significant amount of time (like 5-10 seconds at least) for Windows to enumerate all of the Control Panel icons, presumably because it's either loading all of the DLLs, or paging them in from disk if they were already loaded but paged out.  This is on XP; I don't know if the situation has improved on Vista or 7.

    I'm not sure how to solve this problem (other than redesigning the Control Panel from scratch, which isn't going to happen).  Maybe some sort of caching scheme where Windows remembers the icons from the last time you opened the Control Panel, and it displays that cached list immediately while it waits for the actual enumeration to complete behind the scenes?

  15. Yuhong Bao says:

    "Vista half-assedness. "

    It had existed from the beginning of 64-bit Windows on IA-64, I think

  16. Falcon says:

    A third-party file manager uses a similar trick – it's a 32-bit app, but uses an auxiliary 64-bit program to allow access to 64-bit shell extensions (it lists them in an "X64" submenu).

  17. Marquess says:

    I guess the separate 32-bit control panel folder came about due to a chain of unfortunate events. When it was introduced, only advanced users would be affected by it. When Vista came about, priorities shifted away and no one fixed it.

  18. Ivo says:

    Yuhong Bao: I know I should complain to the Office team, but I'm hoping they read Raymond's blog. It is an excellent resource for all Win32 developers :)

    I'm also afraid they will just say: "32-bit installers can't install 64-bit Control Panel items, go complain to the MSI team". The MSI team will say "The 64-bit shell doesn't let us access it from our 32-bit code, go complain to the Shell team". Back to square 1 :)

    BTW, the MSDN download page for Office says:

    Important: Microsoft strongly recommends the use of 32-bit (x86) versions of Office 2010, Project 2010, Visio 2010, and SharePoint Designer 2010 applications as the default option for all platforms.

  19. Angry user says:

    So MS is denying its users to see which Control Panel applets are native 64-bit and which are 32-bit? Also, what is this extremely evil non-sense decision about not allowing users to run the 32-bit version of Windows Explorer as a file manager or as the shell in 64-bit editions of Windows 7.? 64-bit editions of Windows Vista and Windows XP allowed executing the 32-bit shell/Windows Explorer and making it the default for compatibility with shell extensions. All my 32-bit only shell extensions, some of which used to work but development abandoned are incompatible with 64-bit versions of Windows 7. Another example of things working even in Vista but broken in 7. Give me back my money or give me back 32-bit shell in 64-bit Windows. Imagine if the IE team did the same EVIL and completely removed IE 32-bit from 64-bit Windows 7. SP1 sadly doesn't fix this, this is I guess by design. Moronic stupid evil design or some shell guys who screwed up plenty of other shell features too. Till RC, 32-bit shell worked, so clearly someone wanted to spoil the experience for RTM. MS owes at least a note of this change somewhere.

  20. Miral says:

    @Ivo: The control panel provides a subset of the UI in Outlook's own account management pages.  (At least for Outlook 2007.  It's possible that things are different for other versions, especially Express.)

    @Angry user: On Win7, the control panel shows "Mail (32-bit)", making it pretty obvious that it's a 32-bit control panel.  Not that standard users will care.  As Raymond said, W7 got it right.  Also: don't use abandoned or broken shell extensions.

  21. Simon says:

    And how did something like this get past any kind of interface design review? Splitting the control panel into two pieces based on something as user-meaningless as 32-bit vs 64-bit? Architecture might require they be segregated behind the scenes, but surely there's no excuse for exposing that split to the user?

  22. Ivo says:

    @Miral: From what I remember, it was impossible to add an Exchange account from inside Outlook. When I ran Outlook for the first time it asked me about my account and connected fine. Then a year later I switched companies and wanted to switch my account. I deleted the old one and tried to add the new one. I got a message that I have to go to the Control Panel and look for Mail. But just like the user in Raymond's story, it wasn't there!

    @Simon: Since it was fixed in Windows 7, I'm assuming the fix was deemed to be too expensive or unimportant to include in the Vista build. But I'm glad that the forces of good (and sanity) prevailed in the end :)

  23. chrismcb says:

    And this is why you don't let technology drive the design.

    Some dev or pm must have said "Explorer is a 64-bit process, which means that it can't load traditional 32-bit control panels." Except that it is possible, otherwise Win7 wouldn't be " running a puppet 32-bit copy of the Control Panel behind the scenes "

  24. benjamin says:

    Hasn't the 'Add Account' option been under Tools in Outlook since like OL2K?

    Also, Falcon's comment about the X64 menu finally explained this weird problem I've noticed in [3rd party file manager] not displaying the context menu for [popular open source compression program].

  25. Ivo says:

    benjamin: No, you can't add a new Exchange account from Outlook. When you try to do it you get a message:

    "A new Microsoft Exchange account cannot be manually configured while Outlook is running. To add a manually configured account, exit Outlook. In Control Panel, open Mail, and then click E-mail Accounts."

    You can add POP3, SMS or Hotmail accounts just fine.

  26. 640k says:

    Explorer already runs shell extensions in a separate process. Why this process (or an additional process) cannot be 32-bit is only because shell team is lazy. As control panel has shown, it's clearly possible to do.

    [Only certain shell extensions run in a separate process. Most shell extensions cannot be run in a separate process for compatibility reasons. -Raymond]
  27. Joshua says:

    Office 2010 is 64-bit now anyway.

    Yes, and I'm glad I prepared for it before it happened, so when it did happen I only had to go fix a bug in my preparedness.

    On a related note, it's freaky when you attach to process without source, see the disassembly, and immediately know what the problem is.

  28. Angry user says:

    @Miral, easy to give advice. Read clearly. I am not using broken or obsolete shell extensions, I was using perfectly working 32-bit shell extensions which were unmaintained nnd have not been updated for 64-bit but working well. Windows 7 64-bit broke all of these by not allowing a 32-bit Explorer and now I am forced to use 32-bit Windows 7 or 64-bit Vista.

    Also, do all 32-bit Control Panel icons indicate in the mixed Control Panel that they're 32-bit? I think not. I am not saying separate Control Panels are better but MS can easily have them included in the same namespace but under different group headers.

    Shell team, please fix both these in SP1 or Windows 8. You can't kill all 32-bit shell extensions, especially if future Windows is 64-bit only. That's plain evil and a massive inconvenience. Please note that.

  29. DriverDude says:

    Next thing you know, they'll be running a puppet 32-bit operating system in a VM behind the scenes and making the puppet do… oh, wait, that's been done.

    Seems like there isn't anything that can't be solved with an additional layer of indirection, shims, wrappers and/or virtual machines.

  30. @chrismcb: I don't understand your point.

    "Explorer is a 64-bit process, which means that it can't load traditional 32-bit control panels": well, this *is* true.

    "Except that it is possible": nope. 64 bit explorer *can't* load traditional 32-bit CPLs, in facts a *separate* 32 bit process has to be started, and it's *this* process that loads the legacy CPLs, doing to them what the 64 bit control panel tells him via IPC.

  31. Myria says:

    How do you report a WOW64 issue to Microsoft?  I ran into what I think is a bug: SHOpenFolderAndSelectItems doesn't highlight the target item when executed from WOW64.  It returns 0x80040155 (interface not registered) to 32-bit programs.  It opens the correct folder, but doesn't highlight the target item.  When recompiling for x86-64, it works fine.  This is on Win7 Professional x64 RTM LDR.  This error also occurs for a .NET example program if I use /platform:X86.

    By the way, regarding CommandLineToArgvW, it has another problem for people trying to use it: the created "argv" array does not have a null terminator; that is, the expected truth argv[argc] == NULL is not true and in fact reads past the end of argv.  The CommandLineToArgvW thread is locked to new comments already.

  32. Myria says:

    And on the subject of quickly-locked threads, /LARGEADDRESSAWARE actually does work on a 64-bit program; the linker just sets it by default.  If you do /LARGEADDRESSAWARE on an x64 program, it will only have access to the low 2 GB of address space even though it's a 64-bit program. =^_^=

  33. J says:

    @AU: Why should technical details place limitations on the presentation of something? Whether a Control Panel applet is 32- or 64-bit makes *absolutely no difference* for the vast majority of users (in fact, I would venture to say "for everyone other than you"). If you care so much about whether it's a 32- or 64-bit applet, go locate the associated file (it's really not hard to find) and check. The rest of us can get by without having to think about an utterly irrelevant (in this context) distinction every time we want to use something from the control panel.

  34. Neil says:

    Outlook 2003 on Windows XP actually gave you convenient access to the mail setup from the Start menu. Another thing that was broken by Vista?

  35. Neil says:

    Windows XP and Outlook 2003 conspired to give you easy access to Mail Setup from the Start menu.

    Sorry if this is a duplicate post but posts take so long to submit these days :-(

Comments are closed.