This is happening to Urs Wiggli and Robert Wahlström. It appears to be a registry security issue during initialization of the License object:



mscorlib.dll!System.ThrowHelper.ThrowSecurityExcep tion(System.ExceptionResource resource) Unknown

mscorlib.dll!Microsoft.Win32.RegistryKey.OpenSubKey(string name, bool writable) Unknown

Profile.dll!DC3.Profile.Registry.GetSubKey(string section, bool create) Unknown

Profile.dll!DC3.Profile.Registry.GetValue(string section, string entry) Unknown

Profile.dll!DC3.Profile.Profile.GetValue(string section, string entry, string defaultValue) Unknown

Scheduler.exe!DC3.Scheduler.License.Initialize() Unknown


Scheduler.exe!DC3.Scheduler.License.Valid.get() Unknown

Scheduler.exe!DC3.Scheduler.MainForm.Main(string[] args) Unknown

 

  
SVN Comment
 
 

  
Author
  
rbdenny
 
 

  
Repository
  
svn+ssh://rbdenny@a2_svn_dc3/home/rbdenny/svn/astro/scheduler
 
 

  
SVN Revision
  
603
 
 

  
Affected files
  
/trunk/SchedulerSetup/Custom Actions/SecAdjustForUac/Installer1.cs (Modified)

 
 

  
Check-in comment
  
Use well-known security identifiers for builtin\Users
GEM:1358

 

This is a result of using the name "builtin\Users" in the security adjustment logic of the installer. This fails on non-English systems, leaving sections of Scheduler locked out. Robert Wahlstrom helped me isolate the problem, and also with this link: https://support.microsoft.com/en-us/kb/243330 which lists the locale-independent security identifiers. The one we want is S-1-5-32-545 for builtin\Users.

Verified that the installer custom action is indeed creating the special registry key and setting User-level full-control permissions on it. Yet the problem on those systems is that simply reading a value under that key is generating the security exception. Can't repro this here.

This is happening in License.Initialize() where it is setting the license expiry for the installer and for 60 day eval. See comments in License.cs. The fix needs to be in the installer.