AmbiguousMatchException inside of get_FrameworkVersion()

[kuacci]

Hi guys,

My customer got System.Reflection.AmbiguousMatchException when when using latest version (2.3.10) of Microsoft.Rest.ClientRuntime: https://www.nuget.org/packages/Microsoft.Rest.ClientRuntime/

I captured dump against above above exception and it tells us the exception raised up when thread calling Microsoft.Rest.ServiceClient`1.get_FrameworkVersion()

0:061> kL
Child-SP RetAddr Call Site 00 000000001101cf20 000007fef7ce32ea KERNELBASE!RaiseException+0x39 01 000000001101cff0 000007fef7ce311a clr!RaiseTheExceptionInternalOnly+0x2aa 02 000000001101d0f0 000007fe9b68f8f7 clr!IL_Throw+0x10b 03 000000001101d2a0 000007fe9b595aa7 mscorlib!System.Attribute.GetCustomAttribute(System.Reflection.Assembly, System.Type, Boolean)+0x77 04 000000001101d2d0 000007fe9b595905 Microsoft_Rest_ClientRuntime!Microsoft.Rest.ServiceClient1[[System.__Canon, mscorlib]].get_FrameworkVersion()+0x67 05 000000001101d310 000007fe9b5957c2 Microsoft_Rest_ClientRuntime!Microsoft.Rest.ServiceClient1[[System.__Canon, mscorlib]].get_DefaultUserAgentInfoList()+0x75 06 000000001101d360 000007fe9b594550 Microsoft_Rest_ClientRuntime!Microsoft.Rest.ServiceClient`1[[System.__Canon, mscorlib]].SetUserAgent(System.String, System.String)+0x32 ......

0:061>!pe Exception object: 000000027fd28fc0 Exception type: System.Reflection.AmbiguousMatchException Message: Multiple custom attributes of the same type found. InnerException: StackTrace (generated): StackTraceString: HResult: 8000211d

The corresponding code of Rest is here:

private string FrameworkVersion
        {
            get
            {
                if (string.IsNullOrEmpty(_fxVersion))
                {
                    Assembly assembly = typeof(Object).GetTypeInfo().Assembly;                    
                    AssemblyFileVersionAttribute fvAttribute =
                                assembly.GetCustomAttribute(typeof(AssemblyFileVersionAttribute)) as AssemblyFileVersionAttribute;
                    _fxVersion = fvAttribute?.Version;
                }

                return _fxVersion;
            }
        }

This issue only happens on the IIS server which has SCOM APM installed, the exception just gone after removed SCOM APM agent. I believe this might caused by the APM injection which result in the above reflection code not working properly.

So I would like to know if you can change the above code to get .net framework version? Like the option introduced here to get .net framework version from registry?

Thanks

[hovsepm]

@kuacci this seems to be a known issue which has a fix steps in the comments - https://github.com/Azure/autorest/issues/1542

[MarkWhybird]

Hi @hovsepm - my workplace is the client. As @kuacci noted, both the workaround and the correct way of coding it (looking in the registsry instead of using reflection) are known. is there any reason the code snippet above can't be changed to look up the registry?

[hovsepm]

@MarkWhybird I believe this particular exception indicates a broken environment on the worker that can cause other issues and that is why the suggested direction is to fix the working environment instead of making this particular call "exceptionless". But I'll ask @SergeyKanzhelev and @wiktork to add more details if my explanation is not very precise.

[SergeyKanzhelev]

If it's server app - follow the instructions in abovementined issue. Just update Application Insights extension or StatusMonitor in your environment.

If it's UWP app mentioned here I don't know the status.

[kuacci]

@hovsepm,

Thank you for looking into this issue. As what I said this particular issue was caused by SCOM APM agent and we spent almost a month to figured out the cause. As you know that there are lots of 3rd party components which has the ability to inject into .net application like APM, dynatrace and others.

It would be very frustrated when troubleshooting this kind of issue. So I would like to check with you if it is possible to change the code above to a more safer way to get .net framework version?

Thanks,

[hovsepm]

@shahabhijeet could you take a look to the issue? it seems to be another hit for the parked fix in PR https://github.com/Azure/azure-sdk-for-net/pull/3752

[shahabhijeet]

@kuacci I am going to investigate this and have a resolution on this one soon. My hunch is, some SDK has included FileVersion attribtue multiple times. This could as simple as scanning for duplicate File version attributes.

[kuacci]

Thank you @shahabhijeet

[shahabhijeet]

@kuacci there isn't anything in the clientruntime we can do to workaround this issue. We do not want to swallow the ambiguous exception as it affects basic clientruntime info in the request header for each SDK request. Not swallowing the exception made the real issue getting discovered in this case.

The following comment clarifies what was causing the issues in the first place. https://github.com/Azure/autorest/issues/1542#issuecomment-354811676

Workaround is to install the latest version of App insights extension should resolve the error you have reported and more information can be found in the following issue https://github.com/Azure/autorest/issues/1542

Sorry took longer than expected to respond to this issue.

[kuacci]

I have to say that my issue has nothing to do with App Insights extension. As I said before, the issue was resolved after removed SCOM (System Center Configuration Manager) Application Monitor Agent which is another Microsoft product.

Maybe I should check with SCOM team, but I believe the change from your side would be the permanent solution for this kind of issue.

[justinhelgerson]

@kuacci I was skeptical, but sure enough, removing SCOM fixed this issue for me as well. I'm not an Azure user (I was using a different library that made a similar call) but I was experiencing this same exception. Removing SCOM resolved it.

Did you ever learn more about this or discover any other workarounds?

[kuacci]

@justinhelgerson If removing SCOM can fix this issue for you then the root cause is SCOM. You asked for the other workaround, is that means you want SCOM Application monitor agent running? If that is true then you'd better to upgrade it to latest version. I am not sure if SCOM team has noticed this issue and released fix for it, but it's worth to try.