LoadBehaviour and ClickToRun

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

LoadBehaviour and ClickToRun
Add-in being disabled and users cannot re-enable 
Subscribe
Tim Kempster




Posts: 43
Joined: 2015-01-08
Dear Support

We have a Word Add-in that is suffering from being periodically disabled by Word. This can happen if the add-in does not respond quickly when used or if there is a host application crash while the add-in is on the stack. It's also possible if the add-in is slow loading.

This is a common problem with COM add-ins in Word and other office applications it seems. It seems that when it happens a user is prompted next time they run Word with a dialog box saying

"Word is running into problems with the 'ADD-IN NAME' add-in. If this keeps happening, disable the add-in and check for available updates. Do you want to disable now?"

If the user clicks Yes (as many do) the add-in is disabled.

The user can re-enable the add-in using File->options->add-ins Select "Disabled Items" from the drop down and find the add-in and enable it followed by selecting "COM Add-Ins" from the dropdown and checking the add-in if not checked.

However in some situations although the add-in is enabled again it does not set the load behaviour in the registry to 3 but instead just loads it in that session only. When the host application is restarted it is gone again.

A work around is to update the load behaviour to 3 using code in our add-in each time it loads by setting it in the key

HKCU\Software\Microsoft\Office\Word\Addins\[ADD-IN-NAME] {LoadBehaviour} DWORD=3

In this way if the user does manage to get the add-in back, using the steps above, it will set itself to load on start up.

This all works fine but there is yet another problem when the install of the host application is Click to Run e.g. Office 365. In this case when the add-in is re-enabled the registry entry in

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Wow6432Node\Microsoft\Office\Word\AddIns\[ADD-IN-NAME]

is set with {LoadBehaviour} DWORD=0

This is the virtualization registry entry for C2R. There seems to be no way to access this registry entry from within the add-in so the work around described above is not possible. Can Support help me????

The only way in the case of C2R to get the add-in back is to remove it and re-add it from the File->options->add-ins Select "COM Add-ins". This requires the users making a note of the path to adxloader.dll and it isn't a simple operation for many of them.

Also I've read for Office 16.0 versions or later there is a DoNotDisableAddinList registry hive to make sure add-ins are not disabled but this only applies for Outlook and not Word. Is this true? I can't get it to have an effect so my tests seem to confirm it does not work for Word.

My add-in is deployed via a setup.exe (click twice) and is deployed for all users. Perhaps this is the problem and it might not happen if I deployed for single users only. I have it deployed for all users as some of my users are on a Terminal Server so I want to install once on the server and have all users pick up the add-in. Would the solution perhaps be to move to a single user deployment rather than a machine level deployment.

Any help with this issue would be greatly appreciated as it is reeking havoc with our user base which is over 20,000 users.

I'm pretty desperate to get this fixed and I'm sure other Add-in Express users have had the same issues.
Posted 28 Jul, 2019 09:38:53 Top
Andrei Smolin


Add-in Express team


Posts: 16312
Joined: 2006-05-11
Hello Tim,

Tim Kempster writes:
"Word is running into problems with the 'ADD-IN NAME' add-in. If this keeps happening, disable the add-in and check for available updates. Do you want to disable now?"

If the user clicks Yes (as many do) the add-in is disabled.


In order no to crash the host applicaiton, all your code should be wrapped in try/catch blocks. Also, if you use threads, their code should be wrapped in a try/catch first of all. Secondly, their code should not invoke any Office object model. That is, it is okay to use a thread to calculate something, to get some data from the web, etc; it isn't okay to use the Word object model to scan a document.

Also, make sure you don't use DoEvents. Using it is like opening a door to any sort of disaster. Find my comment on using DoEvents at https://www.add-in-express.com/forum/read.php?FID=5&TID=14850. Sorry for putting a link instead of reproducing the comment here: the forum software doesn't let me do this; I believe, we will fix this issue today.

Regards from Belarus (GMT+3),

Andrei Smolin
Add-in Express Team Leader
Posted 29 Jul, 2019 01:38:42 Top
Tim Kempster




Posts: 43
Joined: 2015-01-08
Hi Andrei,

All our code is already wrapped in try,catch blocks but unfortunately this is not enough to stop Word from flagging what it thinks is add-in problems. In fact if Word determines that he add-in is slow to respond it also can also mark the add-in as faulty and show the message to the user. You can produce this behaviour using a simple demo with a button that is slow to return when pressed.

Also there is some evidence to suggest that if the add-in code is on the stack when a crash or delay occurs (but is not responsible for the crash or delay) it can be victimized by Word.

Our code performs actions involving printing documents and these can be slow operations and so it can trigger this message.

We only use the main thread and have no multi-threaded operations.


After spending many hours on this problem I note that some people have proposed some solutions. One such solution is to remove certain registry entries as documented here https://ardamis.com/2011/05/05/programmatically-re-enabling-word-com-add-ins/

