CODEWITHSUNDEEP
.net
Gaspar Nagy
Gaspar Nagy

Reputation: 4537

How to diagnose 'Strong name validation failed.' 0x8013141A errors

I have a tool that is compiled for .NET Framework 4.8 and uses the NuGet package Microsoft.VisualStudio.Services.Client which contains an assembly Microsoft.VisualStudio.Services.Common.

The tool runs fine on most of the machines, but on some machines it fails with:

System.IO.FileLoadException: Could not load file or assembly 'Microsoft.VisualStudio.Services.Common, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)
File name: 'Microsoft.VisualStudio.Services.Common, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' ---> System.Security.SecurityException: Strong name validation failed. (Exception from HRESULT: 0x8013141A)
The Zone of the assembly that failed was:
MyComputer

I have checked and in both cases it runs with the exact same .NET Framework (4.8). I tried to check the fusion logs, but no errors are reported there, even for the assembly that is causing the problem it reports success.

(The same code works on .NET 6.)

My question is, how such problem could be diagnosed? Any hints what I could check?

Update: To reflect on @CherryDT's comment: Strangely the validation skipping with the sn.exe tool also does not help:

C:\Users\<user>\source\repos\ConsoleApp1\ConsoleApp1\bin\Debug\net48>sn -Vr Microsoft.VisualStudio.Services.Common.dll

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Verification entry added for assembly 'Microsoft.VisualStudio.Services.Common,B03F5F7F11D50A3A'

C:\Users\<user>\source\repos\ConsoleApp1\ConsoleApp1\bin\Debug\net48>sn -Vl

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Assembly/Strong Name                  Users
===========================================
Microsoft.VisualStudio.Services.Common,B03F5F7F11D50A3A All users

C:\Users\<user>\source\repos\ConsoleApp1\ConsoleApp1\bin\Debug\net48>sn -v Microsoft.VisualStudio.Services.Common.dll

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Assembly 'Microsoft.VisualStudio.Services.Common.dll' is valid
Assembly 'Microsoft.VisualStudio.Services.Common.dll' is verified with a key other than the identity key

C:\Users\<user>\source\repos\ConsoleApp1\ConsoleApp1\bin\Debug\net48>ConsoleApp1.exe

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'Microsoft.VisualStudio.Services.Common, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A) ---> System.Security.SecurityException: Strong name validation failed. (Exception from HRESULT: 0x8013141A)
   --- End of inner exception stack trace ---
   at Program.<Main>$(String[] args)

Upvotes: 2

Views: 6651

Answers (2)

Sahitya
Sahitya

Reputation: 181

You can skip strong name validation using below commands.

64-bit machine

For x64 machine,

"C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\x64\sn.exe" -Vr *,*

Please note that we are using x64 version of the sn.exe.

32-bit machine

For x32 machine,

"C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\sn.exe" -Vr *,*

Please note that we are using x32 version of the sn.exe.

Upvotes: 2

Gaspar Nagy
Gaspar Nagy

Reputation: 4537

I finally figured out what causes this. (Thanks to @CherryDT to force me to check the sn.exe once more.)

The problem was that the signature of the assembly was really wrong, but on the machines where it was not causing an error, there has been a global strong name validation ignore for all assemblies (*,*) that was probably added silently by some app installer earlier. (Quite unfriendly to do such thing without notifying the user in my opinion.)

The reason why I was not realizing this earlier was that I was using the x86 version of the sn.exe and not the x64 one that the app used.

Finally I fixed the problem by using a different version of the dependency where the signing problem has been fixed.

So the conclusion is that I should always make sure that I use the right version of the sn.exe (see https://stackoverflow.com/a/18760340/26530 for details on how).

Upvotes: 3

Related Questions