We had this come up yesterday. I'm not sure I've got the full story from our support rep, but here it is:

After installing an update to our software by downloading and unzipping the .EXE, the customer was getting a "User count exceeded" error message on program startup on their workstations. This happens when there are no users in the program.

The program runs fine from the server and shows the correct serial number and number of current/licensed users in Help->About->System Info.

Our software and the DF 17.1 client are installed to a network share.

The workstations are running Windows 10 1903 with Comodo MAMMOTH Client Security 11 antivirus.

The server is running Windows 2012R2 with Comodo MAMMOTH Server Antivirus for Servers 11.

After trying to re-install the 17.1 client and license files and moving them back to a prior version of our 17.1 application .EXE, support rep tried updating them to an 18.2 version of the software and got the same results.

By the time it got handed off to me/their IT (who were asked to re-apply the appropriate permissions to the client folders, even though they seemed ok and all indications were that that was not the problem, as we used the same user account on the server where the program was working and on the workstations where it wasn't), there was an interesting side note: Database Builder and Database Explorer would work fine on the workstations. Indeed they would show the correct license file/# user information in Help->About->System Info just as our program was on the server.

After a lot of trial and error, I seemed to narrow it down to two possibilities. Our main application wasn't signed; normally it is. This was a (soon to be fixed) failure in our automated build process. And Comodo had the "Enable realtime scanning of files on network" box ticked.

After getting the .EXE properly signed and disabling the network scanning, the VDF 18.2 version of the program started working just fine on the first workstation.

Moving on to the second workstation, I changed the setting in Comodo, and still got the "User count exceeded" error on the second workstation. Did I forget something else that I did on the first workstation that was actually the solution? IDK

I moved forward by installing the 19.0 client and (compiled, but technically unreleased ATM) 19.0 version of our program. It worked on both workstations. Success after only 2.5 hours of fumbling around!

I highly suspect the antivirus, though I couldn't find anything in the Windows Event Logs or the antivirus itself to indicate that Comodo thought it was stopping some nefarious activity.

So I don't know if this is possible, but it seems like it would be helpful to have a "More details" button or some changes to the errors that are generated that would give us more diagnostic information, where possible, including:

  • Path and filename of the license files
  • DF version of the license files
  • Max users/current # users
  • If write permissions was not granted for the .DFR/.CFG a "write permission required" error rather than a "user count exceeded" (if that is what it does now)
  • If it is possible to distinguish between all licensed users actually in use vs. other conditions (AV locking entire file or otherwise blocking access?) this information would be helpful
  • If VDFDAEMON.EXE fails in some unexpected way (e.g. AV kills the process) then a "Failed to initialize user counting system" error or something like that.

I've updated our own internal KB so support reps have more diagnostic steps to help narrow down future problems, but different/better errors in this area might be helpful to give us a head start in identifying the problem.