A strange error suddenly cropped up on our Dynamics CRM 2011 server - a specific plugin assembly can not be found when the plugin execution is triggered through a workflow process, with the error:
[Microsoft.Crm.ObjectModel: Microsoft.Crm.ObjectModel.SyncWorkflowExecutionPlugin]
[324f29aa-6082-ea11-80ee-005056837add: ]
Starting sync workflow 'workflow name', Id: 2d4f29aa-6082-ea11-80ee-005056837add
Sync workflow 'workflow name' terminated with error 'The type initializer for '<Module>' threw an exception.'
And exception stack trace ultimately leads to:
Inner Exception: <CrtImplementationDetails>.ModuleLoadException: The C++ module failed to load while attempting to initialize the default appdomain.
at <CrtImplementationDetails>.ThrowModuleLoadException(String errorMessage, Exception innerException)
at <CrtImplementationDetails>.LanguageSupport.Initialize(LanguageSupport* )
at .cctor()
Inner Exception: System.Runtime.Serialization.SerializationException: Unable to find assembly 'AssemblyName, Version=8.75.0.267, Culture=neutral, PublicKeyToken=4e4051c21cef725b'.
The assembly is present on the server, version, culture, and public key token all match. Oddly enough the plugin steps work fine when the execution is triggered directly through a create/update/etc request - it's only when the execution is triggered through a workflow that the error occurs. And by triggered through a workflow I don't mean running code activity from that assembly, I mean a situation like:
Entity is created
OnCreate plugin from Assembly1 runs without issues
Workflow runs that updates a related entity, triggering OnUpdate plugin from Assembly1 - ERROR
This issue cropped up initially after a server restart. Another restart fixed it temporarily, until two days later it started happening again. We've tried everything we can think of - updating the assembly, unregistering/re-registering it, restarting all services, restarting the server again. Does anyone have any idea what might be the cause of this and how to fix it?
We discovered the issue was caused by a Windows update that had been applied before the initial restart, which had installed .NET framework v4.8 on the server. Although the application was still using an older version, apparently just having v4.8 installed was enough to cause errors. Reverting back to an earlier .NET version fixed the problem.
I am not certain what is the exact technical reason for this - seems to be something related to App Domains (https://learn.microsoft.com/en-us/dotnet/api/system.appdomain?view=netframework-4.8). But if you encounter a similar issue, check your .NET framework version.
Related
My application randomly crashes on my target machines with an .net failure. In mscorelib.dll there seems to be a System.InvalidCastException.
The error occures in:
System.Threading._ThreadPoolWaitOrTimerCallback.PerformWaitOrTimerCallback(System.Object, Boolean)
and the reason is:
Unable to cast object of type 'System.Threading.ManualResetEvent' to type 'System.Threading._ThreadPoolWaitOrTimerCallback'.`
The Application runs multiple times on the target machine (win7 x64).
The Application is a x86 application.
There have never been issues before I was forced to compile the Application to the .net 4.6+ target framework. But I need to go up to at least 4.6 due to other dependencies now.
I thought it could be a issue with garbage collection and set <gcConcurrent enabled="false"/>. But this did not help.
I tried to debug the miniDumps with WinDbg. But I was not successful to find a way to track the Issue down to a specific line of code or a method in my code. I don't think it is a .net issue, but I have no clue how to find the corresponding line in my code.
Edit on request:
Former .net target framework: 4.5.1
The application crashes randomly, could be after more than 24h
I'm not able to figure out in which part of my code the application crashes
The same application runs independent parallel on the same machine. Sometimes randomly one or two instances crash.
I'm making a plugin loader for Unity game (Subnautica). The loading mechanism itself works fine but I want to load the assemblies into a separate app domain so I can unload them at runtime too.
However, calling AppDomain.CreateDomain(string) crashes Unity, leaving an error log with
Unknown caused an Access Violation (0xc0000005)
in module Unknown at 0033:049f7717.
...
Read from location 00000000 caused an access violation.
and the log the game produces with
0x0000000005048C6D ((<unknown>))
ERROR: SymGetSymFromAddr64, GetLastError: 'The specified module could not be found.'
ERROR: SymGetModuleInfo64, GetLastError: 'A dynamic link library (DLL) initialization routine failed.'
I have tried injecting the code that calls AppDomain.CreateDomain into the game's code directly and I tried injecting code that loads the dll that calls AppDomain.CreateDomain using Assembly.Load, both methods crash with the same message.
Unity version is 5.4.4f1, I'm on Windows 10 and the assembly that calls AppDomain.CreateDomain uses .net 3.5. This is the error.log created by Unity and the stack trace from output_log.txt created by Subnautica.
Does anyone have any idea what could be causing Unity to crash?
PS, I know with certainty that AppDomain.CreateDomain is causing the problem.
We have a workflow with several activities in a strong-named assembly. While the workflow is waiting for a user action, we update the assembly to a newer version. On the next step execution, workflow foundation suddenly says that it can no longer find the workflow instance. This is literally about the assembly version number. If we don't change the version number, it keeps working. The exception additional information is:
The execution of the InstancePersistenceCommand named {urn:schemas-microsoft-com:System.Activities.Persistence/command}LoadWorkflowByInstanceKey was interrupted by an error.
The fault code name is InstanceNotFound .
Has anyone encountered something like this?
For a while now, I have been having an issue with Team Foundation Server build/deploy process throwing the following error intermittently:
Unhandled Exception: System.TypeInitializationException: The type initializer for 'LibGit2Sharp.Core.NativeMethods' threw an exception. ---> System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
at LibGit2Sharp.Core.NativeMethods.git_threads_init()
at LibGit2Sharp.Core.NativeMethods.LibraryLifetimeObject..ctor()
at LibGit2Sharp.Core.NativeMethods..cctor()
--- End of inner exception stack trace ---
at LibGit2Sharp.Core.NativeMethods.RemoveHandle()
at LibGit2Sharp.Core.NativeMethods.LibraryLifetimeObject.Finalize()
Exception Message: MSBuild error 255 has ended this build. You can find more specific information about the cause of this error in above messages. (type BuildProcessTerminateException) Exception Stack Trace: at System.Activities.Statements.Throw.Execute(CodeActivityContext context) at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager) at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)
This problem is very intermittent and it can be bypassed by simply retrying the build. Has anyone else run into this? Any solutions?
I know it is a little bit late for answer but it might help someone else
answer by Buck Hodges
We have now gotten to the bottom of this issue after debugging it with Manoj and customer support. It affected gated checkin of continuous delivery of Azure deployments as part of the build process when using the Azure SDK 2.5 or older. The workaround is to add /p:GenerateBuildInfoConfigFile=false to the msbuild arguments in your build definition. We are working on updating the build VM in production, but that will take 24-48 hours to propagate to all build pools.
You might want to read more in context here
https://social.msdn.microsoft.com/Forums/en-US/5a0d1950-1367-41a6-9171-676a0d0e93c1/tfs-online-getted-checkin-build-failures-vs-online-tfs-online-team-need-to-look-into-it?forum=TFService
Alternative solution based on comments
If you have VS installed on your build server, make sure you have opened it and licensed it. by #Phill
Strangely enough for me, I was getting the same error in the build logs:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\BuildInfo\Microsoft.VisualStudio.ReleaseManagement.BuildInfo.targets (147): The type initializer for 'LibGit2Sharp.Core.NativeMethods' threw an exception.
Unhandled Exception: System.TypeInitializationException: The type initializer for 'LibGit2Sharp.Core.NativeMethods' threw an exception. ---> System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
I was able to simply RETRY the build, and it did not fail on the second try. So for me it was a transitory build issue.
Although late to the party, experienced this error recently and while the solution marked as the answer worked for that build, the error was fixed (and the switch removed) when Visual Studio 2012 was upgraded to Visual Studio 2015 Update 3 on the build server which was running TFS 2015 Update 3.
I hit this after I had upgraded my TFS 2013 XAML build machine to TFS 2015.
I had also changed the user that TFS 2015 XAML build used to run the build (service.
The Fix:
I had to log into the TFS 2015 XAML build machine as that new user and launch VS (I was using VS2013).
It ran through it's first time launch questions and setup.
I still saw the Lib2GitSharp Error issue sometimes after that.
Then I also logged VS (on the TFS 2015 XAML build machine) into a valid VS account.
I have not seen the Lib2GitSharp Error since and I never used the /p:GenerateBuildInfoConfigFile=false option.
I resolved this error by adding the build account to the local administrators group on the build machine.
I am using a windows service, In which I am having a reference of an assembly which is copy local= false. But I am trying to load it at runtime, which is though working fine when I am running it from visual studio, But when I try to install it, cmd gives this error:
An exception occurred while trying to find the installers in the D:\Official\Pro
jects\20131007_ImproveDN\build\debug\application
s\SubscriptionService\SubscriptionService.exe assembly.
System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the
requested types. Retrieve the LoaderExceptions property for more information.
Aborting installation for D:\Official\Projects\2
0131007_ImproveDN\build\debug\applications\SubscriptionService\SubscriptionServi
ce.exe.
An exception occurred during the Rollback phase of the System.Configuration.Inst
all.AssemblyInstaller installer.
System.InvalidOperationException: Unable to get installer types in the D:\Offici
al\Projects\\20131007_ImproveDN\build\debug\appli
cations\SubscriptionService\SubscriptionService.exe assembly.
The inner exception System.Reflection.ReflectionTypeLoadException was thrown wit
h the following error message: Unable to load one or more of the requested types
. Retrieve the LoaderExceptions property for more information..
An exception occurred during the Rollback phase of the installation. This except
ion will be ignored and the rollback will continue. However, the machine might n
ot fully revert to its initial state after the rollback is complete.
Also one thing to note here is that If I make copy local true of that .dll it makes installation fine. BUt I dont want to load it before installation so I want to do it at runtime.
Thanks in Advance.
Maybe you need to use another version of InstallUtil.exe:
c:\Windows\Microsoft.NET\Framework\v2.0.50727\InstallUtil.exe
c:\Windows\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe
c:\Windows\Microsoft.NET\Framework64\v2.0.50727\InstallUtil.exe
c:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe
Try to use x64 version from Framework64 subfolder.
Also one thing to note here is that If I make copy local true of that .dll it makes installation fine. BUt I dont want to load it before installation so I want to do it at runtime.
That doesn't really matter, the assembly still needs to make it to the installation directory. If you set Copy Local to false, then you still need to distribute the assembly with the installation.
I had a similiar problem. I did the following that worked for me.
First, use FuseLog (Assembly Binding Viewer) to figure out where the binding is failing (Described Here
Once I began getting logs, I noticed this in my log was "Invalid assembly platform or ContentType in file (hr = 0x8007000b)."
My solution consisted of 3 projects. I went through the build properties of each project and noticed that one of them was targeted for "x86". I changed it to "Any CPU", recompiled and the problem was resolved.