Security Manager leaves Outlook running in the Windows System Tray when built with Any CPU

Add-in Express™ Support Service
That's what is more important than anything else

Security Manager leaves Outlook running in the Windows System Tray when built with Any CPU
 
Chris Dewar-English




Posts: 11
Joined: 2013-04-22
When Outlook is not currently running, our .NET application creates a new instance of Outlook (using Activator.CreateInstance...), it send an email and shows the Outlook application icon in the Windows System Tray. Once the email has been sent (and all COM objects have been released) the icon goes grey briefly, then disappears and Outlook closes. This is the expected behaviour.

However when doing the same steps but also using the Security Manager to suppress warnings the Outlook application behaves differently depending on the build architecture:-

If the application is built using Any CPU architecture the Outlook icon stays in the system tray, Outlook never closes.
If the application is built using x86 (in my case Outlook 2016 32-bit, running on a 64-bit platform) Outlook exits as expected.
If the application is built using x64 the Outlook icon stays in the System Tray, Outlook never closes.

In all 3 cases it is the same code, just different build architectures, all using the Security Manager.

We would like to continue to deploy a single version of our application to our clients regardless of the OS and Outlook architecture using Any CPU. Any advice is greatly appreciated.
Posted 06 Jul, 2016 11:15:24 Top
Andrei Smolin


Add-in Express team


Posts: 18793
Joined: 2006-05-11
Hello Chris,

Please install the latest build of the .NET edition of the Outlook Security Manager; see https://www.add-in-express.com/downloads/osm.php. WHATSNEW.TXT for this build contains this line:

FIXED: Outlook 2016 did not close correctly (its process remained in memory) after disabling security warnings.

Please let me know if this fix works for you.


Andrei Smolin
Add-in Express Team Leader
Posted 07 Jul, 2016 06:21:08 Top
Chris Dewar-English




Posts: 11
Joined: 2013-04-22
Hi Adrei,

Thank you but I am already using the latest version of the Security Manager 8.1 (Feb 2016). We noticed that fix note before and it was one of the reasons we purchased the latest version prior to logging the issue.

Please note we have other PCs with Outlook 2013 that also exhibit the problem with Outlook failing to disconnect when using Any CPU architecture.
Posted 07 Jul, 2016 07:07:40 Top
Andrei Smolin


Add-in Express team


Posts: 18793
Joined: 2006-05-11
Chris,

Please make sure that you use secmand.dll and secmand64.dll from that build. Is it possible that secman DLLs from another Security Manager build are registered and this causes the issue?


Andrei Smolin
Add-in Express Team Leader
Posted 07 Jul, 2016 07:19:22 Top
Chris Dewar-English




Posts: 11
Joined: 2013-04-22
That's a good question. We always try to use the security manager without registering by using the DLLs directly and by calling SetDllDirectory, but just to be sure I have unregistered (regsvr32 /u...) and deleted all copies of secman.dll, secman64.dll and SecurityManager.2005.dll. Once deleted the only DLLs present are the ones in C:\Program Files (x86)\Add-in Express\Security Manager for Microsoft Outlook .NET

I have then copied those 3 DLLs into the application's bin\Debug folder. The application calls SetDllDirectory with that path. Then running the application with Any CPU - the Outlook process launches from a cold start, but does not exit.

Copying those 3 into the application's bin\x86\Debug and running as x86 (with the SetDllDirectory pointing to that path) and the Outlook process launches from a cold start, and then exits as expected.
Posted 07 Jul, 2016 08:05:33 Top
Andrei Smolin


Add-in Express team


Posts: 18793
Joined: 2006-05-11
Chris,

Do you call Outlook._Application.Quit() in this case? Does this call produce an exception? Does your antivirus produce any message related to this issue?


Andrei Smolin
Add-in Express Team Leader
Posted 07 Jul, 2016 08:34:35 Top
Andrei Smolin


Add-in Express team


Posts: 18793
Joined: 2006-05-11
Well, I don't seem to be able to reproduce the issue.

