When Your Software License Disappears Overnight
The first time this happened to me, I had a batch of MATLAB licensing scripts running across 40 lab machines, and three of them started throwing "License Server Not Found" errors at exactly 2:14 AM on a Friday. No one was in the building. No updates had been pushed. The service was running. The hosts file was clean. I spent six hours tracing it down to something that honestly should have been obvious. Here is what I learned that cost me more than I want to admit.
Uncovering The Mysterious Case Of The Vanishing License Number
License numbers don't actually vanish. What happens is usually one of three things: the daemon process gets orphaned after a failed Windows Update, the MAC address binding gets corrupted when a virtual machine snapshots are rolled back, or the license file itself gets silently overwritten by a misconfigured group policy that targets the product code instead of the installation path. I have seen all three. The first one is the most common in enterprise environments. The second one is almost always a virtualization team problem. The third one is a silent nightmare because nothing in the logs actually indicates a policy was applied.
How the Licensing Stack Actually Works
Most commercial software licensing systems work the same way under the hood, even if the vendors make it look proprietary. There is a license daemon process, a local license file, a hardware fingerprint cache, and a network activation endpoint. When any of these four components gets out of sync, the application can't reconstruct the credential, and it reports "license not found" even though the number you paid for still exists in the vendor portal. The fingerprint cache is the part nobody thinks about. It stores a hash of your NIC MAC addresses, disk serial numbers, and sometimes motherboard SMBIOS data. If that hash doesn't match what the daemon calculates on startup, the daemon refuses to load the license file. This is by design. It prevents license sharing across machines. What breaks the design is VM snapshot rollback. When you restore a snapshot, the virtualized NIC gets a new MAC address from the hypervisor pool, but the fingerprint cache still has the old one. The daemon sees a mismatch and silently discards the license. The license number is still there. The application just can't use it anymore.
Get the Full Details
The Diagnostic Sequence That Actually Catches It
Start with the daemon log, not the application error. On Windows, the license daemon for most vendors writes to a file in the installation directory, usually named something like flexnet.log or lmstat.log. On Linux it is typically in /var/log/ under a vendor-specific subdirectory. Look for lines containing "fingerprint mismatch" or "HWID changed." That is the smoking gun. If you don't see that, look for "daemon shutdown" followed by "no license found." That means the process died and restarted without its credential file. The third thing to check is the lmutil lmstat output or the vendor-equivalent status command. Run it as the service account, not your user account. Permissions matter here. I lost a whole Tuesday because I was running the diagnostic as my own privileged account and seeing a healthy license count, while the actual application service account saw zero licenses. Different tokens, different visibility.
My Specific Case and the Fix
The MATLAB incident I mentioned earlier. The logs showed clean daemon starts. No fingerprint mismatches. No crashed processes. But the applications couldn't see the licenses. I ran the status command as the system account and got a full valid count. I ran it as the service account and got zero. The culprit was a Windows feature update that had run overnight. It reset the permissions on the license directory, stripping the service account's read access. The daemon process could still start because it inherited permissions from its parent process token, but the license reader thread inside the daemon couldn't open the file anymore. The application asked the daemon for a license, the daemon said it had none, and the application displayed "license not found." The fix was one command:
icacls "C:\FlexNetPublisher\license" /grant "NT SERVICE\MATLABLAUNCHER":F /T That restored full control for the launcher service, which is the account the daemon runs under. I then ran a quick validation with the status command as that specific service account, confirmed the license appeared, and we were back to normal. The deeper fix was adding a scheduled task that runs on every Windows update completion, checks the license directory permissions, and restores them if they changed. I wrote it in PowerShell with a before-and-after Get-Acl comparison. It takes about four seconds to run. It has prevented this exact failure mode ever since.
What This Approach Misses
This diagnostic method assumes you have access to the daemon log and can run the status command as different service accounts. If you are dealing with a cloud-hosted license manager where the vendor controls the underlying VM, you won't have either of those. In that scenario, the only reliable path is opening a support ticket with the activation ID and asking them to check the license state on their end. It also doesn't help with expired subscriptions. The licensing stack treats "expired" and "not found" as different error states, but the application UI often conflates them. If your subscription lapsed, the daemon knows it. The log will say "license expired" not "license not found." If you see that message, you are not dealing with a vanishing number. You are dealing with a billing problem. Hardware changes are another edge case where this method falls short. If someone physically replaced a network card or moved a machine to a different subnet with a different licensing policy, the fingerprint change will look identical to a VM snapshot rollback. The fix is the same either way, but the root cause determines whether you need to re-register the hardware or just refresh the snapshot.
Prevention Is Cheaper Than Diagnosis
The three things I recommend setting up before the next incident, not after: First, add a daemon health check to your monitoring. Something that queries the license count every five minutes and alerts when it drops below the expected threshold. The alert should include which service account the check ran under. Second, take a permissions snapshot of the license directory once a month and compare it to the current state. A simple Get-Acl dump saved to a log file is enough. You won't notice incremental permission drift otherwise.
Third, document the exact service account each license daemon runs under. You would be surprised how many environments have three or four different service accounts handling licensing, and only one of them actually has the right to read the credential file. None of these prevent the issue from happening. They just make it visible the moment it happens instead of three hours after the fact.
