MiniRobotLanguage (MRL)
Service Command codes
Manage NT Services
General Information about the Service commands
The service command(s) need a service name to specify the service we want to deal with.
A service has two names:
1. the "display name" (dn:) - that is the name you see in the service manager console
2. the "service name" (sn:) - that is the name you can see in the service properties, only.
You can see an example in the picture below.
Generally we are using the "service name" for all service commands.
If you prefer to specify a "display name" 8or a part of it), prefix it with a "dn:".
Then the command will internally try to find the matching service name for that service.
You do not need to specify the full "service-name" or "display-name". You can use the
to specify the name of the service.
To make clear, which service name you are using, you can prefix it with:
"dn:" if the "display-name" is been specified
or
"sn:" if you have specified the "service name".
As noted, all commands use the "Standard search patterns", therefore you can just give a unique part of the service name or specify a pattern. Here are some examples:
If you use:
SER.grs|bitlock
DBP.$$000
the service will place an error message on TOS, that is "Error: No such service.".
You can see the Error-Message in the Debug-Output of the Editor. The reason is, that "bitlock" is a part of the "display name" of the service, but generally we search for the "service name". And for the "Bitlocker Service", the proper "service name" is "BIDESVC" as you can see above.
Therefore we could specify:
SER.grs|BDESVC||$$RES
DBP.$$RES
and would get the proper result:
if that service is available and actually stopped. Of course we could also use the "display name", if we prefix it with a "dn:" and write:
SER.grs|dn:bitloc||$$RES
DBP.$$RES
which will also get the expected result ("STOPPED").
As you can see, there is no need to type the whole, complete service name, as we can use the Search Pattern Engine here. That is why "bitloc" in the above example will work just fine.
Here are two things you should take care for:
1. On international computers the "display name" of a service may differ from country to country. For example, the "Netlogon" Service shows up on a german computer as
where it shows up on a english system as expected:
Therefore prefer to use the "service name" whenever your script may touch international clients computers.
2. Make sure that the search pattern, that you specify will really hit the proper service. Therefore specify the target service as close as possible. The good thing about the Pattern Engine is, that you can omit version information that are really obsolete, for example, see the picture below.
You could use "clr_optim&ANDTHEN:v2." to specify such a service using a pattern. Like this:
SER.dnf|clr_optim&ANDTHEN:v2.||$$RES
DBP.$$RES
and you will get the expected result.
To verify if a service is available or running is one thing, and it will most often be done using the ISC. command. To change service attributes or to restart a service is the main job of the SER. command.
What about "state groups"?
Imagine you want to start a service and therefore you want to check if the service is already running. You can do that in several ways. Now you check if the state of the service is "run" and its not. Are you going to run that service next?
What if the state of the service was "start pending" which is as good as "run" but is in fact another state?
To solve this issue, we have so called state groups for some instructions.
These have only 3 states, which are represented by 3 numeric values:
"stop","stopped","stop pending" = 1
"running","run","start pending","continue pending" = 4
"pause","paused","pause pending" = 7
Using these you can easily check, if you really need to start or stop or continue a service.
"Run States" to set using
SER.set run state|(Service name)|(target state number)
START SERVICE = 0
STOP SERVICE = 1
PAUSE SERVICE = 2
CONTINUE SERVICE = 3
UPDATE SERVICE MANAGER = 4
"Run States" as in return from
SER.get run state numeric|(Service name)|$$RES
STOPPED = 1
STARTING = 2
STOPPING = 3
RUNNING = 4
CONTINUE PENDING = 5
PAUSE PENDING = 6
PAUSED = 7
UNKNOWN = any other number
Some commands, like ISC. / NSC. support textual state, these are:
"stop","stopped" = 1
"start pending" = 2
"stop pending" = 3
"running","run" = 4
"continue pending" = 5
"pause pending" = 6
"pause","paused" = 7
Some commands support textual state and a "state group":
"stop","stopped","stop pending" = 1
"running","run","start pending","continue pending" = 4
"pause","paused","pause pending" = 7
Possibly Actions to take an Service failure:
SC_ACTION_NONE = 0
SC_ACTION_RESTART = 1
SC_ACTION_REBOOT = 2
SC_ACTION_RUN_COMMAND = 3
Service-Types
SER.gst|rasaut|$$RES
SERVICE_KERNEL_DRIVER = 1
SERVICE_FILE_SYSTEM_DRIVER = 2
SERVICE_ADAPTER = 4
SERVICE_RECOGNIZER_DRIVER = 8
SERVICE_DRIVER = 11
SERVICE_WIN32_OWN_PROCESS = 16
SERVICE_WIN32_SHARE_PROCESS = 32
SERVICE_WIN32 = 48
SERVICE_INTERACTIVE_PROCESS = 256
SERVICE_TYPE_ALL = 319
Service Start Modes
SERVICE_AUTO_START (Automatisch) = 2
SERVICE_DEMAND_START (Manuell) = 3
SERVICE_DISABLED (Deaktiviert) = 4
also these two states which are in the SM not available,
and may not work with most services:
SERVICE_BOOT_START = 0
SERVICE_SYSTEM_START = 1
Textual Service Start Modes
(parsing is NOT case-sensitive)
"Auto","Auto Start","Automatisch" = 2
"Demand","on Demand Start","Manuell" = 3
"dis","Disabled","Deaktiviert" = 4
"boot","Boot Start" = 0
"system","System Start" = 1
Example
'**********************************
' SER.
'**********************************
SER.dnf|yaho||$$RES
DBP.$$RES
SER.snf|yaho||$$RES
DBP.$$RES
SER.grs|yaho||$$RES
DBP.$$RES
SER.grn|yaho||$$RES
DBP.$$RES
ENR.
'**********************************
Remarks
-
Limitations:
-
See also:
• ISI. / NSI. - If Service Installed