imageToday I was asked to assist in getting an Excel Add-In to work on Citrix XenApp.

The application was packaged into a Thinapp by one of our package engineers.

However when testing the Add-In on Citrix XenApp the following message appeared:


Apparently this application does a license check that fails when run from another server (how bad).

Before we go on: I would like to make clear that my goal is not to be able to use an application without license. I am just trying to make it work within the customer’s environment.

The application consisted of an xla (Excel Add-In Sheet) and two Dll’s called analyse.dll and analyse12.dll.

It seemed logical to me that the license check was in the Dll’s and that there were two versions: one for Excel 2003 and one for Excel 2007 (version 12) and possibly 2010.

I loaded analyse.dll in Ida Pro so I could analyze it.

The exports Tab shows a few exports that are common to XLL Files:


Inside the Dll there was a lot of trace/debug output, like this:

So I looked into sub_9A6E9AD to see if we could output this trace info:

sub_9ADA1F6 is a function for registry access:

From this code I concluded that if a DWORD registry value Dumplog (Value 1) exists in the application’s registry key (HKLM\SOFTWARE\Analyse-it\Analyse-it for Excel\1.0) a logfile would be written to the Temp directory.

The logfile was helpful in determining what happended:

checking registry access

That confirmed the computer check, but where does it come from?

Again the debug output was helpful:

Let’s have a look inside the check, sub_9A6AFDB (only showing the relevant piece):

The location of the Windows directory is retreived and then the volume serial number is requested for that volume.

The obtained serial number is compared to the serial that was saved during activation:

If we analyze the code above we can determine that a registry key is accessed in the HKEY_CLASSES_ROOT hive (-2147483648 = 0x80000000 in HEX which is the constant for HKEY_CLASSES_ROOT)

The key is Excel.App and the value is Flags32d.

The value of this key on the machine that had been activated matched 14065cba and was also the machine’s volume serial.

So the solution was there: I placed the Flags32d value in the ThinApp and in the package.ini I added the following line:

Now the application worked nicely on my testmachine (even though it has a different volume serial number):


On the production XenApp however the Thinapp failed!

It took me some time to realize why, rember this code?

It retrieves the Windows directory and application that are not Terminal Server aware have the Windows directory redirected to their User Profile!

In this case the User Profile was on the H drive so I change the package.ini to:

And not it worked nicely!

And a small PS to developers: First of all: License check’s don’t work at all, removing them is often very easy. Secondly license checks often do more harm than good. If a bug in the license check hurts a paying customer what have you accomplished? In this case there are at least two bugs (or bad design) in only a few lines of code!