I have tried this method and it is effective but obviously it requires a new process (or maybe a thread) to be running to monitor creation of these entries and their removal if they are created by Word. Would it be possible to create some sort of extra add-in that monitors these entries and removes them if they happen? Is it possible to build this into the same DLL and have Word load it twice as two separate add-ins where one just monitors the other?

Any help at all would be very useful as we are under a lot of pressure right now from some big clients who have this problem.

Kind regards
Posted 29 Jul, 2019 03:52:31 Top
Andrei Smolin


Add-in Express team


Posts: 16312
Joined: 2006-05-11
Tim Kempster writes:
You can produce this behaviour using a simple demo with a button that is slow to return when pressed.


Are you saying that a Ribbon button showing a message box can produce this issue?

Tim Kempster writes:
if they are created by Word


I suppose those keys were set by an admin specifying some group policy. I suggest that you talk to them. Also, find more details about resiliency at https://support.microsoft.com/en-gb/help/2758876/add-ins-are-user-re-enabled-after-being-disabled-by-office-programs.

Tim Kempster writes:
Is it possible to build this into the same DLL and have Word load it twice as two separate add-ins where one just monitors the other?


This isn't possible.
Regards from Belarus (GMT+3),

Andrei Smolin
Add-in Express Team Leader
Posted 29 Jul, 2019 05:22:00 Top
Tim Kempster




Posts: 43
Joined: 2015-01-08
Are you saying that a Ribbon button showing a message box can produce this issue?


Well yes. What I'm saying is that if the add-in thread blocks via a modal window or a slow running action and the user gets fed up and closes down Word while this is happening say via task manager or reboots the machine etc. then I'm pretty certain the next time Word is opened it will prompt that user to disable the add-in. At this point all the problems start.

There is also evidence that an un-related crash can also cause this to happen if the add-in code was on the stack when it happened.

The link you sent was for Outlook and as far as I know the same functionality is not available in Word our pluin is for Word only.

I accept that there are actions you can undertake to stop some of the events which cause the add-in to be disabled but they don't seem to cover all possibilities. Users thus sometimes lose their add-ins and as far as I can tell cannot get them back without registry intervention in some cases.

Can you confirm this is the case or am I missing something?
Posted 29 Jul, 2019 05:32:47 Top
Andrei Smolin


Add-in Express team


Posts: 16312
Joined: 2006-05-11
Tim Kempster writes:
the user gets fed up and closes down Word


If this is a problem, you should talk to an admin: the user should not kill task at wish. Other than that, there's no way to deal with such a user.

Tim Kempster writes:
There is also evidence that an un-related crash can also cause this to happen if the add-in code was on the stack


This is expected: Office tries to prevent failing add-ins from being loaded.

Tim Kempster writes:
The link you sent was for Outlook


At the top of that page I find this string: "Applies to: Outlook 2016Excel 2016Word 2016 More". Still, I assume what you describe doesn't relate to this page since by "slow" you do not mean the actual add-in slowness but rather a reaction of an impatient user to a seeming slowness.

The need to deal with this stuff can be a result of default settings or this can be caused by settings specified by the admin. Deleting registry keys isn't something that you are expected to do: this should be made impossible by the admin; if it isn't, this may break something on that machine. You can create another add-in that monitors the real add-in and re-enables and loads it.

This was always the case: the user can disable your add-in by pressing the default button in this message box: "Word is running into problems with the 'ADD-IN NAME' add-in. If this keeps happening, disable the add-in and check for available updates. Do you want to disable now?" There never was a real solution to this.

Regards from Belarus (GMT+3),

Andrei Smolin
Add-in Express Team Leader
Posted 29 Jul, 2019 06:09:14 Top
Tim Kempster




Posts: 43
Joined: 2015-01-08
At the top of that page I find this string: "Applies to: Outlook 2016Excel 2016Word 2016 More". Still, I assume what you describe doesn't relate to this page since by "slow" you do not mean the actual add-in slowness but rather a reaction of an impatient user to a seeming slowness.


It may say that but it does only apply to Outlook. Try looking at the file menu in Word for example and see if you see the button that says "Slow and disabled add-ins" I don't think you'll see it there. I'd be very pleased to find out it does exist for Word but I'm pretty sure it doesn't. Can you please confirm?

You seem to be saying that we just have to live with the real-world cases where add-ins do get disabled for no programmatic reason but because users decide to try to close word when it is slow responding or the other cases I mentioned? It's also the case that when this does happen its not always easy for users to re-enable the add-in.

If you are saying this then I guess it is a bit of a shame because on the one had you can argue that users shouldn't do this or that their support staff should be able to help. However in the real-world users do do this and support staff are often not well equipped to deal with it.
Posted 29 Jul, 2019 06:22:32 Top
Andrei Smolin


Add-in Express team


Posts: 16312
Joined: 2006-05-11
Tim Kempster writes:
It may say that but it does only apply to Outlook.


