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
TA_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
TA_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.
On Linux and BSD (excluding macOS) valid CACerts must be installed on the machine and must be installed in a sane location. TurboActivate, TurboFloat, and the TurboFloat Server check 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).
SSL_CERT_FILE" environment variable.
SSL_CERT_FILE" environment variable.
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 modern Windows (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 old, soon to be deprecated, Windows (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".
Before you do anything, are you using the latest version of TurboActivate, TurboFloat, or TurboFloat Server? If not, update to the latest version and try again. We're always improving our software including our ability to accurately detect VMs. Don't waste your time trying to track down bugs we've long since fixed. Update first.
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 a hypervisor enabled or a feature enabled that depends on Windows running under a hypervisor. It's just the nature of hypervisors (a ring-0 VM) that even the "base" operating system is running inside the VM.
There is absolutely nothing wrong with being inside a virtual machine. And our TurboFloat product handles virtual machines / hypervisor / sandbox / container scenarios perfectly. So, if the customer prefers running inside of a virtual machine, then integrate TurboFloat into your app.
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 any of the following nodes are checked, then the customer is inside a virtual machine:
Hyper-V Platform (and its sub-nodes: Hyper-V Hypervisor and Hyper-V Services)
Virtual Machine Platform
Windows Defender Application Guard (a part of Microsoft's anti-virus product that runs apps in virtual machines)
Windows Hypervisor Platform (Microsoft's partial-rebrand of Hyper-V)
If the customer would prefer not run inside a virtual machine, then they'll need to uncheck all of those options. Then they'll need to restart the machine. If after unchecking them, restarting the machine, and then starting your app again and TurboActivate still says the customer is inside a virtual machine, then it's very likely they have Intel's hypervisor enabled in their BIOS. They'll need to disable it.
TA_E_BROKEN_WMI). What does that mean, and how do I fix it?
If you're getting that error this means that part of the operating system is broken. This is usually caused by partial (and failed) driver installation and/or "cleaner utilities". The good news is that these errors can be fixed. Do each of the following steps:
Are you using the latest version of TurboActivate or TurboFloat? If not, upgrade your version of TurboActivate and/or TurboFloat first, then retry. If you're still getting the error, then continue to step 2.
Update all of your network adapter drivers. If you don't know how, google for generic instructions.
Remove all anti-virus software except Microsoft's Defender anti-virus. (Or if you're still using Windows 7 or Windows Vista, use Microsoft's Security Essentials -- the predecessor to Windows Defender). All 3rd party anti-virus products are junk: slow, bloated, expensive, and do more harm than good. Windows Defender is free and lean.
Remove any "cleaner" utilities. They are often poorly written and do more harm than good. The built in "Disk Cleanup" utility does everything (and more) compared to the adware and malware infested alternatives.
Next, open a command prompt with Administrative privileges. Like so:
Click the "Start button"
Right click "Command Prompt" and click "Run as administrator":
A "User Account Control" window will ask you if you want to proceed. Click "Yes".
Now you should have a command prompt window that, in the title bar" says "Administrator: Command Prompt":
Type the following commands (lines) one after another:
cd C:\Windows\System32\wbem mofcomp C:\Windows\System32\wbem\NetAdapterCim.mof mofcomp C:\Windows\System32\wbem\en-US\NetAdapterCim.mfl
The first command navigates to the directory where the files need to be fixed. The next 2 commands attempt to fix the necessary broken files.
Now open a PowerShell command prompt (which is different than a "cmd" prompt), and run the following command:
Get-WMIObject MSFT_NetAdapter -Namespace root\StandardCimv2
If you're on Windows 8, 8.1, or 10 (or equivalent Windows Server version 2012, 2012 R2, 2016, 2019, or "Windows Server"), you should get a full list of your network adapters whether they're connected to the internet or not. If you're on those Windows versions, and that PowerShell command gives you an error, then you still have WMI corruption. Contact your system admin and tell them to fix it. Or re-install Windows for the easiest fix.
More resources for determining how your WMI registry is corrupt:
If you're having a problem using TurboActivate, TurboFloat, or LimeLM and it's not answered by the rest of the FAQ or our other documentation, then you need to provide enough information about the problem (and about the circumstances surrounding the problem) to us for us to provide useful support. Without enough information, we can usually do nothing.
Here are the steps to either fix the problem yourself or provide us with enough information to us to fix the problem:
We work on our products continually: making them faster, smarter, and better with each release. So, 9 times out of 10 your problem has already been reported and solved. All you have to do is use the latest version of TurboActivate, TurboFloat, or the TurboFloat Server in your app. You can get the latest versions on your API page.
If you're using the dynamic version of the TurboActivate or TurboFloat libraries (so, a .dll, .so, or .dylib file) then you can get the version information like so:
On Windows: Right click the TurboActivate.dll or TurboFloat.dll file, click "Properties", and then click the "Details" tab and you'll see the version number:
On macOS: Open a terminal session and then
cd into the directory containing either libTurboActivate.dylib or libTurboFloat.dylib and then use the
otool to get the version:
otool -L libTurboActivate.dylib
Which will output a number of lines including the version number:
libTurboActivate.dylib: @rpath/libTurboActivate.dylib (compatibility version 1.0.0, current version 4.1.1) ...
On Linux, BSD, etc: all other versions of Unix don't provide ways for us to embed meta-data (like version numbers) in the binaries we distribute. So determining whether you're using the latest binary is more tedious:
Download the latest TurboActivate or TurboFloat library from your API page.
Extract the files, open a terminal session,
cd into the correct directory
sha256sum commandline utility to get the checksum of the latest version of TurboActivate or TurboFloat:
Which will output something like this (make a note of the hash that is output in your terminal — you'll be comparing it against the hash of the version of TurboActivate or TurboFloat you currently are using):
Now repeat the
sha256sum process with libTurboActivate.so or libTurboFloat.so file you're using in your app currently.
Compare the hashes generated between the latest version and the version you're using. Are they different? Then you're using an old version of TurboActivate or TurboFloat.
Getting the version number for the TurboFloat Server is a good deal easier (and cross platform). Simply open a command window or terminal and run the TurboFloat Server instance with the
-v commandline option. For example:
That would output something like this:
Floating license server (TFS) v18.104.22.168
If you've determined you're using an old version of TurboActivate, the TurboFloat library, or the TurboFloat Server then you should update your app to include the latest versions before you do anything else.
Updating the TurboFloat Server is by far the easiest things to do (and you should do this first, before updating the TurboFloat Library in your app). This is covered here: Upgrading the TurboFloat Server instance.
Updating the TurboActivate and TurboFloat libraries requires a couple of steps (and it differs depending on the programming language you use). Broadly, you need to do 2 things:
Replace the library with the newer version: this is just what it sounds like. Replace the TurboActivate.dll, TurboFloat.dll, libTurboActivate.so, libTurboFloat.so, libTurboActivate.dylib, or libTurboFloat.dylib file included with your app.
Replace the integration files: each programming language has a different way of "talking to" the TurboActivate or TurboFloat libraries:
C#: Replace the "
TurboActivate.cs" and/or "
TurboFloat.cs" in your app with the one found in the
C/C++: Replace the "
TurboActivate.h" and/or "
TurboFloat.h" file in your app sources (found in the
API/C directory) and on Windows make sure you're linking against the newest "
TurboActivate.lib" and/or "
TurboFloat.lib" files in the
Delphi: Replace the "
TurboActivateUnit.pas" and/or "
TurboFloatUnit.pas" in your app with the one found in the
NodeJS or Electron: Replace the "
turboactivate.js" or "
turbofloat.js" file in your source code tree with the
API/NodeJS/turbofloat.js file. Also, replace the "
systa.exe" or "
systa" (or "
systf.exe" / "
systf" for TurboFloat) executable files from "
bin-[platform]/[architecture]/nodejs"". For example, for Windows, x64: "
Java: Replace all the sources in your app in the
src/com/wyday directory in your source tree with all the TurboActivate and/or TurboFloat class files found in the
Python: Replace the "
turboactivate" or "
turbofloat" directories in your source code tree with the
API/Python/turbofloat directories (which will also replace the "
__init__.py" and "
pip install --upgrade turboactivate
Xojo: Remove all the TurboActivate, TurboFloat, and Exception classes from your app. Then re-add all the Xojo classes from the
API/Xojo (Real Basic)/Import to your project" directory.
VB6: Replace both the "
TurboActivate.bas" and "
TurboActivate.cls" and/or "
TurboFloat.cls" and "
TurboFloatHelper.bas" in your app with the one found in the
VBA: Replace both the "
TurboActivate.bas" and "
TurboActivate.cls" and/or "
TurboFloat.cls" and "
TurboFloatHelper.bas" in your app with the one found in the
VB.NET: Replace the "
TurboActivate.vb" and/or "
TurboFloat.vb" in your app with the one found in the
Rebuild your app: After you've replaced the library files, and integration files, you need to rebuild your application so that it can properly load the latest version of the TurboActivate or TurboFloat library.
Now that you've integrated the latest version of TurboActivate, TurboFloat, or the TurboFloat Server with your app, you need to re-test whatever part of your app that was causing the problem. Are you still having a problem? Proceed to Step 2.
If after you've updated TurboActivate, TurboFloat, or the TurboFloat Server, and you've given the customer the new version of your app with those latest libraries, and the customer is still having problems, then you need to give us enough information to help.
Here is the minimum information we need:
What version of TurboActivate, TurboFloat, or TurboFloat Server are you using? You should be using the latest version (see step 1), but giving us the version number ensures that you actually went through the steps of first updating the libraries and tried to fix the issue yourself.
In addition to the version number of the build you also need to tell us the architecture of the build of TurboActivate or TurboFloat you're using (x86, x64, armv4, armv7-a, armv8, etc.).
What operating system is the customer running on?
The name of the operating system (e.g. Windows, macOS, FreeBSD, Ubuntu Linux, etc.)
The version of the operating system (e.g., Windows 7, or macOS 10.12.6, or Ubuntu Linux 16.04, etc.)
The architecture of the operating system (e.g. x64, x86, ARM, etc.)
What function is failing and what is the exact error code?
For example saying this is almost entirely to useless for us:
"The activation failed when the user clicked a button"
We didn't write your application and we can't tell you what the button actually does. It's better to tell us something like this:
"We called the function TA_CheckAndSavePKey() with the the product key XYZA-BRZY-.... and the flag TA_SYSTEM and it's throwing the exception PermissionDenied. But when we try to reproduce it on our machines we don't get that error."
Note how the better request include the function, what parameters were used, and what return codes or exceptions were thrown. This information is very important!
What do you expect to happen? Tell us what you expect to happen. This will help us explain what should really happen and/or correct misconceptions you might have about the expected behavior.
Give us the product key! If you or your customer is getting unexpected behavior surrounding activations then you need to provide us with the product key so we can actually look into things on the server-side.
Can you reproduce the behavior? If one of your customers is having a problem, can you reproduce the problem on your machines? Telling us whether you can or cannot reproduce the behavior is also useful information. Also, it gives you a chance to ensure you've collected enough information from the customer to make a useful report to us.
Now that you've prepared all of this information either post to our online forum or shoot us an email. Don't do both of those — do one or the other so we're not wasting time re-answering the identical question. Also, while we do have a phone number, technical questions take about 1,000 times longer to solve over the phone.