>> "Ok Here is an example from a customer who got an Error Code #1:"Thanks, i got it sorted. My firewall was blocking connection to wyday.com.""
Something is odd here. On an Internet Error (which could be caused by literally thousands of different things -- hence the impossibility of logging it) TurboActivate will *always* return TA_E_INET. Not TA_FAIL (1). It will never return TA_FAIL on an internet error.
So, what does that mean?
It could mean the customer is mistaken, or lying (probably just mistaken). Or it could mean your programmer did not correctly take into account error codes returned by our functions and it returning a generic error code (TA_FAIL) instead of the actual error code the function returned.
I don't know which one of our customers you are, so I can't dig into our support requests and see if we've already talked about this with you and/or your programmers. However, we've had a number of customers run into the same problem. Namely, they don't stop on the first error code. But rather they barrel through a handful of TurboActivate functions and only return the error code of the last function that returns an error or just return any error code.
For example, one of the most common mistakes we see when we investigate these type of "TurboActivate doesn't give good enough errors" type reports we see one of the following types of erroneous code blocks:
HRESULT myActivateFunc(TCHAR * pkey){ TA_CheckAndSavePKey(my_handle, pkey, TA_SYSTEM);
return TA_Activate(my_handle);}
Or...
HRESULT myActivateFunc(TCHAR * pkey){ HRESULT hr = TA_CheckAndSavePKey(my_handle, pkey, TA_SYSTEM);
if (hr != TA_OK) return hr;
return TA_Activate(my_handle);}
Both of those chunks of code are bad. They might work. And when they do, everything is great. However, when they fail you don't know what function is failing (or, in the first case you don't even bother checking if the first function is failing).
Is your code like that? I don't know, at this point I'm just speculating based on all the other "bad error code" reports we've had all follow that pattern.
Send us a snippet of your code roundabout where the customer was getting the error and we can give you advice on how to better write the function. You can send it over to support@wyday.com and we'll take a look at it this week.
>> "For example here is the type of stuff I want to be able to detect:
1. If TurboActivate.dat can't be accessed because of permissions2. If the internet is being blocked, because of a Firewall3. If there is no access to the internet"
The good news is that we already have error codes for those. Namely, TA_E_INVALID_HANDLE, TA_E_PDETS for an invalid path to the product details file or corrupt product details file.
For 2, 3, (and the thousand other cases that constitute an "internet error") TurboActivate returns TA_E_INET. For help on debugging internet errors see: https://wyday.com/limelm/help/faq/#internet-error
We cannot build internet diagnostics into TurboActivate. Why? Because there are literally thousands of ways the internet can fail. And only a tiny percentage of those internet failures are visible from a client machine running as a limited process. We can tell *that* the internet is failing, but most of the time we cannot tell *why* the internet is failing. Hence the FAQ entry.
