REGDB_E_CLASSNOTREG when using MsgPack Serializer after application pool recycling

[MarcDrexler]

We have a WCF service application hosted in IIS, which uses MsgPack for serialization in Redis.
Every time IIS recycles the application pool after 20 minutes of inactivity, we get the following exception when calling MsgPack for deserialization:

The type initializer for 'MsgPack.Serialization.EmittingSerializers.SerializationMethodGeneratorManager' threw an exception. System.TypeInitializationException: The type initializer for 'MsgPack.Serialization.EmittingSerializers.SerializationMethodGeneratorManager' threw an exception. ---> System.Runtime.InteropServices.COMException: Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))
   at System.Reflection.Emit.AssemblyBuilder.DefineDynamicModule(RuntimeAssembly containingAssembly, Boolean emitSymbolInfo, String name, String filename, StackCrawlMarkHandle stackMark, IntPtr& pInternalSymWriter, ObjectHandleOnStack retModule, Boolean fIsTransient, Int32& tkFile)
   at System.Reflection.Emit.AssemblyBuilder.DefineDynamicModule(RuntimeAssembly containingAssembly, Boolean emitSymbolInfo, String name, String filename, StackCrawlMark& stackMark, IntPtr& pInternalSymWriter, Boolean fIsTransient, Int32& tkFile)
   at System.Reflection.Emit.AssemblyBuilder.DefineDynamicModuleInternalNoLock(String name, String fileName, Boolean emitSymbolInfo, StackCrawlMark& stackMark)
   at System.Reflection.Emit.AssemblyBuilder.DefineDynamicModuleInternal(String name, String fileName, Boolean emitSymbolInfo, StackCrawlMark& stackMark)
   at System.Reflection.Emit.AssemblyBuilder.DefineDynamicModule(String name, String fileName, Boolean emitSymbolInfo)
   at MsgPack.Serialization.EmittingSerializers.SerializationMethodGeneratorManager..ctor(Boolean isDebuggable, Boolean isCollectable, AssemblyBuilder assemblyBuilder)
   at MsgPack.Serialization.EmittingSerializers.SerializationMethodGeneratorManager.Create(Boolean isDebuggable, Boolean isCollectable, AssemblyBuilder assemblyBuilder)
   at MsgPack.Serialization.EmittingSerializers.SerializationMethodGeneratorManager..cctor()
   --- End of inner exception stack trace ---
   at MsgPack.Serialization.EmittingSerializers.SerializationMethodGeneratorManager.Get(SerializationMethodGeneratorOption option)
   at MsgPack.Serialization.EmittingSerializers.AssemblyBuilderSerializerBuilder.<>c__DisplayClass63_0.<CreateCodeGenerationContextForSerializerCreation>b__1()
   at MsgPack.Serialization.EmittingSerializers.AssemblyBuilderEmittingContext.get_Emitter()
   at MsgPack.Serialization.EmittingSerializers.AssemblyBuilderEmittingContext.BeginMethodOverride(String name)
   at MsgPack.Serialization.AbstractSerializers.SerializerBuilder`2.BuildObjectPackTo(TContext context, SerializationTarget targetInfo, Boolean isAsync)
   at MsgPack.Serialization.AbstractSerializers.SerializerBuilder`2.BuildObjectSerializer(TContext context)
   at MsgPack.Serialization.AbstractSerializers.SerializerBuilder`2.BuildSerializer(TContext context, Type concreteType, PolymorphismSchema schema, SerializationTarget& targetInfo)
   at MsgPack.Serialization.AbstractSerializers.SerializerBuilder`2.BuildSerializerInstance(SerializationContext context, Type concreteType, PolymorphismSchema schema)
   at MsgPack.Serialization.MessagePackSerializer.CreateInternal[T](SerializationContext context, PolymorphismSchema schema)
   at MsgPack.Serialization.SerializationContext.GetSerializer[T](Object providerParameter)

When I recycle the application pool manually, the problem disappears and everything is working fine. Until an automatic recycle event occurs, the problem is back.

I already force all assemblies to be loaded into the AppDomain immediately after application start with this code:

var assemblies = BuildManager.GetReferencedAssemblies().Cast<Assembly>();

Does anybody know about this behaviour?

[yfakariya]

It looks .net framework runtime issue...
This issue may be related for you microsoft/dotnet#811

[MarcDrexler]

Thanks for the tip.
I have not installed the July 2018 .Net Framework Update which is causing similar issues.
However I will install the latest August 2018 Update mentioned here, and will let you know if my problem has been resolved.

[MarcDrexler]

The problem still persists. The system is a windows server 2016 with latest updates installed.
Any ideas how to further troubleshoot this issue? I really don’t want to use another serializer as a workaround :-/

[jc-m7t]

We are seeing the same error intermittently and seemingly randomly in an asp.net application running under IIS. A restart of IIS typically resolves the issue.

The type initializer for 'MsgPack.Serialization.EmittingSerializers.SerializationMethodGeneratorManager' threw an exception. Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))

Has there been any progress on this issue?

[MarcDrexler]

Sorry, no progress from my side. I just couldn‘t find the Problem... I gave up and we switched to another serializer to continue with our project 😕

[MarcDrexler]

Maybe this is a useful information:
We were using the MsgPack Serializer within a static class...

[yfakariya]

Thank you for giving information continuously for this issue. But I don't have effective idea to detect the cause of this issue over years. Sorry for unavailability.

I have some hypothesis that it is caused by out-of-memory in loader heap (or related runtime's native heap). I think it is caused by cache-miss of the serializer... Could you give me all types to pass SerializationContext.GetSerializer?

[edenbd36]

Any update on this one?
It happens from time to time until I recycle the service.

[yfakariya]

@edenbd36

No. I don't find the cause and I never see this kind of error. But it is interesting that it happens from time to time in your environment. So, I want to ask you:

1. Could you tell me your environment?
   • MsgPack for CLI version (nuget package version)
   • .NET Framework or .NET Core runtime version
   • Kind of your service process's user (e.g. AppPoolIdentity, Network Service, dedicated user, etc.)
   • Rough probability
2. Could you give me minimal reproducable code?
3. Could you test preview library it MAY be fixed the problem to verify the issue is really resolved?

I guess you fail to find the COM object of symbol writer of dynamically generated module which will hold serializer types. But I cannot test my hypothesis because I never face this kind problem...