Develop Reference

System.IO.FileLoadException during loading .NET assembly: error 0x8007007a

We are having an issue related to starting a few in house developed .NET applications on Windows 10 Version 1607 machines. Sometimes starting an application doesn't succeed. This is because loading a dependent .NET assembly fails. The error message is:
System.IO.FileLoadException: Could not load file or assembly
'[assemblyname], Version=[version], Culture=neutral,
PublicKeyToken=[publickeytoken]' or one of its dependencies. The data
area passed to a system call is too small. (Exception from HRESULT:
0x8007007A)
The issue happens about 10% of the application startups in different .NET applications. It happens with 32-bit as well as 64-bit applications. During all the startups also many other applications start that start up OK. I wonder why we get the 0x8007007a error? Maybe it is collateral due to a heap corruption that happened before?
You can see related logging from FUSLOGVW below. The filepaths and assembly names are anonymised. The assembly that is attempted to be loaded has quite a long name (59 characters without the .dll postfix). As a test, we changed the name of the assembly to a shorter name. Unfortunately the issue remained. Adding a probing path in the exe.config also did not fix the issue.
Furthermore, there seems to be code of an older version of the Microsoft Assembly Resolver available at Github: https://github.com/fixdpt/shared-source-cli-2.0. I suspect there is something wrong in the ConstructCodeBaseList in adlmgr.cpp. But I can't figure out what triggers the issue.
*** Assembly Binder Log Entry (2020/01/30 # 13:48) ***
The operation failed.
Bind result: hr = 0x8007007a. The data area passed to a system call is too small.
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable C:\Program Files (x86)\XXX\XXX\XX.X.X.X\XXX\XXXXXXXXXXXXXX\ApplicationWeWantToStart.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: DisplayName = AnAssem.blyWi.th.AVeryLon.gNameAA.AAAAAAAA.AAAAAAAAAAA.AAAA, Version=13.0.0.0, Culture=neutral, PublicKeyToken=XXXXXXXXXXXXXXXX
(Fully-specified)
LOG: Appbase = file:///C:/Program Files (x86)/XXX/XXX/XX.X.X.X/XXX/XXXXXXXXXXXXXX/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = ApplicationWeWantToStart.exe
Calling assembly : ApplicationWeWantToStart, Version=13.0.0.0, Culture=neutral, PublicKeyToken=XXXXXXXXXXXXXXXX.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Program Files (x86)\XXX\XXX\XX.X.X.X\XXX\XXXXXXXXXXXXXX\ApplicationWeWantToStart.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: AnAssem.blyWi.th.AVeryLon.gNameAA.AAAAAAAA.AAAAAAAAAAA.AAAA, Version=13.0.0.0, Culture=neutral, PublicKeyToken=XXXXXXXXXXXXXXXX
LOG: GAC Lookup was unsuccessful.
ERR: Error occurred constructing the probing codebase list.
ERR: Unrecoverable error occurred during pre-download check (hr = 0x8007007a).

Any change your startup issue may be related to this Microsoft Support Link

System.IO.FileLoadException when signing application

I have a WPF application that follows the MVVM pattern. We recently signed the app and now I am getting a lot of first chance exceptions on startup. I have traced the problem to the following:
In any view, if I reference another namespace with in the application when the view is initialized I get the error:
"Could not load file or assembly 'MyApplication, Version=3.0.5917.24348, Culture=neutral, PublicKeyToken=xxxxxxxxxxxx' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)":"MyApplication, Version=3.0.5917.24348, Culture=neutral, PublicKeyToken=xxxxxxxxxxx"
Its always looking for a version that is 1 behind the version that I'm actually running.
If I remove the references to the other namespaces from the views, the InitializeComponent() does not throw the error
View:
<UserControl x:Class="MyApplication.View.DiagnosticsView"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:convert="clr-namespace:MyApplication.Converters" <!--Causes error-->
xmlns:behave="clr-namespace:MyApplication.Behaviors" <!--Causes error-->
xmlns:controls="clr-namespace:MyApplication.UserControls" <!--Causes error-->
If I remove these references, and move my converters and behaviors into another DLL and then reference them through the DLL there is no problem. The errors go away. Also If I don't sign the application I do not get the errors. I don't really want to have to reference these things in a different DLL, it seems like this should work fine. It also spends about 30 seconds throwing all of these errors as all of the views are created, so I am taking a hit on performance. I dont get why the application is trying to load itself, and why its trying to load an older version of itself. No matter how many times I build, the error is always 1 version behind.
Fusion Log:
*** Assembly Binder Log Entry (3/17/2016 # 10:30:11 AM) ***
The operation failed.
Bind result: hr = 0x80131040. No description available.
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable C:\tfs\Development\dev-feature\src\MyApplication\bin\Debug\MyApplication.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: DisplayName = MyApplication, Version=3.0.5920.15594, Culture=neutral, PublicKeyToken=xxxxxxxxxxxx
(Fully-specified)
LOG: Appbase = file:///C:/tfs/Development/dev-feature/src/MyApplication/bin/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = MyApplication.exe
Calling assembly : PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\tfs\Development\dev-feature\src\MyApplication\bin\Debug\MyApplication.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: MyApplication, Version=3.0.5920.15594, Culture=neutral, PublicKeyToken=7b0591cb18d2a932
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///C:/tfs/Development/dev-feature/src/MyApplication/bin/Debug/MyApplication.DLL.
LOG: Attempting download of new URL file:///C:/tfs/Development/dev-feature/src/MyApplication/bin/Debug/MyApplication/MyApplication.DLL.
LOG: Attempting download of new URL file:///C:/tfs/Development/dev-feature/src/MyApplication/bin/Debug/bin/MyApplication.DLL.
LOG: Attempting download of new URL file:///C:/tfs/Development/dev-feature/src/MyApplication/bin/Debug/bin/MyApplication/MyApplication.DLL.
LOG: Attempting download of new URL file:///C:/tfs/Development/dev-feature/src/MyApplication/bin/Debug/MyApplication.EXE.
LOG: Assembly download was successful. Attempting setup of file: C:\tfs\Development\dev-feature\src\MyApplication\bin\Debug\MyApplication.exe
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: MyApplication, Version=3.0.5920.15596, Culture=neutral, PublicKeyToken=7b0591cb18d2a932
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: The assembly reference did not match the assembly definition found.
ERR: Run-from-source setup phase failed with hr = 0x80131040.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

Edit:
Did you use ProcessMonitor to see where Visual Studio is loading v 3.0.5917.24348 from? Visual Studio wants v3.0.5920.15596 so you have to put that DLL where its expected.
Edit 2:
Can you put in a binding redirect in your config file like this?
<dependentAssembly>
<assemblyIdentity name="xxxxxx" publicKeyToken="121fae78165ba3d4"/>
<bindingRedirect oldVersion="3.0.5920.15596" newVersion="3.0.5917.24348"/>
</dependentAssembly>
Ref: .Net picking wrong referenced assembly version
Original:
One reason you might get the error:
Could not load file or assembly 'MyApplication, Version=3.0.5917.24348, Culture=neutral, PublicKeyToken=xxxxxxxxxxxx' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
Is when your assembly is signed and your reference to it has the Specific Version property set to True, resulting in FileLoadException.
Check you have Specific Version set to False:

Is it possible that you're trying to use strong-named URI references in your XAML? For example, by setting the AssemblyPublicKeyToken attribute your project file or by modifying the generated code-behind for the XAML?
If your XAML references are using a strong name and you use a constantly-changing version, then your XAML may end up using the previous version of the project, because the references are generated prior to the build being completed (and the new version being set).
To check, find your generated for your XAML under the obj directory and check for Uris (for example ~\obj\Debug\TestControl.g.i.cs):
System.Uri resourceLocater = new System.Uri("/T_Signing;V1.0.0.0;76005ee8ffcf5f2d;component/testcontrol.xaml", System.UriKind.Relative);
Above the URI has the full name and version. Whereas if you don't have strong named references, the uri would be more like:
System.Uri resourceLocater = new System.Uri("/T_Signing;component/testcontrol.xaml", System.UriKind.Relative);

FileLoadException At InitializeComponent or x:Class=

I get a file loader exception (first chance) at the InitializeComponent-method or the debugger breaks at the x:Class attribute of the xaml-root of multiple WPF user controls. Everything works fine despite the fact that the exceptions slow down navigation by a lot.
This is the exception message:
Could not load file or assembly 'Company.Solution.UserInterface, Version=0.1.5568.25577, Culture=neutral, PublicKeyToken=45069ab0c15881ce' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
This is the Fusion log:
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable D:\Development\Product\Main\src\Company.Product \bin\Debug\Product.vshost.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: DisplayName = Company.Product .UserInterface, Version=0.1.5568.25577, Culture=neutral, PublicKeyToken=45069ab0c15881ce
(Fully-specified)
LOG: Appbase = file:///D:/Development/Product/Main/src/Company.Product/bin/Debug/
LOG: Initial PrivatePath = NULL
Calling assembly : PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
LOG: This bind starts in default load context.
LOG: Using application configuration file: D:\Development\Product \Main\src\Company.Product \bin\Debug\Product .vshost.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: Company.Product .UserInterface, Version=0.1.5568.25577, Culture=neutral, PublicKeyToken=45069ab0c15881ce
LOG: Attempting download of new URL file:///D:/Development/Product/Main/src/Company.Product/bin/Debug/Company.Product.UserInterface.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
My project structure has a root project that references a module project (in which the exception occurs). The module project itself references the project that is the target of the above mentioned probing "Company.Product.UserInterface.dll" which contains some resources / controls / styles / primitives / converters and so on.
How can I get rid of the FileLoadExceptions?
Another more complete Fusion-log:
=== Pre-bind state information ===
LOG: DisplayName = Company.Product.UserInterface, Version=0.1.5577.18122, Culture=neutral, PublicKeyToken=45069ab0c15881ce
(Fully-specified)
LOG: Appbase = file:///D:/Development/Product/Main/src/Company.Product/bin/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = Product.vshost.exe
Calling assembly : PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
LOG: This bind starts in default load context.
LOG: Using application configuration file: D:\Development\Product\Main\src\Company.Product\bin\Debug\Product.vshost.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: Company.Product.UserInterface, Version=0.1.5577.18122, Culture=neutral, PublicKeyToken=45069ab0c15881ce
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///D:/Development/Product/Main/src/Company.Product/bin/Debug/Company.Product.UserInterface.DLL.
LOG: Assembly download was successful. Attempting setup of file: D:\Development\Product\Main\src\Company.Product\bin\Debug\Company.Product.UserInterface.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: Company.Product.UserInterface, Version=0.1.5577.18123, Culture=neutral, PublicKeyToken=45069ab0c15881ce
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: The assembly reference did not match the assembly definition found.
ERR: Run-from-source setup phase failed with hr = 0x80131040.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
At the moment the exception occurs the version of the assembly in the SolutionExplorer referenced is 0.1.5577.18123 (in all solutions that reference the ..UserInterface.dll. I have no idea who looks up 0.1.5577.18122, this version did never exist)
If I run a new rebuild all I get the same error, Fusion looks for (I never had this version number):
LOG: Post-policy reference: Company.Product.UserInterface, Version=0.1.5577.18465, Culture=neutral, PublicKeyToken=45069ab0c15881ce
the version found is:
LOG: Assembly Name is: Company.Product.UserInterface, Version=0.1.5577.18466, Culture=neutral, PublicKeyToken=45069ab0c15881ce
Visual Studio Version is 2013 Ultimate, and the project is build on .net4.5 and the assembly versions are auto generated in the build process.
I uploaded the build log to tinyupload as it was too big.
The full Fusion-log can be found here at pastebin.

Version=0.1.5577.18122
This auto-generated version number tells a tale, the last two parts of the version number are not arbitrary. They are based on the date and time the assembly was built. The build number is generated from the number of days since Jan 1st, 2000. The revision number is the number of seconds*2 since midnight without daylight savings correction.
So facts we know is that the 18122 assembly was built on March 30th at 2:12:34 in the afternoon. And then it got built again, 2 seconds later at 2:12:36 in the afternoon. After it was used as a reference assembly to build another project, that made the CLR spit bullets.
This should not happen, a project must be built only once in a single build session. Finding out why this happened requires digging through the MSBuild trace. You generate the one you need with Tools + Options, Projects and Solutions, Build and Run. Change the "MSBuild project build output verbosity" setting to Detailed. MSBuild now gets very chatty and tells you why it decided to build a project. If you get lost in the woods trying to decode its output (there's a lot of it) then copy/paste it in a paste-bin and link to it in your question.
There are otherwise not that many great explanations for a mishap like this. Older VS versions made it too easy to accidentally create a circular dependency between projects. You flush that out by using Build + Clean. Rebuilding the solution now fails and tells you which reference assembly is the troublemaker. You are using .NET 4 however, so at least VS2010. So not a fantastic lead, Microsoft added more checks to prevent this from happening without a warning. Not sure if it is reliable in all cases, it could be fooled if you don't depend on MSBuild alone for example. Not uncommon on build servers with "continuous integration" features.
We need the build trace to give you a reliable diagnostic.

Suggestion 1
Is there a cyclic reference causing an old version of the dll to be loaded? (this was proven not to be the point but I have left in for historical reasons).
Relating to this answer
Suggestion 2
Can you try creating a Publisher Policy?
Here is an example that needs to be added to your app.config file.
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Company.Solution.UserInterface"
publicKeyToken="45069ab0c15881ce"
culture="en-us" />
<!-- Redirecting to version 0.1.5568.25577 of the assembly. -->
<bindingRedirect oldVersion="0.0.0.0-0.1.5568.25577"
newVersion="0.1.5568.25577"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
Explained in further detail here
Suggestion 3
Has anything changed with regards to the key that is being used to sign your assemblies?
Suggestion 4
As a slight adaption of my initial suggestion. You have stated that there are 3 projects that reference Company.Solution.UserInterface. Can you confirm that all 3 projects are referencing the same version of that assembly?

Schema specified is not valid - Exception

Schema specified is not valid. Errors: (0,0) : error 0004: Could not
load file or assembly 'JIMSDAL, Version=6.0.5126.47, Culture=neutral,
PublicKeyToken=9054b539c49e6e2e' or one of its dependencies. The
located assembly's manifest definition does not match the assembly
reference. (Exception from HRESULT: 0x80131040)
Why I get this exception, I checked every dependent project of JIMSDAL and they are referencing the correct updated version 6.0.1.0.
I also checked with fuslogvw.exe and its not helping. It says
The operation failed.
Bind result: hr = 0x80131040. No description available.
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Running under executable X:\yyyyy\Build\Debug\JIMS.vshost.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: DisplayName = JIMSDAL, Version=6.0.5126.47, Culture=neutral, PublicKeyToken=9054b539c49e6e2e
(Fully-specified)
LOG: Appbase = file:///X:/yyyyy/Build/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
Calling assembly : EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: X:\yyyyy\Build\Debug\JIMS.vshost.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Post-policy reference: JIMSDAL, Version=6.0.5126.47, Culture=neutral, PublicKeyToken=9054b539c49e6e2e
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///X:/yyyyy/Build/Debug/JIMSDAL.DLL.
LOG: Assembly download was successful. Attempting setup of file: X:\yyyyy\Build\Debug\JIMSDAL.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: JIMSDAL, Version=6.0.0.0, Culture=neutral, PublicKeyToken=9054b539c49e6e2e
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: The assembly reference did not match the assembly definition found.
ERR: Run-from-source setup phase failed with hr = 0x80131040.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
There is no config file with this version too. I even removed the reference of this project and re added. But nothing works. Where am I going wrong?

That's not much to go by but the FSLogVw output shows the calling assembly to be EF. Are you using and edmx? If so, you may want to open it in XML view (not design view) and see if there are references to your assembly in there. You mentioned you've already checked the .config file, so that rules that out.

You are referencing JIMSDAL, Version=6.0.5126.47, but the calling assembly found JIMSDAL, Version=6.0.0.0. I've had this happen in the past when mixing project references with references to a compiled assembly, but there are other ways it can happen. Look for multiple references to JIMSDAL, and make sure they are all pointing to the same thing.
This question (https://stackoverflow.com/questions/5600904/net-dll-dependency-of-same-file) describes a similar problem, you might want to take a look.
And here's another question with some helpful suggestions: Project References DLL version hell

How to find what depends on a specific version of a specific dependency?

I'm getting this error when I run my app (not at compile time):
Could not load file or assembly
'Castle.Windsor, Version=2.1.0.0,
Culture=neutral,
PublicKeyToken=407dd0808d44fbdc' or
one of its dependencies. The located
assembly's manifest definition does
not match the assembly reference.
(Exception from HRESULT: 0x80131040)
My solution has many projects, using project references where possible, but some of those projects have assembly references to external dependencies.
How can I easily find out which project is looking for this specific version of Castle.Windsor.dll? I don't have that version and am trying to use 2.5.2 (latest), so I want to find the culprit and update it to use the latest one.
Many thanks in advance.
UPDATE
I've added a sanitised Fusion log below. It appears to be telling me that Caliburn.Castle requires Castle.Windsor, Version=2.1.0.0 (which would be a mistake as I'm using 2.5), but Fusion assembly probing as actually finding Castle.Windsor, Version=2.5.1.0 instead.
Have I understood that correctly?
=== Pre-bind state information ===
LOG: User = Barney\neil
LOG: DisplayName = Castle.Windsor, Version=2.1.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc
(Fully-specified)
LOG: Appbase = file:///[Debug folder of my exe]
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = [Filename of my exe]
Calling assembly : Caliburn.Castle, Version=1.1.0.0, Culture=neutral, PublicKeyToken=8e5891231f2ed21f.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: [Config file for my exe]
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: Castle.Windsor, Version=2.1.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///[Debug folder of my exe]/Castle.Windsor.DLL.
LOG: Assembly download was successful. Attempting setup of file: [Debug folder of my exe]\Castle.Windsor.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: Castle.Windsor, Version=2.5.1.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc
WRN: Comparing the assembly name resulted in the mismatch: Minor Version
ERR: The assembly reference did not match the assembly definition found.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

You could use the Fuslogvw.exe utility which will provide you more information on the calling assembly. Scott Hansleman also blogged about it.

Have you looked at the assembly binding log viewer (Fuslogvw.exe)?
This should provide all the information needed.
See on MSDN.

FusionLog tool is best tool for things like that, but sometimes will only point to your code. Try turning up the verbosity for MSBuild and you might be able to track it down to where the compilation is at when it fails.