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
 
Andrei Smolin


Add-in Express team


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

We are unable to reproduce the issue using the SendMail sample project built for the Any CPU platform. I suppose that some other Outlook add-ins or programs that automate Outlook may influence the issue. Could you please check if this is the case?

Regards from Belarus (GMT+3),

Andrei Smolin
Add-in Express Team Leader
Posted 08 Jul, 2016 04:13:36 Top
Chris Dewar-English




Posts: 11
Joined: 2013-04-22
The key factor I think is the disparity between my Windows architecture (x64) and Office (x86). Have you seen it working in with this exact same setup?
Posted 08 Jul, 2016 05:07:00 Top
Andrei Smolin


Add-in Express team


Posts: 14137
Joined: 2006-05-11
We have this setup exactly. What Windows version do you have? Outlook build?

Regards from Belarus (GMT+3),

Andrei Smolin
Add-in Express Team Leader
Posted 08 Jul, 2016 05:13:29 Top
Chris Dewar-English




Posts: 11
Joined: 2013-04-22
Hi. I am running Windows 10 Enterprise 64-bit and Outlook 2016 (16.0.6701.1029) 32-bit.

How does this particular mixture of architectures affect the launching of the secman DLLs anyway? Is secman64.dll being launched initially (based on my Windows OS architecture being 64-bit) but it is then handing over to the secman.dll (32-bit) because of my Outlook architecture?
Posted 08 Jul, 2016 05:32:56 Top
Andrei Smolin


Add-in Express team


Posts: 14137
Joined: 2006-05-11
I have Windows 7 64bit and Outlook 2016 16.0.7030.1012. You could try to update your Outlook; however, I don't believe this influences the issue. I don't think the Windows version used is involved either.

Chris Dewar-English writes:
Is secman64.dll being launched initially (based on my Windows OS architecture being 64-bit) but it is then handing over to the secman.dll (32-bit) because of my Outlook architecture?


Exactly.

Please confirm that *all* Outlook add-ins are turned off.

Regards from Belarus (GMT+3),

Andrei Smolin
Add-in Express Team Leader
Posted 08 Jul, 2016 05:42:15 Top
Chris Dewar-English




Posts: 11
Joined: 2013-04-22
I do have plugins running, but have now disabled them all as requested.

The sample has
if (canQuit) outlookApp.Quit();
and that flag is true when launching a new Outlook session. This means the application will close anyway (after showing a dialog "You have messaged in your Outbox waiting to be sent...").

If that line is commented out and I run the sample application without any Outlook plugins, I can still reproduce the problem. Note I am also able to reproduce the issue without any of the SetDllDirectory code that we added earlier.
Posted 08 Jul, 2016 06:25:57 Top
Andrei Smolin


Add-in Express team


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

If you uncomment that line and if you confirm closing Outlook when the dialog is shown, would the issue occur for you? For us, confirming closing Outlook in that dialog closes Outlook all right.

Regards from Belarus (GMT+3),

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




Posts: 11
Joined: 2013-04-22
Yes if I confirm closing when the dialog is shown, Outlook does indeed exit.

Have you managed to reproduce the issue without the Application.Quit()?
Posted 08 Jul, 2016 07:39:03 Top
Andrei Smolin


Add-in Express team


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

Chris Dewar-English writes:
Have you managed to reproduce the issue without the Application.Quit()?


Sort of.

This works as follows. secman creates a reference to Outlook and this prevents Outlook from quitting. When you close your application or when you call Outlook.Application.Quit(), secman releases this reference. This doesn't depend on bitness.

We regard the example as correct: it starts Outlook and closes it. Why would you need to let it run in the background?

Actually, this kind of problem starts after they modified their approach to reference counting in Outlook; their goal was to prevent Outlook closing slowly.

Regards from Belarus (GMT+3),

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




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

Why would you need to let it run in the background?


I don't want to leave Outlook running in the background. The normal behaviour without using the Security Manager is for Outlook to do its work and close down on its own (after launching from cold).

In light of this I don't think calling Outlook.Application.Quit() is necessary, especially considering the two choices it gives to the user are to "Exit without sending" or "Don't Exit" - neither of which are desirable.


When you close your application or when you call Outlook.Application.Quit(), secman releases this reference. This doesn't depend on bitness.


When using the Security Manager and setting my application's build configuration to x86 (instead of Any CPU) Outlook closes down as expected - no need to call Outlook.Application.Quit(). The build configuration bitness does seem to cause the Security Manager to behave differently.

Regards,

Chris Dewar-English
Posted 08 Jul, 2016 09:02:17 Top