Control Panel Policy and the Missing Icon
A customer recently reported a rather peculiar problem. They were working on a roll out of Windows 7, and one of the policies they employed on their domain was the “Show only specified control panel applets” setting. As its name implies, this policy allows an administrator to specify the names of any Control Panel icons they want their users to see, and all others are not shown. This company chose to allow a few of the Control Panel items included with Windows as well as the Mail icon that is added when Microsoft Office (specifically Outlook) is installed, which allows users to configure their Outlook profiles.
The problem the customer noticed was that, with the policy was in place, the first time a user opened the Control Panel on a computer, all of the allowed icons appeared except for Mail. If the user closed Control Panel and reopened it, the icon suddenly appeared. In fact, from that point on, the Mail icon would appear for that user on that computer. However, if that user logged on to a different computer, or a different user logged in to the first user’s computer, the icon was missing until Control Panel was opened for a second time.
Figure 1: Policy setting on our test system
Figure 2: Result from first open
Figure 3: Result on subsequent opens (desired)
Control Panel isn’t something we get many cases on, so I had to figure out how it worked, and what would cause it to fail only the first time. One of the first things I discovered as I debugged the issue was that the Control Panel is actually loaded in two passes – a “fast” pass and a “slow” pass. This is done so icons we know will be loaded quickly can be displayed first so a user doesn’t get stuck with an empty window waiting for some of the slower icons to load. What makes an icon fast or slow? It turns out shell maintains a cache of Control Panel items, so it can display them quickly without having to query the actual item for its name, description, icon, etc. If we have to ask the item for its information, that will take longer, so it is loaded during the second, slow phase:
shell32!CControlPanelDataWorkItem::_LoadSlowData
shell32!CControlPanelDataWorkItem::DoWork
shell32!CFrameTask::InternalResumeRT
shell32!CRunnableTask::Run
shell32!CShellTask::TT_Run
shell32!CShellTaskThread::ThreadProc
shell32!CShellTaskThread::s_ThreadProc
shlwapi!ExecuteWorkItemThreadProc
ntdll!RtlpTpWorkCallback
ntdll!TppWorkerThread
kernel32!BaseThreadInitThunk
ntdll!__RtlUserThreadStart
ntdll!_RtlUserThreadStart
Luckily for these icons, they won’t stay relegated to slow loading status forever. During the slow loading phase, one of the things we do is add the item’s information to the Control Panel cache, so we can load it during the fast phase in the future.
shell32!CPLD_AddControlToReg
shell32!CControlPanelEnum::_NextNonCachedCpl
shell32!CControlPanelEnum::Next
shell32!CRegFolderEnum::Next
shell32!CControlPanelAppletList::_AddAppletsToCategories
shell32!CControlPanelAppletList::LoadSlowApplets
shell32!CControlPanelDataWorkItem::_LoadSlowData
shell32!CControlPanelDataWorkItem::DoWork
shell32!CFrameTask::InternalResumeRT
shell32!CRunnableTask::Run
shell32!CShellTask::TT_Run
shell32!CShellTaskThread::ThreadProc
shell32!CShellTaskThread::s_ThreadProc
shlwapi!ExecuteWorkItemThreadProc
ntdll!RtlpTpWorkCallback
ntdll!TppWorkerThread
kernel32!BaseThreadInitThunk
ntdll!__RtlUserThreadStart
ntdll!_RtlUserThreadStart
This explains why the item was being loaded on subsequent opens of Control Panel – the item was added to the user’s cache on the first run, so the next time, it was loaded during the fast pass:
shell32!CControlPanelEnum::_NextCachedCpl
shell32!CControlPanelEnum::Next
shell32!CRegFolderEnum::Next
shell32!CControlPanelAppletList::_AddAppletsToCategories
shell32!CControlPanelAppletList::EnsureLoaded
shell32!CControlPanelDataWorkItem::_LoadFastData
shell32!CControlPanelDataWorkItem::DoWork
shell32!CFrameTask::InternalResumeRT
shell32!CRunnableTask::Run
shell32!CShellTask::TT_Run
shell32!CShellTaskThread::ThreadProc
shell32!CShellTaskThread::s_ThreadProc
shlwapi!ExecuteWorkItemThreadProc
ntdll!RtlpTpWorkCallback
ntdll!TppWorkerThread
kernel32!BaseThreadInitThunk
ntdll!__RtlUserThreadStart
ntdll!_RtlUserThreadStart
But that only answers half the question – while we now know why the icon appears every other time, we still don’t know why it doesn’t show up the first time. To figure this out, I debugged a system with the “Show only specified control panel applets” policy applied and one without the policy set, both as they opened Control Panel for the first time, and compared where the return codes from the functions diverged.
Starting with CControlPanelEnum::_NextNonCachedCpl, in the non-working case, we can see that it returns 0:
0:003> bp shell32!CControlPanelEnum::_NextNonCachedCpl
0:003> g
Breakpoint 0 hit
eax=14c5fa8c ebx=14c5fa7c ecx=11224630 edx=00000000 esi=11224630 edi=14c5fa8c
eip=76977e11 esp=14c5f9b4 ebp=14c5f9c8 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
shell32!CControlPanelEnum::_NextNonCachedCpl:
76977e11 8bff mov edi,edi
0:020> k
ChildEBP RetAddr
14c5f9b0 76977dff shell32!CControlPanelEnum::_NextNonCachedCpl
14c5f9c8 768a854d shell32!CControlPanelEnum::Next+0x5a
14c5fa18 769710d2 shell32!CRegFolderEnum::Next+0x22e
14c5fa94 769783e7 shell32!CControlPanelAppletList::_AddAppletsToCategories+0x35
14c5fac4 76978353 shell32!CControlPanelAppletList::LoadSlowApplets+0x68
14c5faec 76974db4 shell32!CControlPanelDataWorkItem::_LoadSlowData+0x2e
14c5fb00 769e06ad shell32!CControlPanelDataWorkItem::DoWork+0x4b
14c5fb18 768d83a6 shell32!CFrameTask::InternalResumeRT+0x14
14c5fb38 7691639b shell32!CRunnableTask::Run+0xce
14c5fb54 76918c1f shell32!CShellTask::TT_Run+0x167
14c5fb9c 76918d53 shell32!CShellTaskThread::ThreadProc+0xa3
14c5fba4 760cb2b1 shell32!CShellTaskThread::s_ThreadProc+0x1b
14c5fbb4 77c8d877 shlwapi!ExecuteWorkItemThreadProc+0xe
14c5fc28 77c90842 ntdll!RtlpTpWorkCallback+0x11d
14c5fd80 00000000 ntdll!TppWorkerThread+0x572
0:020> gu <-- This steps out to the instruction after the call to CControlPanelEnum::_NextNonCachedCpl in CControlPanelEnum::Next.
ModLoad: 35c70000 35c8b000 c:\progra~1\common~1\system\msmapi\1033\mlcfg32.cpl
eax=00000000 ebx=14c5fa7c ecx=bea347f1 edx=006d2904 esi=11224630 edi=14c5fa8c
eip=76977dff esp=14c5f9bc ebp=14c5f9c8 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
shell32!CControlPanelEnum::Next+0x5a:
76977dff 84c0 test al,al
But on the machine without the policy set, it returns 1:
eax=0c83fc34 ebx=0c83fc24 ecx=04ab1060 edx=00000000 esi=04ab1060 edi=0c83fc34
eip=76977e11 esp=0c83fb5c ebp=0c83fb70 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
shell32!CControlPanelEnum::_NextNonCachedCpl:
76977e11 8bff mov edi,edi
0:012> k
ChildEBP RetAddr
0c83fb58 76977dff shell32!CControlPanelEnum::_NextNonCachedCpl
0c83fb70 768a854d shell32!CControlPanelEnum::Next+0x5a
0c83fbc0 769710d2 shell32!CRegFolderEnum::Next+0x22e
0c83fc3c 769783e7 shell32!CControlPanelAppletList::_AddAppletsToCategories+0x35
0c83fc6c 76978353 shell32!CControlPanelAppletList::LoadSlowApplets+0x68
0c83fc94 76974db4 shell32!CControlPanelDataWorkItem::_LoadSlowData+0x2e
0c83fca8 769e06ad shell32!CControlPanelDataWorkItem::DoWork+0x4b
0c83fcc0 768d83a6 shell32!CFrameTask::InternalResumeRT+0x14
0c83fce0 7691639b shell32!CRunnableTask::Run+0xce
0c83fcfc 76918c1f shell32!CShellTask::TT_Run+0x167
0c83fd44 76918d53 shell32!CShellTaskThread::ThreadProc+0xa3
0c83fd4c 760cb2b1 shell32!CShellTaskThread::s_ThreadProc+0x1b
0c83fd5c 77c8d877 shlwapi!ExecuteWorkItemThreadProc+0xe
0c83fdd0 77c90842 ntdll!RtlpTpWorkCallback+0x11d
0c83ff30 778b3c45 ntdll!TppWorkerThread+0x572
0c83ff3c 77cc37f5 kernel32!BaseThreadInitThunk+0xe
0c83ff7c 77cc37c8 ntdll!__RtlUserThreadStart+0x70
0c83ff94 00000000 ntdll!_RtlUserThreadStart+0x1b
0:012> gu
ModLoad: 35c70000 35c8b000 c:\progra~1\common~1\system\msmapi\1033\mlcfg32.cpl
eax=00000001 ebx=0c83fc24 ecx=bea347f1 edx=00002bba esi=04ab1060 edi=0c83fc34
eip=76977dff esp=0c83fb64 ebp=0c83fb70 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
shell32!CControlPanelEnum::Next+0x5a:
76977dff 84c0 test al,al
So we know something in this function is causing us to return FALSE in the failing case and TRUE in the working case. An easy way to see where the return result of function calls is the wt (watch trace) debugger command with the -oR switch to see the return values. I set the level (-l) to 1 so I’d only see functions directly called from CControlPanelEnum::_NextNonCachedCpl. Here were the results.
Failing case:
eax=14c5fa8c ebx=14c5fa7c ecx=11224630 edx=00000000 esi=11224630 edi=14c5fa8c
eip=76977e11 esp=14c5f9b4 ebp=14c5f9c8 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
shell32!CControlPanelEnum::_NextNonCachedCpl:
76977e11 8bff mov edi,edi
0:020> wt -oR -l 1
Tracing shell32!CControlPanelEnum::_NextNonCachedCpl to return address 76977dff
31 0 [ 0] shell32!CControlPanelEnum::_NextNonCachedCpl
10 0 [ 1] shell32!DSA_GetItemPtr
17 0 [ 1] comctl32!DSA_GetItemPtr eax = 1123aa78
48 27 [ 0] shell32!CControlPanelEnum::_NextNonCachedCpl
ModLoad: 35c70000 35c8b000 c:\progra~1\common~1\system\msmapi\1033\mlcfg32.cpl
34 0 [ 1] shell32!CPLD_InitModule eax = 1
55 61 [ 0] shell32!CControlPanelEnum::_NextNonCachedCpl
15 0 [ 1] shell32!CDPA_Base<RESULT_FOLDER_ITEM,CTContainer_PolicyUnOwned<RESULT_FOLDER_ITEM> >::AppendPtr eax = 0
59 76 [ 0] shell32!CControlPanelEnum::_NextNonCachedCpl
14 0 [ 1] shell32!CPL_AddModuleReference eax = 0
61 90 [ 0] shell32!CControlPanelEnum::_NextNonCachedCpl
21 0 [ 1] shell32!CPL_ReleaseModuleReference eax = 0
76 111 [ 0] shell32!CControlPanelEnum::_NextNonCachedCpl
128 0 [ 1] shell32!CPLD_AddControlToReg eax = 1
78 239 [ 0] shell32!CControlPanelEnum::_NextNonCachedCpl
12 0 [ 1] shell32!FindCPLModuleInList eax = c666998
84 251 [ 0] shell32!CControlPanelEnum::_NextNonCachedCpl
10 0 [ 1] shell32!DSA_GetItemPtr
17 0 [ 1] comctl32!DSA_GetItemPtr eax = c5e7410
91 278 [ 0] shell32!CControlPanelEnum::_NextNonCachedCpl
90 0 [ 1] shell32!CControlPanelEnum::_CanEnumerateApplet eax = 0
97 368 [ 0] shell32!CControlPanelEnum::_NextNonCachedCpl
21 0 [ 1] shell32!CPL_ReleaseModuleReference eax = 0
108 389 [ 0] shell32!CControlPanelEnum::_NextNonCachedCpl
143 0 [ 1] shell32!CPLD_FlushRegModules eax = 0
116 532 [ 0] shell32!CControlPanelEnum::_NextNonCachedCpl
3 0 [ 1] shell32!__security_check_cookie eax = 0
118 535 [ 0] shell32!CControlPanelEnum::_NextNonCachedCpl
Working case:
eax=0c83fc34 ebx=0c83fc24 ecx=04ab1060 edx=00000000 esi=04ab1060 edi=0c83fc34
eip=76977e11 esp=0c83fb5c ebp=0c83fb70 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
shell32!CControlPanelEnum::_NextNonCachedCpl:
76977e11 8bff mov edi,edi
0:012> wt -oR -l 1
Tracing shell32!CControlPanelEnum::_NextNonCachedCpl to return address 76977dff
31 0 [ 0] shell32!CControlPanelEnum::_NextNonCachedCpl
10 0 [ 1] shell32!DSA_GetItemPtr
17 0 [ 1] comctl32!DSA_GetItemPtr eax = 4a732c8
48 27 [ 0] shell32!CControlPanelEnum::_NextNonCachedCpl
ModLoad: 35c70000 35c8b000 c:\progra~1\common~1\system\msmapi\1033\mlcfg32.cpl
34 0 [ 1] shell32!CPLD_InitModule eax = 1
55 61 [ 0] shell32!CControlPanelEnum::_NextNonCachedCpl
15 0 [ 1] shell32!CDPA_Base<RESULT_FOLDER_ITEM,CTContainer_PolicyUnOwned<RESULT_FOLDER_ITEM> >::AppendPtr eax = 0
59 76 [ 0] shell32!CControlPanelEnum::_NextNonCachedCpl
14 0 [ 1] shell32!CPL_AddModuleReference eax = 0
61 90 [ 0] shell32!CControlPanelEnum::_NextNonCachedCpl
21 0 [ 1] shell32!CPL_ReleaseModuleReference eax = 0
76 111 [ 0] shell32!CControlPanelEnum::_NextNonCachedCpl
128 0 [ 1] shell32!CPLD_AddControlToReg eax = 1
78 239 [ 0] shell32!CControlPanelEnum::_NextNonCachedCpl
12 0 [ 1] shell32!FindCPLModuleInList eax = 2ff3968
84 251 [ 0] shell32!CControlPanelEnum::_NextNonCachedCpl
10 0 [ 1] shell32!DSA_GetItemPtr
17 0 [ 1] comctl32!DSA_GetItemPtr eax = 4aa81a8
91 278 [ 0] shell32!CControlPanelEnum::_NextNonCachedCpl
111 0 [ 1] shell32!CControlPanelEnum::_CanEnumerateApplet eax = 1
104 389 [ 0] shell32!CControlPanelEnum::_NextNonCachedCpl
21 0 [ 1] shell32!CPL_ReleaseModuleReference eax = 0
112 410 [ 0] shell32!CControlPanelEnum::_NextNonCachedCpl
3 0 [ 1] shell32!__security_check_cookie eax = 1
114 413 [ 0] shell32!CControlPanelEnum::_NextNonCachedCpl
Here, we can see that the function CControlPanelEnum::_CanEnumerateApplet returns true in the working case, but false in the failing case. This is what is causing the return value from _NextNonCachedCpl to differ, which is ultimately what causes the icon to load/not load. So let’s take a look at _CanEnumerateApplet. Using wt inside this function showed something rather interesting:
Failing:
eax=0c5e7410 ebx=769298fd ecx=11224630 edx=00000000 esi=11224630 edi=0c666998
eip=7693a72f esp=14c5f980 ebp=14c5f9b0 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
shell32!CControlPanelEnum::_CanEnumerateApplet:
7693a72f 8bff mov edi,edi
0:020> wt -oR -l 1
Tracing shell32!CControlPanelEnum::_CanEnumerateApplet to return address 7693a68e
27 0 [ 0] shell32!CControlPanelEnum::_CanEnumerateApplet
737 0 [ 1] shlwapi!PathFindFileNameW eax = c6669f8
40 737 [ 0] shell32!CControlPanelEnum::_CanEnumerateApplet
59 0 [ 1] shell32!IDControlCreate eax = 0
44 796 [ 0] shell32!CControlPanelEnum::_CanEnumerateApplet
43 0 [ 1] shlwapi!SHWindowsPolicy eax = 1
53 839 [ 0] shell32!CControlPanelEnum::_CanEnumerateApplet
2 0 [ 1] shell32!CRegFolder::QueryInterface
5 0 [ 1] shell32!CKnownFoldersFolder::QueryInterface
12 0 [ 1] shell32!CAggregatedUnknown::QueryInterface eax = 0
71 858 [ 0] shell32!CControlPanelEnum::_CanEnumerateApplet
48 0 [ 1] shell32!CRegFolder::GetDetailsEx eax = ffffffff`80070002
77 906 [ 0] shell32!CControlPanelEnum::_CanEnumerateApplet
24 0 [ 1] shell32!CRegFolder::Release eax = 3
79 930 [ 0] shell32!CControlPanelEnum::_CanEnumerateApplet
6 0 [ 1] shell32!ATL::CComVariant::Clear eax = 0
88 936 [ 0] shell32!CControlPanelEnum::_CanEnumerateApplet
3 0 [ 1] shell32!__security_check_cookie eax = 0
90 939 [ 0] shell32!CControlPanelEnum::_CanEnumerateApplet
Working:
0:012> wt -oR -l 1
Tracing shell32!CControlPanelEnum::_CanEnumerateApplet to return address 7693a68e
27 0 [ 0] shell32!CControlPanelEnum::_CanEnumerateApplet
737 0 [ 1] shlwapi!PathFindFileNameW eax = 2ff39c8
40 737 [ 0] shell32!CControlPanelEnum::_CanEnumerateApplet
59 0 [ 1] shell32!IDControlCreate eax = 0
44 796 [ 0] shell32!CControlPanelEnum::_CanEnumerateApplet
43 0 [ 1] shlwapi!SHWindowsPolicy eax = 1
53 839 [ 0] shell32!CControlPanelEnum::_CanEnumerateApplet
2 0 [ 1] shell32!CRegFolder::QueryInterface
5 0 [ 1] shell32!CKnownFoldersFolder::QueryInterface
12 0 [ 1] shell32!CAggregatedUnknown::QueryInterface eax = 0
71 858 [ 0] shell32!CControlPanelEnum::_CanEnumerateApplet
48 0 [ 1] shell32!CRegFolder::GetDetailsEx eax = 0
77 906 [ 0] shell32!CControlPanelEnum::_CanEnumerateApplet
28 0 [ 1] shell32!CPL_DoesPolicyAllow eax = 1
82 934 [ 0] shell32!CControlPanelEnum::_CanEnumerateApplet
24 0 [ 1] shell32!CRegFolder::Release eax = 3
84 958 [ 0] shell32!CControlPanelEnum::_CanEnumerateApplet
6 0 [ 1] shell32!ATL::CComVariant::Clear eax = 0
98 964 [ 0] shell32!CControlPanelEnum::_CanEnumerateApplet
358 0 [ 1] shell32!CControlPanelFolder::GetCustomAttributes eax = 0
109 1322 [ 0] shell32!CControlPanelEnum::_CanEnumerateApplet
3 0 [ 1] shell32!__security_check_cookie eax = 1
111 1325 [ 0] shell32!CControlPanelEnum::_CanEnumerateApplet
Looking at the two, we can see that they both call GetDetailsEx, but in the failing case we seem to get an error result: 80070002, and in the working case we get 0, and then proceed to call CPL_DoesPolicyAllow. CPL_DoesPolicyAllow is not called on the machine with the policy applied. A quick code review of CPL_DoesPolicyAllow showed that this function checks if a policy prevents or allows an item from being displayed. So if we can just get to that function, the icon will load. Now we need to know why GetDetailsEx fails, preventing us from calling CPL_DoesPolicyAllow. If we look up the error code, it is pretty generic:
0:020> !error 80070002
Error code: (HRESULT) 0x80070002 (2147942402) - The system cannot find the file specified.
Next I stepped through and into GetDetailsEx. I’ll save you the tedious steps and output, since the procedure is similar to what I’ve already shown above. Anyway, I was able to trace the error 2 as being returned by a call to the registry a few functions deep into GetDetailsEx:
kernel32!RegOpenKeyExW
shell32!CControlPanelFolder::_GetExtPropRegKey
shell32!CControlPanelFolder::_InitExtPropRegValNameCache
shell32!CControlPanelFolder::_PropertyFromPidl
shell32!CControlPanelFolder::GetDetailsEx
shell32!CRegFolder::GetDetailsEx
shell32!CControlPanelEnum::_CanEnumerateApplet
shell32!CControlPanelEnum::_NextNonCachedCpl
This is good news, because it means we can find out what we’re looking for that we aren’t finding. First I stepped out to get back to CControlPanelFolder::_InitExtPropRegValNameCache. Sure enough, eax was 2, which is our ‘cannot find the file’ error.
0:020> gu
eax=00000002 ebx=00000000 ecx=778ac2da edx=00000002 esi=14c5eff0 edi=00000000
eip=76975ead esp=14c5ed40 ebp=14c5efc4 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
shell32!CControlPanelFolder::_GetExtPropRegKey+0xb1:
76975ead 50 push eax
0:020> !error 2
Error code: (Win32) 0x2 (2) - The system cannot find the file specified
Since we know that RegOpenKeyEx takes the subkey it is looking for as the second parameter, let’s look back at the assembly before the call to see what we passed in:
0:020> ub @eip
shell32!CControlPanelFolder::_GetExtPropRegKey+0x98:
76975e94 7c1f jl shell32!CControlPanelFolder::_GetExtPropRegKey+0xb9 (76975eb5)
76975e96 56 push esi
76975e97 6a01 push 1
76975e99 53 push ebx
76975e9a 8d8590fdffff lea eax,[ebp-270h]
76975ea0 50 push eax
76975ea1 ffb588fdffff push dword ptr [ebp-278h]
76975ea7 ff15a0128776 call dword ptr [shell32!_imp__RegOpenKeyExW (768712a0)]
Remember that function parameters are passed in in reverse order, so the second parameter is the second to last value passed to the function. In this case, we can see that it was stored in eax. Of course, eax has been overwritten by our return value of 2, but we can see that just before pushing eax, we get the value from ebp-0x270. Dumping that out as a Unicode string, we get the key we were looking for:
0:020> du @ebp-270h
14c5ed54 "Software\Microsoft\Windows\Curre"
14c5ed94 "ntVersion\Control Panel\Extended"
14c5edd4 " Properties\System.ApplicationNa"
14c5ee14 "me"
The first parameter is the root key, which was:
0:020> dc @ebp-278h L1
14c5ed4c 80000002
We can look up this value in the Windows SDK header files and see that it is for HKLM:
#define HKEY_LOCAL_MACHINE (( HKEY ) (ULONG_PTR)((LONG)0x80000002) )
Aha! So now we know we were trying to access “HKLM\ Software\Microsoft\Windows\CurrentVersion\Control Panel\Extended
Properties\System.ApplicationName” which didn’t exist, so we were unable to proceed with loading the icon.
What’s that key for, you ask? MSDN tells us that it is used to store the Canonical Name of the Control Panel item. Canonical Names were added to the Control Panel in Windows Vista as a better way to organize and name the items in the Control Panel. By convention, the canonical name of “Mail” is “Microsoft.Office.Outlook.Profiles.” Because the “Show only specified control panel applets” policy can now accept either the legacy name (“Mail”) or the canonical name, we are checking the registry for this string. Since the key is not present, GetDetailsEx cannot determine the canonical name, and the icon does not load.
As a test, I created the key HKLM\ Software\Microsoft\Windows\CurrentVersion\Control Panel\Extended
Properties\System.ApplicationName and added a REG_SZ to it with a name of the file location of the Mail CPL file ("C:\Program Files\Common Files\SYSTEM\MSMAPI\1033\MLCFG32.CPL") and a value of "Microsoft.Office.Outlook.Profiles". Sure enough, the icon loads up on the first try for new users.
While new Control Panel items should implement a canonical name, that doesn’t work for existing CPLs, like Mail from Outlook 2003. Since the canonical name isn’t actually required (CPL_DoesPolicyAllow works with both name formats), we’re following up with the development team to allow CPL_DoesPolicyAllow to be called even if a canonical name is not found.
-Matt Burrough