Could you please modify the code of the SendMai sample project so that the issue is reproducible? Please see the download item called Security Manager for Microsoft Outlook sample projects at https://www.add-in-express.com/downloads/osm.php.

This is the code fragment that I've added (see the three code lines before calling securityManager1.ConnectTo().

if (outlookApp != null)
{
    if (tbtnMode.Pushed)
    {
        string location = System.Reflection.Assembly.GetExecutingAssembly().CodeBase;
        string directoryPath = System.IO.Path.GetDirectoryName(location); // directory path
        SetDllDirectory(directoryPath);

        securityManager1.ConnectTo(outlookApp);
        securityManager1.DisableOOMWarnings = true;
    }
	try
	{
		newMail = outlookApp.CreateItem(Outlook.OlItemType.olMailItem) as Outlook.MailItem;


The declaration of that API function is:

        [DllImport("kernel32.dll", CharSet = CharSet.Unicode, SetLastError = true)]
        [return: MarshalAs(UnmanagedType.Bool)]
        static extern bool SetDllDirectory(string lpPathName);


I've got an exception once but I cannot reproduce it any longer:

************** Exception Text **************
System.Runtime.InteropServices.COMException (0x800706BE): The remote procedure call failed. (Exception from HRESULT: 0x800706BE)
at Outlook._Application.Quit()
at SendMail.Form1.toolBar1_ButtonClick(Object sender, ToolBarButtonClickEventArgs e) in D:\_Projects\_pub\_Samples\outlook-security-manager-samples\NET\C#.NET\SendMail\Form1.cs:line 365
===============================

You can send me the project to the support email address; see {Add-in Express installation folder}\readme.txt. In this case please make sure your email contains a link to this topic.


Andrei Smolin
Add-in Express Team Leader
Posted 07 Jul, 2016 08:56:17 Top
Chris Dewar-English




Posts: 11
Joined: 2013-04-22
Thank you Andrei.

I downloaded the sample and set it up as you requested. Initially I got an error: "There was a problem starting secman.dll. The specified module could not be found". But I was able to resolve this by using Location instead of Codebase on the first line. I presume this was necessary because Codebase prefixes file: to the path which SetDllDirectory does not support. I presume your test is working because the DLLs are registered?...

e.g.
string location = System.Reflection.Assembly.GetExecutingAssembly().Location;
string directoryPath = System.IO.Path.GetDirectoryName(location); // directory path
SetDllDirectory(directoryPath);

However once this fix is made I am still getting the original issue with Outlook not closing. I suspect I would not see the fault if my Windows "bitness" (64-bit) and my Outlook 2016 "bitness" (32-bit) were the same.

To answer your previous question. I do not cal Quit on Outlook. Just Marshal.ReleaseComObject(outlook). I see no anti-virus messages.

Regards,

Chris Dewar-English
Posted 07 Jul, 2016 09:40:20 Top
Andrei Smolin


Add-in Express team


Posts: 18793
Joined: 2006-05-11
Chris,

Am I right assuming the issue doesn't occur if you don't call SetDllDirectory?


Andrei Smolin
Add-in Express Team Leader
Posted 07 Jul, 2016 09:55:01 Top
Chris Dewar-English




Posts: 11
Joined: 2013-04-22
If I run the sample exe directly and without the call to SetDllDirectory I still get my original issue.

As a side-note: the reason we use SetDllDirectory is to ensure the path to the DLLs is correct (we can't register the DLLs because we don't want our client-base to require elevated permissions when installing our application). This has to happen because our application is sometimes launched via a parent process (a web browser) which may or may not have overridden the DLL search path. Child processes inherit the parent's DLL search path which may then cause the security manager DLLs to not be found (i.e. "There was a problem starting secman.dll. The specified module could not be found"). This can be reproduced on my PC when running the sample application via the Visual Studio Debugger. This is because the vshost.exe parent process to the running application overrides the DLL path due to a plugin I have installed for VS).
Posted 07 Jul, 2016 10:12:36 Top