I'm sorry for pointing you to that page. It was my reaction to your words "slow add-in". As explained in my previous message, I've understood that these words do NOT point to the scenario in which Office penalizes an add-in for being slow. Instead, these words refer to a scenario in which the user kills the application and this makes Office disable the add-in (as a consequence, in an indirect way).

Yes, Office makers have decided to solve issues with add-ins in this way. What I'm trying to do is to describe what *you* can or cannot do. As to the users and what they do, you should contact their admins or write an add-in that monitors the real add-in. The latter is an ugly solution (a non-solution actually) since the monitoring add-in is left non-monitored and there's a chance that Word marks it as responsible for a crash.

PS. Just a note on Office disabling *slow* add-ins as per that page on support.microsoft.com: I assume an administrator may enable this functionality for Word. Although I've never found out how to do this, everything suggests that this functionality is implemented in these Office applications.

Regards from Belarus (GMT+3),

Andrei Smolin
Add-in Express Team Leader
Posted 29 Jul, 2019 06:42:45 Top
Tim Kempster




Posts: 43
Joined: 2015-01-08
I assume an administrator may enable this functionality for Word.

I've not seen anywhere that this can be enabled.


For Word my understanding is

The user is prompted to disable when any of these situations occurs:-

1. The add-in is slow starting up. This is based on the median over the last five load times stored in the registry.
2. Word "crashes" or doesn't handle an exception when the add-in code is on the stack.
3. Word is forced closed via a reboot or force close in task manager when the add-in code is on the stack.

I've seen some people suggest the add-in can be disabled without even this prompt but I've not been able to reproduce this.

Once this occurs an entry is placed in HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Word\Resiliency\StartupItems which then at the next run of Winword.exe prompts the user to disable. If the user selects "Yes" to this prompt then an entry is put in

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Word\Resiliency\DisabledItems

and the add-in is not loaded.

If the user then goes to File->options->add-ins Select "Disabled Items" from the drop down and find the add-in and enable it THEN IMMEDIATELY restarts Word the add-in comes back. It is important that they do not try to reload the add-in via the "COM Add-ins" in the same drop down list. If they do then the add-in loads and it seems all is well BUT the Load Behviour (for some unknown reason) is changed to a value to not equal 3 and subsequent restarts of Word lose the add-in. There is no way I know of getting it back using user intervention and instead this requires a registry change.

Worth also noting that adding a registry entry in HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Word\Resiliency\DoNotDisableAddinList with the ClassID of the add-in as described for Outlook does not work in Word 2016 or Office 365. This may change I suppose.

I agree with you that a monitoring add-in is ugly and has it's own issues. I may look at spawning off an .exe process to do the job but it's certainly also ugly it also has the added side-effect of making all disabled add-ins come back to life as there is no way to identify which add-in has been disabled in the list!

Clearly the solution here is to support the DoNotDisableAddinList in Word as it is in Outlook. If you have a way to escalate this to Microsoft then I'd appreciate this. I have a big Legal user of our software that tried this but they were just told that the behaviour is as intended. I assume it is to stop add-in authors just force persisting their add-ins!

For completeness sake I think it is worth saying that to minimize the instances of this sequence of events it is a very good idea to catch all exceptions in add-in code inside try/catch blocks and to try to minimise add-in load time and prevent any long running add-in code which may cause users to try to force exit your addin.

I hope this post is useful documentation for others.
Posted 29 Jul, 2019 07:01:37 Top
Andrei Smolin


Add-in Express team


Posts: 16312
Joined: 2006-05-11
Hello Tim,

Thank you for sharing your findings!

Tim Kempster writes:
It is important that they do not try to reload the add-in via the "COM Add-ins" in the same drop down list. If they do then the add-in loads and it seems all is well BUT the Load Behviour (for some unknown reason) is changed to a value to not equal 3 and subsequent restarts of Word lose the add-in.


I didn't know these details.

Tim Kempster writes:
Worth also noting that adding a registry entry in HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Word\Resiliency\DoNotDisableAddinList with the ClassID of the add-in as described for Outlook does not work in Word 2016 or Office 365.


According to that page, HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\<application>\Resiliency\DoNotDisableAddinList is created after "you click Always enable this add-in".

No, I have no way to escalate this to Microsoft. Although I agree that they have turned their face to developers (compared with how it looks like 2-3 years ago), they don't want us to report to them. I assume they want us to use their official channels. However, we found such channels extremely slow. In addition, they do not produce a required result so often that we almost dropped using them. Now I periodically post our findings on the Office for developers forums (such as Word for developers at https://social.msdn.microsoft.com/Forums/en-US/home?forum=worddev) *hoping* that someone from them would read this. Recently, they contacted us on a major Excel issue; it turned out they didn't read the report on this issue I posted a year ago.

Tim Kempster writes:
I hope this post is useful documentation for others.


I strongly believe it is.

Regards from Belarus (GMT+3),

Andrei Smolin
Add-in Express Team Leader
Posted 30 Jul, 2019 01:34:53 Top