0

Have a MAPI service provider that provides custom folder view in Outlook, works fine in Outlook 2010 64-bit. In Outlook 2013 64-bit and later it fails to open the folders with error Cannot expand the folder. No description is available for this error.

enter image description here

However if Outlook 2013+ is launched via a PowerShell script like below, the folders work:

 Add-type -Assembly "Microsoft.Office.Interop.Outlook" | out-null
 $olFolders = "Microsoft.Office.Interop.Outlook.olDefaultFolders" -as [type] 
 $outlook = New-Object -ComObject Outlook.Application
 $namespace = $outlook.GetNameSpace("MAPI")
 $folder = $namespace.GetDefaultFolder($olFolders::olFolderInbox)
 $folder.Display()

enter image description here

Currently I am doing an analysis of what is different using Process Monitor, Rohitab API Monitor and Windbg when Outlook is opened these ways.

However I am interested to know if anybody knows what is different between Outlook startup process when launched via shortcut vs automation that may impact MAPI service provider working correctly.

Malcolm McCaffery
  • 273
  • 3
  • 12

3 Answers3

0

The class olDefaultfolders in the Microsoft.office.interop.outlook namespace is to specify the folder type olFolderInbox for the current Microsoft Outlook profile, in addition, the only supported name space type “MAPI” of GetNameSpace method is functionally equivalent to the Session property.

According to your issue “can’t expand the folder” and your script which fixed the issue, it seems that something wrong happened on your folder type of Outlook client profile, and the script which you post is to specify the folder type and establish the session of the folders.

Ivan_Wang
  • 1,323
  • 1
  • 3
  • 4
0

Because the detailed description is not available for the error, it seems to be the closest thing to the truth. In addition, if you still encounter the issue, you could try recreating the Outlook profile of the problematic account in the Control Panel and then restart client to check whether the issue still exists. Hope it helpful to you. :)

Ivan_Wang
  • 1,323
  • 1
  • 3
  • 4
0

  • The DLL characteristics of Outlook.exe has changed between Outlook 2010 and Outlook 2013. Outlook 2010 has a value of 8040 which signifies the IMAGE_DLLCHARACTERISTICS_ DYNAMIC_BASE + IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE properties are set. However Outlook 2013 has a value of 8160 which includes the same properties as Outlook 2010 but in addition sets IMAGE_DLLCHARACTERISTICS_HIGH_ENTROPY_VA+IMAGE_DLLCHARACTERISTICS_ NX_COMPAT properties.

  • Normally when Outlook 2013 64-bit is launched, all DLLs are loaded with random image base. However in Outlook 2010 64-bit many DLLs are loaded with default image base of 0x180000000. When launching Outlook 2013 64-bit via COM automation many of this DLLs load with image base of 0x180000000 like Outlook 2010. However when launched via shortcut they are loaded with different image base each time. This can be confirmed by attaching WinDbg to Outlook.exe and using lmv command to output loaded modules, or a tool such as Process Explorer and setting View -> Show Lower Pane on and configuring View -> Lower Pane -> to DLLs then adding columns Image Base.

  • Checking the properties of Outlook.exe process using Process Explorer you can see the key difference on the image tab:

Outlook 2010

  • Data Execution Prevention (DEP) Status: Enabled (Permanent)

  • Address Space Load Randomization: Bottom-Up

  • Control Flow Guard: Disabled

  • Enterprise Context: N/A

Outlook 2013

  • Data Execution Prevention (DEP) Status: Enabled (Permanent)
  • Address Space Load Randomization: High-entropy, Bottom-Up, Force-Relocate
  • Control Flow Guard: Disabled
  • Enterprise Context: N/A

You can use a PE editing tool such as CFF Explorer to modify the DLL characteristics of an executable image. However by removing some of these options you will increase attack surface area vulnerabilities can take advantage of.

Malcolm McCaffery
  • 273
  • 3
  • 12