Known Issues
The following known issues exist in Sentinel RMS Envelopev1.2:
Tracking ID | Description |
LDK-6695 | When the "Debugger Detected" error is generated, the protected application cannot determine which process is regarded as a debugger. |
LDK-8850 | When the protected application detects that a debugger is present, it may generate multiple "Debugger Detected" message windows. |
SM-15325 |
If the application uses a Sentinel RMS Envelope-protected DLL, the license may not be released on application exit. This problem occurs when the general recommendations are not followed for protecting applications. To resolve this: >You may disable the background check. However, this is NOT recommended due to the possibility of licensing misuse. >Wait for the key lifetime (KLT) to expire. The Sentinel RMS License Manager releases the license on KLT expiration. |
SM-19968 |
The lease mode is not supported with a protected DLL. |
SM-554 |
For applications 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 the asynchronous tasks 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 the above behavior, the thread uses the system's culture to define behavior. The workaround to fix this is to do the following: 1.Use .NET Framework 4.5. 2.Use CultureInfo.DefaultThreadCurrentCulture = new CultureInfo(...) instead of Thread.CurrentThread.CurrentCulture = new CultureInfo(...) |
SM-25875 |
Under the following circumstances: 1.A .NET application is protected with Envelope. 2.The application attempts to get a module handle using the following method:
The handle returned may not be correct, and as a result, an error will be generated. The workaround to fix this is to call the GetModuleHandle system API of the Kernel32.dll to get the module handle. For example:
|
SM-26578 |
If a .NET application protected with Windows Shell (an erstwhile Sentinel product used for automatic wrapper protection) sets the exit code to ExitEventArgs such as "e.ApplicationExitCode = 1" when the application exits, the exit code cannot be retrieved by an external process. The workaround to fix this is to call "Environment.Exit(1)" to exit the process. |