Services2
Services2 is a file-system plugin that can list, control and manage the services registered in the system.Contents
1. General features
- List services registered in the system
- Control service states
- Edit service properties
- Delete services from the system
- Analyze service executables with internal and external tools (version 0.5.0 or higher)
- Manage services on remote systems (version 0.6.0 or higher)
- Show service PIDs (process IDs) (version 0.8.0 or higher)
2. System Requirements
- Windows 2000 or later, both 32 and 64 bit
- Total Commander 7.50 or later, both 32 and 64 bit.
3. Comparison with Services 2.4
Services2 has some advantages over Services 2.4 but due to its early development state it has some disadvantages, too. Note that some features which Services 2.4 has will not be implemented in this plugin.
3.1. Advantages
Things that the old Services plugin can't or doesn't do
- Show correct executable information in the file list of Total Commander (32 bit) on Windows 64 bit, i.e. file date/time and sizes. Services 2.4 always shows the information of the files in C:\Windows\SysWow64 instead of C:\Windows\system32.
- Unicode capable (this should be implemented correctly).
- 64 Bit version of this plugin to use in Total Commander x64.
- Translation to other languages possible.
- Support for custom columns, including default view.
- Show services in Total Commander's file list in all states, not just running, stopped and paused but all transitional states (pause/continue/start/stop pending) as well.
- Additional startup type "Automatic (Delayed)" on Vista and higher.
- Delete a service by pressing F8 or DEL in Total Commander's file list. This feature can be turned off. See section Plugin settings.
- Show some additional information when pressing F3 on a service:
- startup type
- if a service is allowed to interact with the user's desktop
- if a service uses a shared process or its own
- name of the account that the service process will be logged on as
- Show driver services as such in the dependencies/dependents trees.
- Show load order groups in the dependencies tree (but not their members).
- Show warning if not all of the service's dependencies could be retrieved, e.g. when the user executing the plugin doesn't have administrative privileges that are necessary to get the dependents of some services. Namely these are DcomLaunch, RpcSs, RpcEptMapper and pla (on Windows 7/8), but there may be other services. Services 2.4 just shows "No dependencies found" in this case which isn't necessarily true.
3.2. Disadvantages
Things this plugin can't do, and in some cases never will
- "Log on as" management is available but might be not as stable as I want it to be.
OK, the dialog's controls are more stable in this plugin as there can't be more than one radio button checked/marked simultaneously like in Services 2.4 ;). - No feature to start or stop a service directly in TC's file panel with a hotkey like F5 or F6. Note: This feature never worked on the systems I tested Services 2.4 on.
- No "Recovery" tab in the service's properties. This will most probably never be implemented (too much effort for very little benefit).
- No feature to add any executable as service. It's not planned to implement this.
4. Plugin settings
You can change most of the options in the plugin's settings dialog (Alt+Enter on the "Services2" entry in TC's Network Neighborhood).
4.1. Location of plugin settings file
If you want to change any plugin settings manually you can use either
a) Services2.ini in the plugin's directory, or
b) fsplugin.ini in the directory where wincmd.ini is located (default).Option a) is good for portable mode, option b) is useful on systems where Total Commander is installed in a directory where users can't write to (like %ProgramFiles%).
Important: If Services2.ini exists in the plugin's directory it is preferred over fsplugin.ini!
The full path of the INI file currently in use is shown in the settings dialog. As of version 0.5.0 there is a button that allows the user to open the plugin settings file in the editor defined in TC, so it can be edited directly without the need to navigate to it by hand.
4.2. The settings in detail
The settings are explained in the Services2.sample.ini file, but they're listed here for the sake of completeness.
Section [Services2]
| Setting and default | Description |
|---|---|
| ShowState = 1 | 1 - Show the service's states in the extension column of TC's file panel. 0 - Don't show the service's states. |
| ClassicTreeStyle = 1 | 1 - Use classic tree style and buttons (plus/minus signs instead of triangles) in the dependencies/dependents trees
of the service properties dialog on Windows Vista and higher 0 - Use the style defined by the OS. |
| AllowDeleteInPanel = 1 | 1 - Allow deletion of services in TC's file panel 0 - Disable deletion of services in TC's file panel. Note that TC will ask for confirmation if F8/DEL is pressed in the file list, but the plugin will not actually delete the service. Also note that services can still be deleted via the service properties dialog. |
| LoadCustomColumns = 1 | 1 - Automatically load custom columns view when entering the plugin. Note that this setting only affects
the default custom columns view which this plugin provides! More specifically the setting controls whether the plugin
reports a custom columns default view to TC or not. 0 - Don't report a default view to TC. See FAQ section on how to completely disable custom columns view |
| Language = English.lng | Specifies the language file to use by the plugin. Note: Strings missing in the specified language file are replaced with default English ones! |
| AddTxtExtensionOnDownload = 0 | 1 - Append an additional '.txt' extension when a service "file" is downloaded. This is a way to control
whether the service "files" are loaded into TC's Lister plugins (if any are installed). 0 - Don't append '.txt' extension. |
| AddSvcNameToDependencyTrees = 1 | 1 - Service properties dialog: Add service names to dependencies/dependents trees in brackets. Note that the
display name of dependent services is always shown (of course). 0 - Don't add service names to the trees. |
| ShowSvcNameAsName = 0 | 1 - Show the service's names instead of display names in TC's file panel. 0 - Show display names in TC's file panel. |
| EnableRemoteManagement = 1 | 1 - Enable management of services on remote computers, and show the "Remote Computer" subdir in the plugin's root. 0 - Disable remote computer management (hide the "Remote Computer" subdir). |
| Monitor = 0 | 0 - Show all plugin dialogs/windows on the active monitor, i.e. the monitor TC is on. 1..4 - Show all dialogs on the primary, secondary, tertiary or quaternary monitor, respectively. Note: If you specify an invalid monitor, the value will be reset to 0, i.e. the active monitor will be used instead. |
| DisablePanelAutoRefresh = 0 | 0 - Enable the automatic refresh that is done every time the service properties dialog is closed.
This is the behavior of previous plugin versions. 1 - Disable the automatic refresh when the service properties dialog is closed by Cancel, ESC key or the system methods like Alt+F4 and the X in the upper right corner. This avoids unnecessary refreshs of TC's panel which is especially helpful when there are a lot of custom columns shown. Note that this setting doesn't disable refreshs when there are changes made to a service, i.e. the service properties dialog is closed with the OK button (or ENTER). |
| RemoteComputerList = "" | Specifies a list of computers, separated by a pipe (|), that will be shown in the "Remote Computer" subdir. |
Section [Services2.Tools]
| Setting and default | Description |
|---|---|
| ShowIcons = 1 | 1 - Show icons in the list of external tools. This might slow down the list's opening operation because the plugin
extracts the icon of every external tool. Disable this setting if that's the case. 0 - Don't show icons in the list of external tools. |
| AutoDetectArch = 1 | 1 - Automatically determine the architecture of all external tools. This adds some comfort to external
tools management without having to check whether an executable is x86 or x64. However, it requires the plugin to
open every external tool's executable file which can cause slowdowns by anti-virus software and the like. 0 - Disable automatic architecture detection. If this feature is disabled, the architecture of every external tools must be set in Services2.Tools section using the x64 key (see section The keys in detail) |
| I1_Shortcut = A+ENTER
I2_Shortcut = F3 I3_Shortcut = "" I4_Shortcut = S+F3 |
(Pre-defined) keyboard shortcuts for internal tools. I1 - View executable properties I2 - View executable in Lister I3 - View service DLL properties I4 - View service DLL in Lister The value has the same format as for the shortcuts for external tools, as detailed in section Keyboard shortcuts. To disable a shortcut just set its value to an empty string (with or without quotes). |
5. Remote service management
For service management on remote systems to work correctly, several conditions have to be met.
The credentials of the local and remote users must match. This is true for every Windows version, local and remote. See section Limitations of remote computer management for more details.
Managing services on a remote Windows system running Vista or later is much more challenging, when done on a standard system which has UAC (User Account Control) and Windows Firewall enabled, and where the user is a member of the administrators group but TC - and thus the Services2 plugin - is not running elevated (as administrator).
For some reason Vista and later require administrator privileges on the remote system, even to list the services!
Additionally, a system policy is required that tells the system to create an elevated instead of a filtered access
token. See Microsoft KB article 951016 Description of User
Account Control and remote restrictions in Windows Vista for a detailed explanation.
You can either use the LocalAccountTokenFilterPolicy.reg file shipped with this plugin, or add the registry
value manually to the remote system:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"LocalAccountTokenFilterPolicy"=dword:00000001
The aforementioned restrictions can be circumvented by either disabling UAC on the remote system, or using an account that's not subject to UAC approval mode on the remote system, like the built-in administrator account.
Additionally, the Windows Firewall - if enabled - must allow remote service management, which it doesn't by default. Either start the Windows Firewall MMC snap-in (WF.msc), and enable the rules of the group "Remote Service Management" there. Or use the WinFirewall*.cmd scripts shipped with this plugin.
There's another factor to consider when managing services on Vista or later from a system running XP or older,
or vice versa. Due to the way remote service management works, either a SMB1 server or SMB1 client is required on
Vista or later to allow RPC (remote procedure call) access to the remote system. Since Microsoft and others are
deprecating SMB1 with Windows 10, even as far as automatically uninstalling SMB1 client and server protocols "when
they're not needed", this issue gets increasingly important.
When managing services on Vista or later from XP or older, the remote system must have a SMB1 server installed
and enabled! When managing services on XP or older from Vista or later, the local system must have a SMB1 client
installed and enabled!
See Microsoft KB article 2696547
How to detect, enable and disable SMBv1, SMBv2, and SMBv3 in Windows and Windows Server for more information.
There's also a helper script available to enable SMB1 server in the \remote subdirectory.
6. Internal and External Tools
As of version 0.5.0 there is support for internal and external tools. With this feature you can
- view the service executable's properties
- view the service executable in TC's Lister, including its plugins like FileInfo or PEViewer
- open the service executable in any external tool like anti-virus scanner, the VirusTotal Uploader, a web browser, a hex editor, a debugger and so on
This greatly simplifies the analysis of (unknown) services and their executables, especially such from vendors that are unable or unwilling to give their services meaningful names and/or descriptions.
The first two items mentioned above (properties and TC Lister) are internal tools and always available - provided that the service executable is found, of course.6.1. How to configure external tools
Create a new section named [Services2.Tools] in the plugin's INI file. See section Plugin settings above on how to find the correct INI file.
There can be several keys in this section:
n_Name
n_File
n_Params
n_x64
n_WWW
n_Shortcut
The values of some keys can contain the following placeholders:
| Placeholder | is replaced with | Valid in key(s) |
|---|---|---|
| {FileName} | the fully-qualified path of the service executable | Params only |
| {SvcDll} | the fully-qualified path of the service DLL, if any | Params only |
| {FileNameOnly} | the file name only, i.e. path removed | Params and WWW |
| {SvcName} | the service name | WWW only |
Quotes are automatically added to the File key value only, so they must be set explicitly in all other key values if they contain spaces!
6.2. The keys in detail
| Name | A string which will be shown in the list of external tools. If it's empty the value of File is used instead (path removed, i.e. file name only). You can use an ampersand here to manually define a character that will be used as keyboard hotkey, e.g. "&Firefox" will create an item that can be called by pressing "f" when the list of external tools is opened. |
|---|---|
| File | The path to the external tool. It can contain either a fully-qualified path or a simple file name that is located somewhere in the %PATH%. It can also contain environment variables like %ProgramFiles% or %SystemRoot% and so on. |
| Params | A string that contains any command-line parameters for File. The value can contain environment variables as well. |
| x64 | A Bool (either 0 or 1) that defines the architecture of File. 0 defines that File is a 32 bit executable 1 defines that File is a 64 bit executable Please note that this key is not required as long as AutoDetectArch is enabled in [Services2.Tools] section. |
| WWW | A string that can contain a web address that will be opened in the system's default web browser. Characters forbidden in URLs will be replaced by %hexvalue! This applies to the placeholders only, not the whole WWW string, of course. |
| Shortcut | A string that can contain any shortcut which is assigned to this external tool. Shortcuts allow quick access to internal
and external tools using the keyboard. They are useful if you don't want to use the small button to open the list of external
tools, too. See section Keyboard shortcuts for details on the string's format and supported keys and modifiers. |
If File is not found at runtime the item of this external tool will be disabled. The minimal set of keys required for a working external tool consists of Name and WWW or File and Params.
See Services2.sample.ini, section [Services2.Tools], for some examples.
6.3. Keyboard shortcuts
Supported modifiers: Alt, Shift, Ctrl
Supported keys:
For internal tools there are some shortcuts pre-defined and assigned to the following functions:
6.4. An important note on 64 bit systems
You may have wondered why there is an x64 key and the AutoDetectArch setting which the plugin uses to determine the architecture of external tools.
All 32 bit applications are subject to file-system redirection because of WOW64. There are numerous articles on the internet about this topic, see for example Wikipedia for an outline. When a 32 bit application accesses %SystemRoot%\system32 it is redirected to %SystemRoot%\SysWOW64 by the system.
Many service executables are located in the %SystemRoot%\system32 directory and the service's configuration points to this path in such cases. Now, with that in mind, what would happen if a 32 bit external tool is launched with "%SystemRoot%\system32\svchost.exe" as parameter? It would load the "wrong" file, i.e. %SystemRoot%\SysWOW64\svchost.exe. There are even cases where there's no file with the same name in %SystemRoot%\SysWOW64 but only %SystemRoot%\system32 (e.g. lsass.exe), so 32 bit external tools would not be able to load the service executable at all.
Therefore Services2 replaces "%SystemRoot%\system32" with "%SystemRoot%\SysNative" in the paths of all service executables if the external tool's executable is a 32 bit binary (unless the service is a WOW64 service). Furthermore, Services2 replaces "%SystemRoot%\system32" with "%SystemRoot%\SysWOW64" in the paths of all service executables if the service is a WOW64 service and the external tool's executable is a 64 bit binary.
With this approach all internal and external tools always load the correct file, regardless of the architecture of TC, this plugin, the external tool or the service itself.
6.5. A special note on Windows XP x64 Edition
By default, there is no %SystemRoot%\SysNative pseudo-directory available for 32 bit applications on this OS. That may result in non-working internal and external tools. You have two options here:
- Get a patch from Microsoft
Unfortunately this patch is NOT publicly available. There may be other sources for this hotfix, but you don't want to install patches from an unknown source, do you? - Create an NTFS junction from %SystemRoot%\system32 to %SystemRoot%\SysNative. You can do this with tools like Sysinternals Junction or NTFS Links
Sysinternals Junction:
- Launch a 64 bit command prompt (CMD) and navigate to the folder where junction.exe is located
- type "junction %SystemRoot%\SysNative %SystemRoot%\System32" (without the quotes) and hit Enter
- the tool should say something like
Created: C:\WINDOWS\SysNative
Targetted at: C:\WINDOWS\system32
NTFS Links:
- Install the tool according to its help file, e.g. on a button or start menu in TC
- Navigate to %SystemRoot% in both of TC's panels
- Set the cursor on system32 directory (doesn't matter if left or right panel)
- Call the tool from the button/start menu create in first step
- Important: Replace the "*.*" at the end of the target path with "SysNative" so that the path points to "C:\Windows\SysNative"
- Confirm the creation of the junction
7. Known Issues and Limitations
7.1. Known Issues
- When the option "Show service state in the extension column of TC's panel" is disabled and the state of any services changes
(using this plugin or other means) the icon does not reflect the new state of the service. Fixing this would require a lot
of work, so I'll leave it as it is for now.
Update: This should be fixed as of version 0.4.2, except perhaps for services whose executable is not found/recognized by the plugin, so there isn't any information shown in TC's Date column.
- The feature "Configure" of TC Plugins Manager does not work with this plugin. This is a limitation of TC Plugins Manager. It calls only the ANSI functions exported by the plugins. Since Services2 is a Unicode only plugin (regarding the relevant functions) it does not work.
- The dialog asking for confirmation to grant a user account the SeServiceLogonRight is too wide on pre-Vista systems. I'm really not happy about this, but inserting manual line-breaks kind of breaks the dialog text on Vista+ systems...
- The shortcuts assigned to internal/external tools items are not translated. Currently I don't think I will translate them as it is quite some work for a relatively small benefit.
7.2. Limitations of remote computer management
Due to the nature of managing services on a remote machine, there are some limitations that are important to be aware of.
- The credentials to access a remote system must match the credentials of the user running the plugin. That means, you can't access the remote system if your local user doesn't exist with the same password on the remote system. There's no API to provide any different credentials. Note that the system's MMC snap-in (services.msc) has the same limitation.
- The information about the service executables and service DLLs shown in TC's panel, like file size, date, attributes, version
number and so on, are that of the local system. There's just no reliable way of accessing files on a remote machine,
even though there are administrative shares (which are not accessible if the plugin is not run as administrator).
This also means that all internal and external tools will operate on the files of the local system. - When managing a remote system running Windows Vista or higher from a local system running Windows XP or earlier the startup type "Automatic (Delayed)" will not be available, neither for display nor for selection (service properties dialog). So, although there might be services with this startup type on the remote system, the plugin won't be able to show or set it; the startup type will be "Automatic" instead.
- The "Service is WOW64" checkbox will not be available in the service properties dialog, because this flag has no meaning anyway on remote systems, even less for internal/external tools.
8. Frequently Asked Questions
Why does the plugin load the custom columns view although the option "Load Custom Columns View upon entering the plugin" is disabled?
The option controls whether the plugin reports a default custom columns view to TC or not. In case the default custom columns view is changed by the user, TC switches to this custom columns view automatically when the plugin is entered, regardless of the plugin's setting, because the option "Switch to this view when entering the plugin" in TC's custom columns view is enabled by default. So, to really disable the loading of custom columns view the option "Switch to this view when entering the plugin" in TC's custom columns view must be disabled as well.
Why is "Service is WOW64" in the service properties dialog not ticked on some services although they clearly use a 32 bit executable?
The checkbox is only ticked when a service has a flag set in the registry which tells the system that this service is a WOW64 service. This happens if the service executable is located in %SystemRoot%\SysWOW64 but its executable path points to %SystemRoot%\system32 and therefore subject to file-system redirection. The flag is not necessarily set if the service executable is located in places that are not subject to file-system redirection, like %ProgramFiles(x86)%.
Why does the properties dialog and TC Lister show "C:\Windows\SysNative" as location although the service properties show "C:\Windows\system32"?
Take a look at An important note on 64 bit systems section above for a detailed explanation.
Why are there services without information about their executables on a remote system?
Why is there no "Automatic (Delayed)" startup type on a remote system?
Take a look at Limitations of remote computer management section above for a detailed explanation.
Why do I get error 5 "Access denied" when trying to access a remote system?
See Remote service management section for an explanation and the registry value that's required on remote systems running Vista or later.
Why do I get error 1722 "The RPC server is unavailable" when trying to add a remote machine to the list or access a remote system that's already in the list?
You're probably trying to remotely manage services on a system running Vista or later from XP or older, or vice versa. Take a look at Remote service management section for a detailed explanation as well as some options to make it work.
9. License
The plugin's cog icon "Fatcow-Farm-Fresh-Cog", part of the "Farm-Fresh Web Icons" package:
(C) Fatcow Web Hosting, licensed under CC Attribution 3.0
All other icons (except the Delphi main icon) were made by my brother.
This software is provided "as is". No warranty provided. You use this program at your own risk. The author will not be responsible for data loss, damages, etc. while using or misusing this software.
The software must not be modified, you may not decompile or disassemble it.
This plugin is copyrighted freeware.
10. Thanks to
- Christian Ghisler, the author of Total Commander, for developing this great program that I use every day
- Serge Kandakov (KaSA) for making the Services 2.4 plugin. It would have been much more work to make my own plugin without "the original".
- The authors of HTTP Browser and Uninstaller64 plugins. I adopted some of the ideas (but not any code) from their available source code.
- Ritsaert Hornstra @ StackOverflow for his unit ServiceManager
- Colin Wilson for his unit LsaApi
- Nico Bendlin (NicoDE) for his unit ObjSel
- The members of the Delphi-PRAXiS forum that helped me understand and fix some things
11. Contact
If you have found a bug, have a suggestion, improvement, criticism, translation, you can contact me, Dalai,
in English or German, at:
Mail: dalai82@gmx.net
Please put "Services2" somewhere in the subject.
There is a discussion thread in the official TC forum which can be used, too: http://ghisler.ch/board/viewtopic.php?t=40155