Start10 Losing Registration Status in Citrix

Hello,

 

I am creating a post here because we have recieved no answer on an official support ticket submitted through Stardock support channels (atlassian/jira platform) for two weeks and it's an ongoing problem heavily impacting our production systems.

 

We have a Citrix VDI deployement of 120 non-persistent multisession machines that has recently started to randomly lose registration status with Start10 in high volums, 50, 60, 70 machines at a time. This has been happening for quite some time, though until recently only during our weekend scheduled restart of all virtual machines. Now however, all users on affected machines can't use their start menu when this happens until we manually register again on every machine.

 

I appreciate any advice or potential solutions to this problem.

144 views 3 replies
Reply #1 Top

That pattern reads like activation seat exhaustion rather than anything failing on the machines themselves.

In a VDI or Citrix deployment licences are counted per instance, and the key carries a fixed number of concurrent activations. If your non-persistent instances come back with a different SID, MAC or hostname, each one looks like a new PC and takes another activation off the key.

Nothing returns those seats unless the instance is deactivated before it goes away. A weekend restart of all 120 machines consumes a batch that never comes back, which fits what you saw: it started at the scheduled reboot, and once the pool ran low it began hitting machines during the week too.

For non-persistent instances both halves need to be scripted, activation at logon and deactivation at logoff. Both binaries sit in the Start10 program folder, and for Start10 the product ID is 2623.

Activate: SASUpgrade.exe -prodId=2623 -prodName="Start10" -company="Stardock" -ver="YOUR_VERSION" -email="YOUR_LICENSING_ADDRESS" serial="YOUR_KEY"

Deactivate: SdDisplay.exe -deactivate -prodID=2623 -prodName="Start10" -company="Stardock" -prodVer="YOUR_VERSION"

The company value is literally Stardock. Putting your own company name there is the most common reason a scripted activation fails.

Two things worth checking alongside that. Activation should not be baked into the golden image, because the license.sig it writes to \ProgramData\Stardock\Start10 is overwritten when the image deploys. That same file is how you confirm a given machine is genuinely activated.

The seats already burned by destroyed instances will need releasing from your account page, otherwise the logon script has nothing left to draw against.

Reply #2 Top

Hello,

Sorry to hear you’re experiencing this issue. In many cases, this happens because a third‑party cleanup or optimization tool is running on a schedule and removing the activation signature file during its automated cleanup cycle. When that file gets deleted, the product will prompt for activation again.

Please check if you have any cleanup or optimization software installed and review their automatic cleanup settings. If you find one, add an exception so it does not touch anything inside the Stardock license directory.

Some common applications that perform scheduled cleanup include:

  • EaseUS tools (CleanGenius / Partition Master Clean Hub) – known to scan and remove junk files automatically.

  • CCleaner

  • Glary Utilities

  • Advanced SystemCare

  • Wise Disk Cleaner

  • BleachBit

  • Ashampoo WinOptimizer

If any of these (or similar tools) are running periodic cleanups, please configure them to ignore Stardock-related files to prevent future activation prompts.

Thank you.


Basj,
Stardock Community Assistant.

Reply #3 Top

Hi, 

One question regarding your answer, you say Logon and Logoff, does that mean that for example with 10 users working on a machine, the registration script has to run 10 times, once for each user that logs on?

Because until now it ran as a Startup script at machine launch and activated Start10 for every user connecting to the machine. This worked fine for years until the recent errors started showing up.

We don't have the Shutdown script configured however, we will try that and see how it behaves. Our "-ver" parameter also stayed at 1.60 while we're using currently version 1.98.