8 years of random deactivations!Answered

I've been a customer of wyday since 2016 and the one thing that has plagued us throughout the last 8 years is customers complaining that their software deactivates without any reason.

We ALWAYS ensure we are using the latest version of Turbo Activate but we never seem to resolve this issue.

I can only speculate that either your system is flawed or we haven't implemented it correctly.

Let me explain what we actually need, and you can advise accordingly.

Customer needs to activate the product, this can be online or offline, we don't mind.  The product will be given an expiry date such as 1 month, 3 months, 12 months from todays date.

We want the software to run continuously for that period without deactivating.

We have also had a lot of customers experience the error stating they were running a virtual machine, to bypass this we have allowed product keys to be activated on virtual machines - we know you don't recommend this but we are sick of trying to resolve this issue.

What we could really deal with here is some one on one support rather than trying to fix it ourselves.  I think 8 years is long enough to say “WE GAVE IT OUR BEST SHOT” and if you can't help us sort this once and for all, it must be time to find another licensing provider.

Yeah, we can help. If you're using the latest version (currently 5.0.2), then we'll be happy to dig in.

It sounds like you're asking about different things. If this is *all* about VMs, then we have a FAQ about it. Long story short: we detect VMs accurately. And we give you multiple choices in what to do with them (disable the VM, allow activations on VM, force use of TurboFloat, etc).

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


If this is a separate issue, namely, a customer is activated fine then one day they become deactivated, then this is a genuine issue. The first thing we'll ask to look at is your code. The reason is that this sounds like a common misunderstanding of how our API works, and your handling the error from IsGenuineEx incorrectly (namely, on TA_FAIL from that function you shouldn't tell them they're deactivated, instead you should call TA_IsActivated() to check if the failure is because it's a different computer or because the customer has gone X+Y days without reverifying)


If your code looks good (we actually need to see it so we can help you – We don't need to see app code-- just code related to your licensing). Then we'll need to see a representative product key.

In other words we need to see a product key that's allowed for only one machine that a customer reports that they were deactivated and they didn't change machines. Not a key that's allowed for multiple machines. Just one that a customer is reporting becoming deactivated and can't immediately reactivate.


To sum up:

  1. Use the latest TA.
  2. VMs are accurately detected and we provide multiple options for customers, including ignoring it if you want.
  3. Make sure your code is correct. My guess is that this is the problem.
  4. Provide a representative product key of this problem.


The handful of times we've had this “problem” reported over the years it was either incorrectly written code (not handling TA_IsGenuineEx return codes correctly) or an end-user lying about it being the “same computer”.

But provide us enough information and we'll help.

, edited
Answer

That's a good start, thanks for providing the code. There's several problems with the code and also much more information is still needed:

  1. What exactly is a customer getting for an error?
  2. What are you doing to trouble-shoot it?
  3. Do you have a representative key?
  4. What's the actual version of TurboActivate and systa are you using?

It does look like you're handling the result for the IsGenuineEx() wrong but in an atypical way. Here are a few things that you need to fix:

  1. evt.ErrorObj != null case in onIsGenuineEx()
  2. The !isActivated case in onIsGenuineEx() – you should call that function but with another callback so that you can correctly prompt the user to reverify immediately. This might be the source of all your problems (because a customer can be “expired” and never have a chance to reverify with the servers).
  3. Also the whole expiry date rube-goldberg machine looks like you're just recreating what TurboActivate already does (but without any of the reliability of TurboActivate). I don't know why any of this is necessary. If you want them to reverify every X+Y days, that's exactly what IsGenuineEx() does.

Long story short, this is fixable, and most of the fixes just depend on removing large chunks of code, and correctly handling errors.

We also need more information on top of the fixes. Why? So we can tell you exactly what error path the customer went down.

The customer isn't getting an error message as such, they are being reverted to trial mode.

What should we be doing to troubleshoot it.  We don't know what causes it or how to get any information on why it happened?

What is a representative key?

What is a representative key?

A product key where a customer has reported this behavior. They've activated successfully, then become “mysteriously” deactivated, you've deactivated them server side for the same key, and then they've re-activated again.

We can look at the key and see the machine data – this is so we can confirm either the customer is lying (i.e. moving to a different machine and just lying about it being the same machine) or your code is broken (which, scroll up and I've already suggested a whole bunch of things you should fix).

What should we be doing to troubleshoot it.  We don't know what causes it or how to get any information on why it happened?

Start with all the things I already suggested.

We are working on those changes, but here is a representative key you asked for.

Customer is being asked to enter their serial number again but the customer states that the serial number no longer works.

DS7N-P6HP-RHVE-Q77V-PMKT-BZXB-WWTA

Hello,

I am the sole developer on this project and apologize for being here late as I was involved in some personal matter for a long time. I think I missed few lines of relevant code inside onIsGenuineEx() function for IGRet_InternetError before. Please check this link again  https://www.dropbox.com/scl/fi/p8d28zh7eq6k8zc9bzw1v/Wyatt-Code-full.as?rlkey=u4ok3i10y3wug1g3wnvpg0wlt&dl=0

 Let me reply to your queries.

1) evt.ErrorObj != null case in onIsGenuineEx()

We are showing the message that something went wrong, so contact the support. The features were disabled and showed some options like buying, activating and offline activating. I don't think this is an issue for our problem.

2) The !isActivated case in onIsGenuineEx() – you should call that function but with another callback so that you can correctly prompt the user to reverify immediately. This might be the source of all your problems (because a customer can be “expired” and never have a chance to reverify with the servers).

We are not instantly showing the message to connect to the server because in the past, when we did this, lots of users complained that they needed to connect to the internet randomly to use the application even when they were in a valid period. You have to understand our scenario. Lots of our users use the application where the internet is not available and we give options to buy the license for monthly, quarterly, half-yearly or annually. And it is embarrassing for us to ask the users subscribing quarterly, half-yearly or annually to connect to the internet every month. We would have even done this if it was connecting to the server on the renewing day only as passed in the function ta.IsGenuineEx(renewingDay, graceDay, false); But in the past, it was randomly contacting LimeLM server well before verifying/renewing day. Thus, we try to check with the expiry-date field by using TA_GetFeatureValue() function and use our own built-in IsDateValid() function to check whether the application is still under a valid period. If not, then only we show them that they must connect to the internet anyhow to reverify with the server as our last option which uses TA_IsGenuine() function underneath. 

Changing as you have suggested is not a big deal but we are afraid we 

3) Also the whole expiry date rube-goldberg machine looks like you're just recreating what TurboActivate already does (but without any of the reliability of TurboActivate). I don't know why any of this is necessary. If you want them to reverify every X+Y days, that's exactly what IsGenuineEx() does.

Not due to the reliability of TurboActivate but due to the lack of a function IsDateValid() in AS3/Air. Like mentioned above, we were getting reports that it was trying to contact LimeLM server even well before the valid period, i.e., before another time it should verify with the server again as the value passed as renewingDay inside IsGenuineEx(renewingDay, grace, false);

https://wyday.com/forum/t/3587/isdatevalid-equivalent-function-adobe-air/#post-17435

Looking forward.

Thanks
BP