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:

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

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:

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

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.