You are viewing limited content. For full access, please sign in.

Question

Question

The type initializer for 'System.ServiceModel.Channels.Msmq' threw an exception.

asked on May 27, 2015

If you don't have Message Queueing installed on the computer where you are running your LF WF SDK code, you will get this error "The type initializer for 'System.ServiceModel.Channels.Msmq' threw an exception." at workflow.StartWorkflow (....) function....

So make sure that you have msmq installed at the system running your code.

3 0

Replies

replied on May 27, 2015

This is just to help those who might run into this issue, as I wasn't able to find an exact solution for this issue over here at answers website (not sure if I might have missed it in someone's post).

0 0
replied on May 27, 2015

I'm not sure what you mean about "the computer where you are running your LF WF SDK code". Windows Message Queuing is a pre-requisite on the Workflow Server.

0 0
replied on February 6, 2018

hey guys, any idea what causes this error when Message Queue is actually installed on the WF server? We do have it installed with WF on the same machine, but we see this error in the WF Admin Console under monitoring. We had to restart the Message Queue and WF + Subscriber services to resolve issue.

0 0
replied on February 6, 2018

It would depend on what the actual exception is.

0 0
replied on February 6, 2018

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

0 0
replied on August 27, 2018

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.

1 0
replied on August 27, 2018

Thanks for the update Chad. Good information.

0 0
replied on August 28, 2018

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

0 0
replied on August 29, 2018 Show version history

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.

1 0
replied on August 30, 2018

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.

0 0
replied on August 30, 2018

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?

0 0
replied on August 31, 2018

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.

0 0
replied on September 17, 2018

Hi There,

 

i am experiencing an issue where the message "The type initializer for 'System.ServiceModel.Channels.Msmq' threw an exception." is displayed at an invoke Workflow step.

 

Please let me know if there are any known fixes or if I should contact Laserfiche Support?

0 0
replied on February 25

Thank you.  This is exactly what I needed.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.