mscorlib

[CJHammond]

I have a .DLL that uses mscorlib in Labwindows/CVI 2013 SP2. We recently had to update the dotnet from version 4.5.1 to 4.5.2 but in addition to the update, 4.5.1 was scrubbed from the machine. My .DLL is broken now and reports error 17502 when executed from TestStand. Stepping into the CVI code, one of the library function calls is returning a null pointer. This .DLL does work on a machine that always that 4.5.2 on it from the start.

I tried removing both the instrument mscorlib and the function panel(FP). Then reconnecting them. I tried removing the #include and letting the compiler auto add it. I tried adding mscorlib2.fp and making sure I added the mscorlib2 instrument(that is mscorlib version=2.0.0.0). Still not working. I know there is a setting in a labview .ini that tells it which version of dotnet to use. Is there something similar in CVI?

[Princealimagicalhe]

CJHammond,

It seems as though you've done a great deal of troubleshooting similar to the 17502 error resource article linked here.

Have you gotten a chance to debug further into the DLL or change the reference within the DLL?

Could you elaborate how 4.5.1 was scrubbed from your machine and how you were able to tell?

Does downgrading the dotnet framework on either systems help with your issue at all or are you still having the same problem?

Additionally, there is some resources in setting legacy dotnet configurations, I've attached them here.

Please let us know if the resources help or if you're able to configure any further.

[CJHammond]

I was doing a bit more research on it over the weekend and found a few more things to try.

I removed the mscorlib.fp and the instrument mscorlib. I then used Tools>>Create .Net Controller inside CVI to make a new mscorlib .fp and instrument(I will call it mscorlib4 from here on). I created a new object file for the new mscorlib4 using Options>> Create Object File, inside the mscorlib4 . I made the appropriate changes, like pointing to the right header file, etc. I then recompiled my dll and got the same result.

I checked that the GAC, located at ' C:\Windows\assembly ' had a matching version. It gets a little strange here because the mscorlib is version 2.0.0.0 here, the public key token does match the mscorlib4.c, so I am assuming at the moment that it is fine on the .dll side of the code.

To answer your questions Ali,

I should say that 4.5.1 was uninstalled from program and features in Control Panel. It occurs to me now that saying scrubbed is not the same thing as uninstalled because there could still be references or .dlls present. Part of the update was to do a patch conformance, which searches for 4.5.1 components and it reported compliance. However, that just means that in the places the tool was told to look, it saw 4.5.2 and not 4.5.1, which is why I was thinking scrubbed until I thought about it a little more.

I have not tried downgrading or reverting back to 4.5.1. I was thinking of trying that.

I will look at the registry setting for useLegacyDotNetLibrary option.

[bahannah]

CJHammond,

It sounds like you have quite a few other steps to try, but I was wondering if your dll produces the same error when you try to access it in other programs besides TestStand?

Please continue to keep us updated!

Regards,

Hannah 

Applications Engineering 

National Instruments 

www.ni.com/support 

[CJHammond · Accepted solution]

Ok, I have solved the issue. It was not what I expected.

This .DLL is going onto a Government System and dotnet was updated as part of STIG. One of the settings is to turn on 'Federal Information Processing Standard (FIPS) 140 – Security Requirements for Cryptographic Modules'. That is accomplished by changing this key in the registry;

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\fipsalgorithmpolicy = 1 is enabled, 0 is disabled

This 'advises' applications to use specific cryptography algorithms that have been validated as being FIPS compliant.  In my case, my DLL is a checksum generator and the verify tool. This means that when I call, in example, "System_Security_Cryptography_MD5_Create" to be FIPS compliant, I have to call "System_Security_Cryptography_MD5CryptoServiceProvider__Create".

I additionally noticed another issue that I now know to be related to this issue as well. We are using Labview FPGA compile farm for some of the PXI chassis. A behavior where we were unable to compile bitfiles and the error presentation would be something like 'The Pipe MD5 hash does not match reported value'.  I will get an image in later.

SO at the moment I am just running with the FIPS compliant off, letting development continue, while I get the code modified to compliance.

[CJHammond]

LabView FPGA Compile Farm related issue