1

I have an MFC app and WPF app that when run in LocalSystem user can't process any IMEs (Input Method Editors). But the same application when launched in user mode was able to receive IME inputs from keystrokes and from IMEPad.

In the LocalSystem user process, when keyboard focus is in the control (both WPF and MFC) the IME icon becomes "X" like the following image:

IME disabled

I can't launch in the user mode by default as I have to perform higher privileged operations with my app. I am not able to find any explicit thread in Microsoft forums or elsewhere that talks about my issue.

Have you faced this issue? This seems like a restriction in Windows rather than an issue, do you know how to work around it. Any valuable input regarding this is appreciated.

Edit: LocalSystem account is not associated with any user. As mentioned in msdn :

The account is not associated with any logged-on user account.

This could be the reason why Windows can't enable IME on System user. It does not know the language set in the current user. Is there anyway to force/bypass to consider Logged user's locale.

Shameel Mohamed
  • 607
  • 5
  • 23
  • 1
    I guess you found the issue. LocalSystem is not by far a regular user, so it seems logical it has no relation with UI or input. You should change your architecture so you keep your LocalSystem process because you need it but add process logged as the current user, and add some IPC between the two processes (with a level of security depending on your need). – Simon Mourier Jul 18 '22 at 17:16

1 Answers1

1

The LocalSystem account is a predefined local account used by the service control manager. This account is not recognized by the security subsystem, so you cannot specify its name in a call to the LookupAccountName function. It has extensive privileges on the local computer, and acts as the computer on the network. Its token includes the NT AUTHORITY\SYSTEM and BUILTIN\Administrators SIDs; these accounts have access to most system objects. The name of the account in all locales is .\LocalSystem. The name, LocalSystem or ComputerName\LocalSystem can also be used. This account does not have a password. If you specify the LocalSystem account in a call to the CreateService or ChangeServiceConfig function, any password information you provide is ignored.

A service that runs in the context of the LocalSystem account inherits the security context of the SCM. The user SID is created from the SECURITY_LOCAL_SYSTEM_RID value. The account is not associated with any logged-on user account. This has several implications:

  • The registry key HKEY_CURRENT_USER is associated with the default user, not the current user.
  • To access another user's profile,impersonate the user, then access HKEY_CURRENT_USER.
  • The service can open the registry key HKEY_LOCAL_MACHINE\SECURITY.
  • The service presents the computer's credentials to remote servers. If the service opens a command window and runs a batch file, the user could hit CTRL+C to terminate the batch file and gain access to a command window with LocalSystem permissions.

So if you need to run app as a LocalSystem account and you are not happy with default user settings you can 2 things:

  1. Impersonate another user, this is common tactic (Impersonate user in Windows Service)
  2. Set language preferences (or whatever you need) to default user. Here is an example for Win10 for and language issue (https://www.microcloud.nl/windows-virtual-desktop-dutch-language-pack/#more-1311).

Demystifying error - If you are using VS, you can try enable more logging, https://learn.microsoft.com/en-us/visualstudio/ide/reference/devenv-command-line-switches?view=vs-2022 and figure out what the tool is not able to get from default user. You also can attach VS debugger to running process, see msdn article (https://learn.microsoft.com/en-us/visualstudio/debugger/attach-to-running-processes-with-the-visual-studio-debugger?view=vs-2022)

Maksym
  • 820
  • 1
  • 8