Below are some of the more frequently asked questions about LimeLM, TurboActivate, and TurboFloat. These questions are answered elsewhere in our extensive help documentation and forums, but we've decided to highlight a few of the more common questions asked despite the answers already existing:
No, your app does not need an internet connection when your app is running even if the customer activated using online activation. And if you never want the customer to activate online, you can give them the option to activate offline.
TurboActivate verifies whether the activation data is valid locally, without needing to be connected to the internet, using asymmetric cryptography. This is described in the "Type of software licensing" article; specifically, in the "Hardware-locked licensing" section.
You can, of course, require that your app re-verifies with the activation servers every X days. You can do that by using the
IsGenuineEx() function. However, using this function is not required. You can completely validate the license "client-side" without ever contacting external servers.
Before you do anything, always use the latest version of TurboActivate. We fix bugs and add features all of the time. And we're continually improving our computer "fingerprinting algorithm" — our proprietary algorithm we use to accurately tell computers apart.
If you're using the latest version of TurboActivate, and the customer is still reporting being "deactivated", then 1 of 3 things is happening:
They're running your app on a virtual machine: If the customer is on a virtual machine then the underlying hardware can change. And thus the "computer fingerprint" can change. This is especially true for virtual machines on Amazon services (and other VPS services). The solution is to use TurboFloat which is specially constructed to handle virtual machines (and many other business cases).
They've significantly changed their computer: if they're really using the same computer, and TurboActivate is reporting they're no longer activated, then they have changed their computer components so much that TurboActivate correctly sees the computer as different. TurboActivate can handle "routine" maintenance to a computer (replacing hard drives, updating the operating system, replacing less critical components), but some changes are seen as a different computer (replacing the CPU, motherboard, etc.).
They're lying to you in order to get free licenses: If you can rule out #1 and #2, then it's very likely it's just a case of the customer lying in order to get free usage of your app on more computers. If you're using the
IsGenuineEx() function in your app to re-verify with the servers every X days, then even if you deactivate the customer's activation in LimeLM, and they're lying to you, then this malicious customer will get at most X days of free usage of your app on the original computer (before TurboActivate deactivates it).
TA_E_INET" or an "
The standard debugging principles hold for this. If you're getting
TA_E_INET (return code 4 is
TA_E_INET, see TurboActivate.h) there's a 99.99% chance it's because the customer has a restrictive internet policy (i.e. blocking all traffic or all but a set of whitelisted domains/IPs).
But before you do anything ensure the following:
Always use the latest version of TurboActivate.
Make sure the customer is actually connected to the internet. TurboActivate is pretty great, but it's not magic; it needs an internet connection to do online activation.
Have the customer open Internet Explorer. Have them type "https://wyday.com" in the browser window. Does it work? If not, there's your problem. Stop and fix it.
Don't use Firefox. Don't use Opera. Don't use Chrome. Always use Internet Explorer for that test. Why? Because TurboActivate uses the same proxies that Internet Explorer uses. So if the customer screwed up the proxies you'll be much more likely to see it in Internet Explorer.
If contacting "https://wyday.com" works unmolested in Internet Explorer (i.e. no junk being inserted into the communication) and TurboActivate is still returning TA_E_INET in C/C++ or throwing and InternetException in another programming language, then you can be fairly sure the problem is on that computer, and not in the LAN or the wider internet.
What does that mean? It means that a firewall, or an anti-virus/anti-malware program, or some other junk on the computer is blocking or "filtering" communication to/from your app.
How do you fix it? It depends. The quick solution: disable the junk. Turn off the firewall. Turn off the anti-virus/anti-malware junk. Try it again. Does it work? If so, you found the source of the problem. Now you just need to figure out how to configure the firewall/anti-virus/anti-malware to add your app and/or TurboActivate to their whitelist (or exclude it from whatever filtering that/those program(s) are doing).
Follow the instructions above, but replace "Internet Explorer" with "Safari".
For the instructions above, but replace "Internet Explorer" with whatever browser you happen to have.
Also, on Linux, valid CACerts must be installed on the machine and must be installed in a sane location. TurboActivate checks for the CACerts in the following locations and stops at the first one found (whether or not it contains valid and up-to-date certificates):
TA_E_INETor InternetException? (And you followed the above instructions.)
Did you follow the instructions above and TurboActivate is still returning
TA_E_INET (or throwing an InternetException)? Now it's time to break out WireShark and give us logs of the communication to/from your app so we can see where things are going off the rails.
In the meantime, have the customer activate your app offline.
TA_E_ENABLE_NETWORK_ADAPTERS" or throwing the "
EnableNetworkAdaptersException" exception, why?
TurboActivate needs to read all the components of a computer to get an accurate "fingerprint" of the computer, and that includes all real (a.k.a. non-virtualized) network adapters attached to the computer.
On Windows 8 / Windows Server 2012 and newer, TurboActivate can utilize improvements to the Windows API and Windows Drivers requirements to read network adapters even when they are disabled. So, if your customer is getting "
TA_E_ENABLE_NETWORK_ADAPTERS" or "
EnableNetworkAdaptersException" on Windows 8 or newer, then the first thing you should do is have them update their network adapter drivers.
On Windows 7 / Windows Server 2008 R2 and older TurboActivate cannot read network adapters if they have been disabled in the "Network Connections" control panel. There are a few solutions to this customer-inflicted problem:
If you're using the TurboActivate Wizard, have the customer run the wizard again with admin permissions (right click, click "Run as administrator"). When TurboActivate is running in an admin process it has permission to enable/disable network adapters. So TurboActivate will temporarily enable any disabled network adapter, read its hardware properties, and then disable it again.
If you're not using the TurboActivate Wizard, you can have the customer run your app as an admin and it will do that same thing (enable the disabled adapters temporarily, read their hardware, and then disable them again).
If you want to let the customer handle it manually, then you can tell them to open the "Network Connections" control panel:
There are multiple ways to open the "Network Connections" control panel, but the fastest way is to type "NCPA.cpl" in the start menu and press Enter. Then, for any disabled (or greyed-out) adapters, right click them and click "Enable":
After enabling a network adapter is will no longer be greyed-out. Also, note that the adapter doesn't need to be connected to the Internet, like in this example, it just needs to be Enabled. Whether the adapter is connected to the Internet or not is unimportant:
If you want to automatically show the "Network Connections" control panel directly from your app, you can do it by launching "NCPA.cpl". So, in C# that might look like this:
ProcessStartInfo startInfo = new ProcessStartInfo("NCPA.cpl"); startInfo.UseShellExecute = true; Process.Start(startInfo);
While it's best practices to keep network adapters enabled at all times, even if there isn't an active internet connection, customers aren't forced to use these best practices. In other words, customers can disable the network adapters after TurboActivate successfully reads them, and TurboActivate will remember them for a while. This way customers won't be prompted to enable the network adapters every time they run your application.
Of course, the solution to never be prompted is to leave the network adapters enabled all of the time. If a customer is disabling network adapters in an effort to shut off the internet there are better and more secure ways to do it:
For Ethernet connections: unplug the ethernet cable.
For WiFi connections: Disconnect from the network. Or, if the customer doesn't want the WiFi to talk to any network, put the WiFi adapter in "Airplane Mode".
If the customer is on Windows, and they're certain they're not running in a virtual machine, but TurboActivate says they're running in a VM, then it's almost always the case that the customer has "Hyper-V" enabled and they either don't know it or don't understand that with Hyper-V enabled they are running inside a VM. It's just the nature of Hyper-V (a ring-0 VM) that even the "base" operating system is running inside the VM.
A customer can check if they're inside a VM by opening the "Turn Windows Features on or off" dialog. On earlier versions of Windows you can find this in the Control Panel / Uninstall Programs, on the right hand side of the window. On Windows 10, you can just Settings and type "Hyper-V" in the search box and it will pop-up in the list of options:
After clicking that, the "Turn Windows features on or off" dialog will appear. If the "Hyper-V" node is checked (or, more specifically, the "Hyper-V Hypervisor" node is checked) then you're in a virtual machine:
If you don't use Hyper-V or you don't want to run inside of a virtual machine, then uncheck "Hyper-V", click "OK" and restart your machine. After doing that you will no longer be inside of a virtual machine.