Known Issues and Workarounds

When upgrading from Sentinel LDK v.7.3 through v.7.8 to Sentinel LDK v.7.10, all non-English locales of Customer contacts and Channel Partner contacts in Sentinel LDK-EMS are converted to the English locale.

Note: You can ignore this issue if all of your Customer and Channel Partner contacts are set up to use the English locale or if you are not upgrading Sentinel LDK-EMS.

Workaround: A solution for this issue is provided in the technical note available here.

When a user clicks the link provided in an email (that is sent by Sentinel LDK-EMS) to display a scheduled report, the report is not displayed when the DNS server cannot resolve the server hostname present in the link. Instead, the message "This page can't be displayed" is shown.

Workaround: In the etc/host file on the user's machine, add an entry that contains the hostname and IP address of the Sentinel LDK-EMS machine.

Customers who were associated with a channel partner prior to Sentinel LDK 7.7 will not be visible in Sentinel LDK-EMS to the relevant Channel Partner user. However, the Channel Partner user will not be able create a new entry for an existing customer with the same email address as already exists in the EMS database. In this situation, the Channel Partner user will not be able to fulfill an entitlement for the customer.

Workaround: If the Channel Partner user cannot create the required customer in Sentinel LDK-EMS, the software vendor should handle the fulfillment of the entitlement for the customer.

After you upgrade to the latest version of Google Chrome or to Microsoft Edge version 95 or later, functionality related to protection keys is blocked if you access Sentinel LDK-EMS using HTTP mode. This applies to both the vendor portal and the customer portal.

Workaround: Switch Sentinel LDK-EMS to HTTPS mode.

The Sentinel Remote Update System (RUS utility) is not supported for Mac systems.

Workaround: To obtain a fingerprint, use Sentinel Admin Control Center.

When installing a different version of Sentinel LDK Run-time Environment (RTE) over an existing version on a Linux platform, the newly-installed hasplmd daemon is typically started automatically. However, in the following instances, the hasplmd daemon is not started automatically:

> When upgrading RTE version 8.13 or earlier to RTE version 8.15 or later

OR

>When downgrading RTE version 8.15 or later to RTE version 8.13 or earlier

Workaround: After installing the desired version of the RTE, do either of the following:

>Install the desired version of the RTE a second time.  After performing the second installation, the hasplmd daemon starts automatically.

OR

>Start the hasplmd daemon manually by entering the command: systemctl start hasplmd

Given the following circumstances:

>An RTE without legacy drivers is installed on a new machine.

>An RTE with legacy drivers is installed afterward on the machine.

An application that requires an RTE with legacy drivers will not operate successfully. During installation of the RTE with legacy drivers, no warning or error is generated.

Workaround: Using Admin Control Center, generate a diagnostic report, and contact Thales Technical Support.

Given the following situation:

> When the current state of an SL key is decoded (using SL License Generation API), the status of the container is shown as Secure Storage Id Mismatch in the Key ID column.

> The key contains a Product that is rehostable or detachable OR the Product license type is Executions or Expiration Date.

If the SSID (secure storage ID) of the container changes (for example, the container becomes corrupted or is deleted), the Product will be marked as Cloned and become unusable. In any other situation, the status Secure Storage Id Mismatch has no significance and can be ignored.

Given the following circumstances:

1.Windows is installed on a Mac machine with Boot Camp.

2.An SL license is installed in the Windows system.

The Secure Storage ID may change and cause Feature ID 0 to be flagged as "cloned".

Workaround: Do not install the SL license in the Windows system. Have your application consume a network seat from a cloud license.

The Sentinel LDK License Manager (process hasplms.exe) hangs intermittently and reaches a very high CPU utilization (approximately 1.9 GB).

Workaround: Protect the application using the latest API libraries and, if the RTE is required on the end user's machine, upgrade to the most recent RTE.

Given the following circumstances:

>A protected application was created using Visual Studio 2015

>Control Flow Guard is explicitly enabled in Visual Studio.

>The application links statically or dynamically with Sentinel Licensing API.

>The External License Manager (hasp_rt.exe) is not used.

>The application is run under Windows 10, or Windows 8.1 Update (KB3000850). (Not all Windows 8.1, only recent ones)

The protected application may fail.

Workaround: Include the External License Manager (hasp_rt.exe) with the protected application.

Given the following circumstances at a customer site:

>One machine has Run-time Environment version 7.51.

>A second machine has a version of Run-time Environment that is earlier than v.7.51.

>The customer performs rehost of a license repeatedly between the two machines.

>An update is applied to the license on either of these machines.

A rehost operation may fail with the message HASP_REHOST_ALREADY_APPLIED.

Workaround: Obtain a new SL license from the software vendor for the protected application on the target machine. Before attempting any additional rehost procedure, install the latest Run-time Environment on both machines.

Under Linux, if the user is running a Windows 64-bit protected application using Wine with default options, Linux may return a "debugger detected" error.

Workaround: When you protect the application using Envelope, disable User debugger detection for the application. (Note that disabling debugger detection reduces the overall security of the application.)

After a user connects a Razer Abyssus mouse and installs Razer drivers on a computer, the device manager on the computer does not recognize a Sentinel HL key if the key is connected to the same USB port where the mouse was previously connected.

This issue has been reported to Razer.

Given the following circumstances:

A Sentinel HL (Driverless configuration) key is connected to a USB host controller in default mode on QEMU emulator version 2.0.0 and Virtual Machine Manager version 0.9.5.

When the key is disconnected, the key continues to be displayed in Admin Control Center as a connected key. (However, a protected application whose license is located in the key does not execute after the key is disconnected.)

Workaround: Switch the USB controller to USB 2.0 mode.

Debugger detection is not provided for .NET applications.

Workaround: Implement debugger detection mechanism in the application code, and use Envelope to protect the methods that call these functions.

When a protected application is run under Novell ZENworks Agent, the application may generate "Debugger Detected" errors and may fail to run. This is because ZENworks Agent attaches to the started application as a debugger in order to monitor different events.

When a "Debugger Detected" error is generated, it is not possible for the protected application to determine which process is regarded as a debugger.

When a protected application detects that a debugger is attached, the application may generate multiple "Debugger Detected" message windows.

Given the following circumstances:

1. Install SL AdminMode licenses on your local machine.

2.Run IObit Advanced SystemCare Ultimate 12 to clean and optimize your machine.

3.Restart your machine.

Local SL AdminMode licenses may be missing or may be identified as cloned licenses. This is an issue with the IObit product. Thales has reported this issue to IObit and it is currently under investigation.

Workaround: Do not use the current version of the IObit product, OR do not use SL AdminMode licenses until this issue is resolved. (You can use SL UserMode licenses.)

When protecting a Java application, Envelope fails with the message "Serious Internal Error (12)".

Workaround: If this error occurs, protect the Java application using either of the following techniques:

> If the application contains JARs within a JAR/WAR executable, remove those JARs when protecting the executable with Envelope. You can add the JARs to the JAR/WAR executable after protection is complete.

> Create a JAR/WAR executable using only those classes that you want to protect. After applying protection, you can add other classes or JARs, or any other dependencies in the protected JAR/WAR executable.

Given the following circumstances:

> An Envelope project was created with Envelope version 7.3 or earlier.

>The project contains settings for a Java application.

>On the Protection Settings tabbed page for the Java application, you select the option to overwrite default protection settings.

The Allows grace period after failed license check check box should be modifiable. However, the check box cannot be changed.

Workaround: On the Advanced tabbed page, make any change to the MESSAGE_OUTPUT_MODE property, and then change it back. This forces Envelope to load an internal data structure that then makes the Allows grace period after failed license check check box modifiable.

Note: This grace period is not supported for Web applications.

Due to a known limitation in Java, if a background check thread becomes non-EDT, the background check (Abort/Retry/Ignore) dialog box may not appear. Envelope has been modified so that the error dialog prompted by the protected method in the protected application takes precedence. This has reduced the occurrence of the problem, but it has not eliminated the problem entirely.

For apps that target the .NET Framework version 4.6 and later, CultureInfo.CurrentCulture and CultureInfo.CurrentUICulture are stored in a thread's ExecutionContext, which flows across asynchronous operations. As a result, changes to the CultureInfo.CurrentCulture and CultureInfo.CurrentUICulture properties are reflected in asynchronous tasks that are launched subsequently.

If the current culture or current UI culture differs from the system culture, the current culture crosses thread boundaries and becomes the current culture of the thread pool thread that is executing an asynchronous operation.

When protecting a sample application implementing above behavior with protection type as "Dot Net Only", then the application behaves as expected. However, with protection type "Dot Net and Windows Shell" or "Windows Shell Only", the thread uses the system's culture to define behavior.

Workaround:

Do the following:

1.Use .NET Framework 4.5.

2.Use

CultureInfo.DefaultThreadCurrentCulture = new CultureInfo(...)

instead of

Thread.CurrentThread.CurrentCulture = new CultureInfo(...).

Given the following circumstances:

1.A .NET application is protected with Envelope.

2.The protection type includes Windows Shell (with or without the method level).

3.The application attempts to get a module handle using the following method:

IntPtr hMod = Marshal.GetHINSTANCE(Assembly.GetExecutingAssembly().GetModules()[0])

The handle returned may not be correct, and as a result, an error will be generated.

Workaround: You can call the GetModuleHandle system API of the Kernel32.dll to get the module handle.

For example:

[DllImport("kernel32.dll", CallingConvention = CallingConvention.StdCall, CharSet = CharSet.Auto)] private static extern IntPtr GetModuleHandle(IntPtr lpModuleName); IntPtr hMod = GetModuleHandle(Process.GetCurrentProcess().MainModule.ModuleName);

Given the following circumstances:

>A Linux application is protected with Envelope, with protection against debugging.

>The application calls the wait(&status) system call. This is equivalent to:

waitpid(-1, &status, 0)

The application may hang.

Workaround 1: Call waitpid for a specific child process pid (pid > 0).

Workaround 2: Disable the anti-debugging feature in Envelope. Note: This workaround significantly reduces the security of the protected application. Thales recommends that you consult with Technical Support before choosing this workaround.

>When running Envelope in a VMware Fusion 7.1.1 virtual machine on a Mac machine, if you save the protected application to an HGFS (Host Guest File System) volume, the application file is corrupted.

> When you run a protected application on a VMware Fusion virtual machine from an HGFS share, if the application requires write access, the error "unable to write to file" is generated.

The command line Envelope tool (envelope_darwin) now only works if Envelope.app (UI bundle) is in the same folder. To use the command line tool, copy Envelope.app to the folder that contains the command line tool.