Custom shell as user.... default shell (explorer.exe) as administrator...

Schurink used Ask the Experts™
Hi All,

We have a wbt to set up..... So we created a custom shell "wbt.exe" which the users get when they start into Windows XPe. This is done by editing the registry:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]

Now the problem is that also as local administrator (this WBT is not part of a domain) we are getting this shell, and we don't want that; the local administrator must have the default shell.

There are several things we have tried to get a normal desktop as an admin, while retaining the custom shell for the user :
- From taskmanager (logged in as admin) launch an "explorer.exe"  => starts a windows explorer, not the desktop.
- Re-create the "Show Desktop" button and (logged in as admin) launch it as admin  => nothing happens.

We are trying to figure out how to arrange this. Does any of you know how to get around this (start the desktop when you don't have the default shell)?


Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
you can also use autoexec.bat i think.


Can you please be a bit more specific? How would you configure your proposed solution?

If you use the taskmgr approach, you have to kill wbt.exe (the currently running shell) BEFORE you launch explorer.exe.  Otherwise, explorer won't launch as a shell (the problem you've already encountered).

You also might be able to create a special script to do this automatically using pskill (  Something along the lines of:

REM Change to explorer.exe as shell
@echo off
pskill wbt.exe
start explorer.exe

Rowby Goren Makes an Impact on Screen and Online

Learn about longtime user Rowby Goren and his great contributions to the site. We explore his method for posing questions that are likely to yield a solution, and take a look at how his career transformed from a Hollywood writer to a website entrepreneur.

Most Valuable Expert 2011
Top Expert 2011

Implement a User Based Custom Shell

Registry Settings
User Key: [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\                        <~~~~~~
System Key: [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\
Value Name: Shell
Data Type: REG_SZ (String Value)
Value Data: Filename of Replacement Shell

Make teh user an Admin temporarily to allow registry importing to the HKCU.....DONT DO A RUN AS ON A .REG FILE, cause it will go to teh HKCU of that ran as user...


Hi, and thanks for the reply... i will  try this to see if it works.



We found a very easy and good solution:

The custom shell we built with Wise has 2 options: logon using a custom ICA file or shutdown. But before that we made a simple check within the executable which checks wether the Administrator is logged in or not. If he is then the "explorer.exe" is started and the executable exits.
We can do this because we use the default user account to automatically logon, who of course is not the administrator.
It works very good.


Ah well, for those who are interested: this is the other way to do it:


The ability to make your application the shell is one of key features of Windows XP Embedded. Devices can start in a custom shell instead of starting in the Explorer shell, which provides two benefits. The first benefit is that the system will start faster. The Explorer shell takes a significant amount of time to load all of the support libraries and files, whereas a specific application will most likely have fewer libraries to load. The second benefit is that access to a device's administrative functions can be limited, depending entirely on how the custom shell application is written.

Limiting a user's access to administrative functions such as Control Panel can be a benefit, but there is a small drawback: The administrator is also limited unless the administrator can start in a different shell.

The ideal solution would be to set up Windows XP Embedded so that the user account can start in the application shell and the administrator account can start in an administrative shell. Security features built in to Windows XP Embedded would then prevent users from accessing administrative functions. This article describes how this solution can be implemented.

Registry Is the Key
Microsoft® Windows® XP has a feature that can provide the solution through the registry. The registry for each user account and administrator account can be set up to start a user-specific shell. There are three keys that must be set up. The first two are generic for all users. This article refers to the keys as "Key1," "Key2," and "Key3" for simplicity.

Key1 is a string value. When Windows XP starts, Key1 is called and the default Windows shell is started. However, if the default value is changed to USR:Software\Microsoft\Windows NT\CurrentVersion\Winlogon, Windows looks in the HKEY_Current_User key to start a specific shell for the user logging on. If the specific user shell is not found, Key2 is called and a default shell is started.

Key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\IniFileMapping\system.ini\boot\Shell
Type: REG_SZ
Value: SYS:Microsoft\Windows NT\CurrentVersion\Winlogon
Key2 provides a default shell if the user shell application cannot be found. When you select a shell component for a Microsoft Windows XP Embedded configuration, Key 2 is set up to the shell application as the default shell.

Key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell
Type: REG_SZ
Value: Explorer.exe (or this can be a different default application)
Key3 sets up a shell for the current user or logged-on user. Thus, the only way to change a particular user's shell is to log on to the user account and create this registry entry.

Key: HKEY_Current_User\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell
Type: REG_SZ
Value: c:\windows\system32\account shell.exe, where account shell.exe is the name of the application
How It Works
When the user logs on, Windows uses Key1 to determine which key holds the shell information. Normally, Windows uses Key2 next. However, if the value of Key1 is changed to USR:Software\Microsoft\Windows NT\CurrentVersion\Winlogon, Windows will use Key3 for the user logging on to start the user's specific shell.

Changing the registry key values in a system with a registry already set up is fairly straightforward. The challenge is how to do this in Windows XP Embedded, where the registry is set up during the First Boot Agent (FBA) process.

HKLM keys can be set up in Target Designer because they are computer specific. Setting up the HKCU keys, however, is impossible in Target Designer because the accounts will not be created until after FBA runs. The user account and administrator account components create only the accounts, user names, and passwords. These components cannot be used to set up a specific shell. The only solution is to set up the specific shells after the Windows XP Embedded image has completed the FBA process.

Setup for Windows XP Embedded
The trick to making different shells for different users in Windows XP Embedded is in the setup. There are a few components that need to be part of the configuration so that Key3 can be set up for the user's account:

Windows Logon. Because different accounts will be part of the image, Windows Logon (Standard) is a required component for the configuration. Windows Logon supports the ability to log on to different accounts locally and remotely. By contrast, the Minlogon component supports only logon to a single administrator account.
Two User Account components. Two computer accounts are required at a minimum; at least one account must be an administrator account. The User Account component can be set up to be an administrator account through the Extended Properties page. When a user account is set up as an administrator account, it replaces the generic "Administrator" account, just as in other versions of Windows XP. Because of the elimination of the administrator account, you may want to consider using two instances of the User Account component. You can set up one component as an administrator (which will have the administrator shell), and you can set up the other component as a regular user (which will have the system shell).
Automatic Logon. Most original equipment manufacturers (OEMs) want their systems to start directly in the application. The Automatic Logon component can be added to the configuration to start directly in the user account, whose shell will be the system's application.
Default Shell. Windows XP Embedded comes with several shells: Explorer, Task Manager, and Command. You can also create a custom shell. A shell component is required in the configuration. When you select a shell component for the configuration, the shell will be the default shell for the Windows XP Embedded image, so you do not need to set up Key2.
For setting up different shells for different users, the chosen shell component will be the administrator shell, and the shell must allow access to configure the registry to set up Key3. Task Manager may be a good choice. TaskManager is small shell that you can use to start other applications, such as Control.exe (Control Panel) or Regedit.exe (Registry Editor). You may want to create your own administrative shell if the TaskManager shell is not appropriate. After the FBA process is completed, all accounts will have the same administrator shell. You can then log on to any account and set Key3.
User Shell. The last component is the user or system application, which will be the second shell. Your second shell component should not be set up as a shell component or be grouped with the other shell components. Rather, the second shell component should be treated like any other application component, such as Windows Accessories or Transmission Control Protocol/Internet Protocol (TCP/IP) utilities. After the FBA is completed, you can log on to the user account and set up Key3 to point to the application. If the application component is missing, the default administrator shell component will appear.
Other components. Windows Script Engine and Registry Editor can be included to help with creating Key3. You can create a custom application to perform this task.
Setting Up Key1
You must set up Key1. In the Extra Registry Data, found at the top of the configuration, add Key1 as described earlier, with the value set for USR:Software\Microsoft\Windows NT\CurrentVersion\Winlogon. To see the Extra Registry Data resource, you may have to enable resources by clicking View, pointing at Resources, and then clicking Target Designer.

After the configuration has been set up, built, and downloaded to the target, and after the FBA process is completed, the last step is to set up the user account for the system shell. Because you initially set up the image to start in the administrator shell, you should be able to access the registry.

Setting Up Key3
To set up the user account with the unique shell, you must log on to the user account and add Key3 to set the path to the system application. Note that you cannot log on to the administrator account to change the user account's shell. After you log on to the user account, you can use Regedit.exe, Windows Script, or another application to create Key3 and set the path to the application.

The following is an example of WScript.

'Windows Script to set a user shell
set shell = CreateObject("")

shellpath = InputBox ("Enter the path and name of the EXE application
to be this user's shell. Example: c:\windows\system32\cmd.exe:")

if shellpath <> "" then Shell.RegWrite
"HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell", shellpath, "REG_SZ"

The following is an example of CScript.

 'Windows Script to set a user shell
set shell = CreateObject("")

wscript.stdout.WriteLine "Change the Shell for this user."

sub ChangeReg
wscript.stdout.WriteLine "Enter the path and name of the EXE application to be this user's shell."
wscript.stdout.WriteLine "Example: c:\windows\system32\cmd.exe or type QUIT to exit: "

if wscript.stdin.AtEndOfStream  then exit sub
shellpath = wscript.stdin.ReadLine
if ucase(shellpath) = "QUIT" then exit sub

Shell.RegWrite "HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell", shellpath, "REG_SZ"

wscript.stdout.WriteLine "User will now have a new shell"
end sub

After you set Key3, you can log off and log on again to the user account and/or the administrator account. The user account's specific shell will be started when you log on to the user account. The default/administrator shell will be started when you log on to the administrator account.

Extra Notes
By default, Windows Script engine is set up for WScript. WScript uses dialog boxes for input and output messages. CScript uses only a command prompt, which is ideal for headless systems. You can change to CScript only from an administrator account. If you decide to use a Windows Script Engine, you must modify the registry data for the Windows Script Engine component for the Microsoft Visual Basic® Scripting Edition (VBScript) file. Change HKEY_CLASSES_ROOT\VBSFile\Shell\Open\Command and add %1 to the end of the value %11%\WScript.exe, as shown in Figure 1.

Figure 1. Changing the registry value for the Windows Script Engine component

After Key3 has been created, you can log on again to the user account and see the new shell for the account. When you log on to the administrator account, the default or administrator shell will still be started.

If you are using remote administration features, be aware that Telnet allows more than one user to be logged on to the same computer, but Remote Desktop Connection or Microsoft NetMeeting® allows only one user to be logged on to the computer. Remote Desktop Connection takes control of the desktop and logs off users from a system. If you plan to use Remote Desktop Connection, your system must not be affected by an administrator logon and a logoff of the user account.

In addition, after Key3 has been set up, you can use FBreseal—found with the Cloning component—to reseal the image for duplication. The registry key information for the user account will be preserved.

Windows XP Embedded provides a flexible way to deploy the popular Windows XP operating system into a number of embedded devices. The ability to have two accounts with different shells allows OEMs to build systems that prevent users from accidentally accessing administrative functions. The solution is to define the administrative shell as the default shell in the system and change the user account's registry keys to point to a second shell.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial