TA_CheckAndSavePKey returns TA_FAIL on one machine

>> "P.S. I don't see a password reset option on the forum login?"

This forum software (phpBB) is garbage. It's being replaced in the coming couple of months with something usable.

>> ' It seems that this result should only occur if the key is either entered incorrectly or for the wrong product,"

Correct.

>> "Is there anything else that could cause this?"

Only rare "system is broken beyond all recognition" type problems. It will, however, return other errors like TA_E_ALREADY_ACTIVATED if the customer has already entered a key and it's activated on that machine. So, look at your code and make sure you're not "swallowing" specific errors and returning generic, less useful errors.

Next steps:

1. Review your code, fix it to return specific errors.2. Still having problems? More information is needed:

a. OS customer is on.b. OS version customer is on.c. Code that is failing.d. Exact parameters passed to function.e. Exact return code from "failing" function.

See: https://wyday.com/limelm/help/faq/#useful-reports

Hi, appreciate the swift response as usual. I've just had a skype screen share with the customer and didn't see any problem with the way the key is being entered. After checking our software again I am certain that TA_CheckAndSavePKey returns TA_FAIL. I'm not sure if it makes a difference, but the product was previously successfully activated on that computer. The problem only started with a licence update.So the next step I will take will be to add a complete set of logging to every DLL function call so you can see exactly what is happening. Do you have anything like that already available?Regards,Robin

So we added some logging, here it is:1/8/2019 2:20:46 PM : TA_PDetsFromByteArray: pdets="<pdets>", pdets_len=8108, result => 01/8/2019 2:20:46 PM : TA_GetHandle: product_guid="xxxxxxxxxxxxxxxxxxxxxx.yyyyyyyy", result => 331/8/2019 2:20:46 PM : TA_IsActivated: handle=33, result => 171/8/2019 2:20:46 PM : TA_IsActivated: handle=33, result => 171/8/2019 2:20:46 PM : TA_IsActivated: handle=33, result => 171/8/2019 2:20:46 PM : TA_GetPKey: handle=33, lpValueStr="XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX", cchValue=256, result => 01/8/2019 2:20:46 PM : TA_IsActivated: handle=33, result => 171/8/2019 2:20:49 PM : TA_IsActivated: handle=33, result => 171/8/2019 2:20:49 PM : TA_GetPKey: handle=33, lpValueStr="XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX", cchValue=256, result => 01/8/2019 2:20:49 PM : TA_IsActivated: handle=33, result => 171/8/2019 2:20:57 PM : TA_CheckAndSavePKey: productKey="XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX", flags=1, result => 11/8/2019 2:20:58 PM : TA_IsActivated: handle=33, result => 171/8/2019 2:21:36 PM : TA_CheckAndSavePKey: productKey="XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX", flags=1, result => 11/8/2019 2:21:36 PM : TA_IsActivated: handle=33, result => 171/8/2019 2:21:37 PM : TA_IsActivated: handle=33, result => 171/8/2019 2:21:37 PM : TA_IsActivated: handle=33, result => 17

As you can see TA_IsActivated returns 17 which means the customer appears to be in a VM, but TA_CheckAndSavePKey does not have this error code so just returns 1 (TA_FAIL). Our implementation misses the 17 because if TA_IsActivated fails we don't check why we just continue assuming the product is not activated. Questions:1. Would it make sense to return 17 from TA_CheckAndSavePKey?2. I'm not sure how the Windows Hyper-V works, but this is the second customer we've had where simply having it turned on throws up error 17. Is it actually true that this already means Windows is in a VM, or is the system simply being cautious in this case?Regards,Robin

>> "Would it make sense to return 17 from TA_CheckAndSavePKey?"

No. That function does what it says (checks & saves the pkey). Nothing else.

>> "I'm not sure how the Windows Hyper-V works, but this is the second customer we've had where simply having it turned on throws up error 17. Is it actually true that this already means Windows is in a VM, or is the system simply being cautious in this case?"

Nope, Hyper-V is a hypervisor, and even the "base system" is running under the VM. They can stop running under the VM by turning off Hyper-V.

Covered in the FAQ: https://wyday.com/limelm/help/faq/#in-vm

>> "Would it make sense to return 17 from TA_CheckAndSavePKey?">No. That function does what it says (checks & saves the pkey). Nothing else.But then why does it fail? You explictly said earlier in this thread that it would only fail if the key was incorrect or for the wrong product. Now it seems it can also fail when in a VM, in which case why not return an error code to indicate that?

Likely because you're using a version of TurboActivate older than 4.0.2.

From: https://wyday.com/limelm/api/ta-changes/

"TA_CheckAndSavePKey() now returns TA_E_ALREADY_ACTIVATED instead of TA_FAIL if you try to use a new product key if your app is already activated."

Don't use static version of TurboActivate. Always use the dynamic version. And here's how you tell which version you're using: https://wyday.com/limelm/help/faq/#get-version