Re: Windows Logon User Interface Host High Cpu Server 2022
Eliane Lebouf
In previous versions of Windows, during system boot, the Session Manager process (SMSS.EXE) would start the Client-Server Runtime Subsystem (CSRSS.EXE), and the logon process (WINLOGON.EXE). The Winlogon process would then launch the Local Security Authority Subsystem Service, better known as LSASS.EXE and the Service Control Manager (SERVICES.EXE). The user logged into the console would be logged into Session 0, which is the shared session used by system processes. One security risk was that if a poorly written Windows service running in Session 0 displayed a user interface on the interactive console, malware could attack the window using windows messages and possibly gain administrative privileges to the system.
To address these potential issues, several system processes were redesigned for Windows Vista and Windows Server 2008. SMSS.EXE is still the first user-mode process created during the boot process as in previous versions. The change is that now SMSS.EXE launches a second instance of itself to configure Session 0, which is dedicated to system processes. The instance of SMSS.EXE dedicated to Session 0 launches the Windows Startup Application (WININIT.EXE) as well as an instance of CSRSS.EXE for Session 0, after which it exits. WININIT.EXE continues the startup process by starting SERVICES.EXE and LSASS.EXE as well as a new process, the Local Session Manager (LSM.EXE) which manages Terminal Server connections for the machine.
In parallel with the creation of Session 0, a Console session is also initialized. The initial instance of SMSS.EXE creates a new instance of itself to configure the Console session - just as it did with Session 0. The new instance of SMSS.EXE starts an instance of CSRSS.EXE and WINLOGON.EXE for the Console session in preparation for user logon. WINLOGON.EXE then launches the Logon User Interface Host (LOGONUI.EXE) which presents the Windows Security screen prompting the user to press CTRL+ALT+DELETE to log on.
When a user attempts to log on to the system, the initial instance of SMSS.EXE creates a new instance of itself to configure the new session just as it did for Session 0 and the Console session. This new instance of SMSS.EXE starts a CSRSS.EXE process and a WINLOGON.EXE process for the new session. WINLOGON.EXE starts LOGONUI.EXE to present the logon screen to the user. This may seem as though it would cause unnecessary overhead on a system, and on a client system, it does not provide any noticeable advantage. However, on Windows Server 2008 Terminal Server systems, multiple instances of SMSS.EXE can run concurrently - providing faster logons for multiple users.
Let's move on to take a quick look at another new feature of Windows Vista and Windows Server 2008 - Delayed Automatic Start for System Services. To address the problem of the growing number of services set to start automatically and the subsequent negative impact on boot performance, there is a new start type for services that do not need to start early in the boot process - the Delayed start. This allows a service to still start automatically, but with the added advantage that boot performance is improved. Services set to start as Delayed will start shortly after boot.
So how does this work? The Service Control Manager starts services that are configured for delayed automatic start after all of the automatic-start threads have finished starting. The Service Control manager also sets the priority of the initial thread for these delayed services to THREAD_PRIORITY_LOWEST. This causes all of the disk I/O performed by the thread to be very low priority. Once a service finishes initializing, the priority is set back to normal by the Service Control Manager. The combination of the delayed start, low CPU and memory priority, as well as the background disk priority greatly reduce the interference with the user's logon. Many Windows services, including the Background Intelligent Transfer Service (BITS), Windows Update Client, and Windows Media Center, use this new start type to help improve logon performance after a system boot. To configure a service for delayed automatic start, you can create a REG_DWORD value called DelayedAutoStart in the service's configuration registry key under HKLM\SYSTEM\CurrentControlSet\Services .
As an administrator of Bitvise SSH Server, you should first become comfortable with the SSH server's log files. Bitvise SSH Server writes warnings and errors into the Application section of the Windows Event Log, but it also writes more detailed information to textual log files. These are located by default in the 'Logs' subdirectory of the SSH server installation directory.
No activation code is needed to use Bitvise SSH Server for personal use. If your Bitvise SSH Server Control Panel is saying that there is an evaluation period, this means that you installed the product as the Standard Edition. In this case, you need to uninstall Bitvise SSH Server, re-install it again, and choose the Personal Edition this time.
Note that Bitvise SSH Server may be installed in the Personal Edition only by genuine, non-commercial personal users who are not using the SSH server as part of a commercial endeavor, and are not using it in an organization, whether commercial or otherwise. All commercial or organizational use requires a purchased license.
This can happen if you created a custom parent directory such as D:\Programs into which you are installing Bitvise software, but you have not taken care to configure Windows filesystem permissions on that directory.
This means that any other user on the system who is able to rename a Bitvise software installation directory, or to rename or modify files it contains, can use this limited access to give themselves complete administrative access to the system.
Recent versions of our software will warn about this situation, and will do so even if the system does not currently have any non-administrative users. If the filesystem permissions are not fixed, a problem can still arise if non-administrative accounts are added later.
To fix this problem, you must set up Windows filesystem permissions on the parent directory into which you are installing Bitvise software. For example, if you are installing under D:\Programs, you must ensure that only administrators have the right to rename or modify files and subdirectories under this location.
This is achieved by configuring permissions using Windows File Explorer. If you are unfamiliar with Windows permissions, we suggest installing into a standard location such as C:\Program Files or C:\Program Files (x86). Filesystem permissions on these directories are configured properly by default by Windows.
For a basic, open setup, just start Bitvise SSH Server and it will work. Use one of your existing Windows account names and passwords to log on. For a basic usage case, where you want to use the SSH server for remote administration, the default server settings do not need to be changed. The one exception is the Open Windows Firewall Setting, described in Q103.
After you have established a successful connection, consider locking down your settings to prevent SSH access to Windows accounts and features that you do not want to be accessible over SSH. See the page Securing Bitvise SSH Server for more information.
The SSH Server is configured primarily by a user who is a member of the Administrators group on the computer where the SSH Server is running. The SSH Server also supports a delegated administration feature where aspects of SSH Server settings can be configured by a user who does not need administrative rights.
Use Advanced settings to configure one or more accounts so they can connect to the SSH Server and use the delegated administration feature. This can be configured either for an individual user in their account settings entry, or in a group settings entry as a default for multiple users. The settings can be found under Remote administration access.
Use a recent Bitvise SSH Client version to connect to the SSH Server using an account that can use delegated administration. Once connected, use the SSH Server Control Panel button in the SSH Client. This will open a delegated administration interface which allows the user to perform administrative tasks within limits configured by a full administrator.
The delegated administration interface permits access to a subset of SSH Server settings. If you would like specific functionality to be configurable using this interface, and it is not, please contact us to describe the situation.
To help prevent inadvertently exposing your SSH server to the internet before it has been properly configured, Bitvise SSH Server will not open its ports to the internet by default. When you are ready to open your server to internet connections, go to Easy SSH server settings, and change the setting Open Windows Firewall to Open port(s) to any computer. If your Windows Firewall is disabled, or if you prefer to manage it manually, change this setting to Do not change Windows Firewall settings.
If you still cannot connect from the internet after making this change, make sure that your router is properly configured to forward SSH connections to the SSH server. You can configure the router directly through its administrative interface, or if the router can be managed using Universal Plug and Play, you can set Bitvise SSH Server to configure it. To let the SSH server manage the router, enable Automatically configure router (requires UPnP) in Easy SSH server settings.
It is possible to log into a domain account by providing only the account name, e.g. "John". In this case, authentication outcome may be undependable if Windows finds multiple matches. For example, there may be a local account named "John", a domain account named "DOMAIN\John", and another one named "OTHER\John". You can control the outcome in such circumstances by configuring the Windows domain order setting in Advanced SSH Server settings.
d3342ee215