It would depend on what the actual exception is.

looks like i'll have to open a LF support ticket. the error log looks complex

It is caused by a conflict with Windows Update, which disables the Message Queuing service. It also dumps anything currently queued, which means your action history might be lost. The other problem is, even after the message queuing service comes back online, the subscriber will not show any events until you restart the Workflow service, not the subscriber service, but the workflow service.

I just had another situation where the OS was not rebooted after Windows Update. So the error log showed that the message queuing service is not available in the Connections Error log (it is in the <Message> at the bottom of this exception). That was on 8/26 @ 4:38 am. This morning the last entry in the Subscriber log was from 8/24, none of today's updates showed until I restart the Workflow Service.

So #1 Never allow users access to the system while a Windows Update is running, or your action history will be lost and your workflow states will be unrecoverable.

#2 Always reboot after a Windows Update.

Thanks for the update Chad. Good information.

@████████, what OS was it? Do you know which Windows updates were installed when you saw this happen?

I was under the impression that every Windows Update stops the Message Queue Service. I did a ton of research on this back in 2014 when it first came to my attention that workflows could be blind to certain actions. I have since seen it multiple times, where actions had taken place in Laserfiche, but are not listed in the subscriber log, hence the workflows can never return to their correct state. It only ever happens when the Messaging Queue Service is turned off, which is only when Windows Updates are running.

We have been coordinating to disable the Laserfiche Service during Windows Updates so it has been awhile since I have had it effect anything.

The situation where the subscriber goes into hibernation was just discovered this weekend. We had a customer with a Windows Update that ran extra long on Sunday, the Laserfiche Server was brought back online before the Update was complete and about 8 minutes later a request to access the Messaging Service was made, where it was logged that it was not available (in the details of the type intitializer error from the original post).

Monday we received reports that workflows were not running. I checked the logs and the last thing stated was the Messaging Service not available error, from 4:38am on Sunday morning. No other error. However the subscriber logs showed no actions having taken place since Friday, which was not true compared with the Audit Log.

I restarted the Subscriber Service, no change. I restarted the Workflow Service, all actions were recovered into the subscriber log and workflows all returned to their correct state.

Only actions that occur while the Message Service is actually stopped are lost permanently.

I think the server from this weekend was running Server 2012 R2, it had the full screen start menu.

Hm, that's interesting. I've only seen Windows updates remove MSMQ (and IIS) once on a machine in the fast update ring. We haven't seen any support cases and the latest post I can find about people complaining about it to Microsoft is from 2017. That said, though, Windows update stability record of late is kinda...iffy.

I'd be curious to take a look at the log files around the time this happened. I'd have expected a steady stream of messages about MSMQ not being available if the Subscriber was processing activity notifications.

I was on the server today and grabbed the error, communication, and subscriber logs. They still show the last errors as from 4:38am on Sunday when the service was not available. Can I send them to you directly somehow?

Please open a support case and attach them referencing this thread. If it's not too much trouble, getting the entire Logs folder would be better.