Set LabWindows CVI Adapter to older version

[Curt_C]

Hi Doug,

I have the 32 bit versions of TestStand and CVI.

I don't have admin rights on any of my machines but I have do have elevated privileges to change the registry.

Curt

[Scott_Richardson]

Curt -

Is there anyway that you could work with someone, maybe your IT, to test if launching CVI as elevated helps mitigate the issue?

[Curt_C]

Hey Scott,

I tried that, it doesn't help

[Scott_Richardson]

Curt -

I think I understand what is going on.

First, here is just as an FYI for future testing of this. If you still have the option configured for CVI to display the Welcome page, I did notice that the registry key for the server path is not updated until the Welcome page is dismissed. So if some of your testing expected the key to change when the Welcome page was visible, you might have to repeat that testing.

I used procmon.exe to see what registry keys TestStand was accessing and I noticed that TestStand was creating and deleting a key, specifically

HKCU\Software\Classes\Wow6432Node\CLSID\{5AB151E3-414A-11D0-A62C-0020AF16F78E}\TestStandCVILastLaunchedWorkaround

I looked in our TestStand source code for the adapter and I did notice that TestStand creates and deletes the key to mitigate an issue with Windows 7 (and likely later OS) where the OS caches registry keys and the TestStand application cannot see any changes potentially until after reboot. A mitigation was added to TestStand 2014 to create and delete a subkey to potentially invalidate the cached registry values. This was based on this StackOverflow article. and our empirical testing done at the time.

I could not reproduce your issue because I was using TestStand 2014 which has this mitigation, and you are using TestStand 2012. I now tested TestStand 2012 and I now see your issue.

Since you are using TestStand 2012, that mitigation is not in TestStand. I would suggest the following test:

1) Exit any TestStand and LabWindows/CVI apps.

2) Launch LabWindows/CVI 2012 and exit.

3) Verify that the registry key previously discussed points to 2012

4) Restart you computer

5) Re-verify that the registry key previously discussed points to 2012

6) Launch TestStand and try to use Edit Code feature

A manual work around that worked for me was:

1) Exit all CVI

2) Launch CVI 2012 to set the CU key path (you could just edit it in Regedit)

2) Open Regedit and go to the CU entry HKEY_CURRENT_USER\Software\Classes\Wow6432Node\CLSID\{5AB151E3-414A-11D0-A62C-0020AF16F78E}

3) Add a subkey and delete it

4) Lauch TestStand if not already launched and attempt to edit code

Technically you should be able to create a simple CVI application to do what the TestStand adapter does. The C++ code in our adapter is the following:

const static char keyName[] = "Software\\Classes\\CLSID\\{5AB151E3-414A-11D0-A62C-0020AF16F78E}\\TestStandCVILastLaunchedWorkaround";
HKEY hDummyKey = NULL;
LONG result = RegCreateKeyEx(HKEY_CURRENT_USER, keyName, 0, NULL, REG_OPTION_NON_VOLATILE, KEY_WRITE | KEY_WOW64_32KEY, NULL, &hDummyKey, NULL);
if (ERROR_SUCCESS == result)
{
	RegCloseKey(hDummyKey);  hDummyKey = NULL;
}
TSRegistry::DeleteKeyFrom32BitHive(HKEY_CURRENT_USER, keyName);