Installation of service created by Embarcadero compiler

[PaulAdams]

Summary:
I cannot get any service application I have created using Embarcadero RAD Studio 10.4 to properly register the service using the "Services" item under "Advanced options".

Details:
With both 32-bit and 64-bit services, the service is shown in the service manager after the install, but an attempt to start it fails. With both the application that started this adventure and a very simple application I created specifically for testing purposes, attempting to start either the 32-bit or the 64-bit version results in an extremely protracted apparent attempt to start the service, eventually displaying that "the service did not respond to the start or control request in a timely fashion". However, the service status continues to be displayed as Starting - it is necessary to disable the service start-up and restart the operating system before the application is "released" such that an uninstall is possible.

Further, when the installer is then run again to uninstall the application, the uninstall of the related files occurs, but the service is left registered (with no corresponding executable on the drive). I am obliged to perform a manual registry clean-up to "deregister" the service.

Providing good evidence that the issue is not with the service application itself, if I modify the installer to simply install the application, but not register the service using the "Services" item, and I then use an Administrator command prompt to install the service, this creates the service entry, and the service starts and stops correctly.

Finally, again not using the "Services" item, if I create "Run Program" entries that perform the service registration "after install" and deregistration "before uninstall", the service registration and deregistration all happens completely as expected.

So, why doesn't it work through the "Services" item under "Advanced options"?

BTW: The service registration and deregistration is performed simply by running the service application with "-install" or "-uninstall" as the command line parameter, respectively.

[FrancescoT]

The Install Service command is a Windows Installer command (PURPLE COMMAND), and this once installed the service to the target dir, it also invokes the "SC.EXE" tool for the service registration. Probably, this last one may be cause of the problem you noticed … and this due the fact that your service expects "-install" or "-uninstall" as command line parameter, for registering/unregistering the service.

At any rate, the alternative approach you used it's totally correct.

[PaulAdams]

Hi Francesco,

Thanks for the reply.

The issue with the use of "-install" and "-uninstall" is that they are not silent - they cause a dialog to be displayed "The service was successfully installed" / "The service was successfully uninstalled", respectively, and I have no idea whether there is a "-silent" option, or similar - I will be trying that today.

Addendum:
There is a "silent" option, so this works around that issue.


Your statement "your service expects" implies a bit of misunderstanding.

This self-registering capability is a built-in feature of the Embarcadero Windows Service project type - I only used this because the other way (which appears to work as far as Service Manager is concerned) somehow doesn't do what is required. Best I understand, the Embarcadero Windows Service application class is a proper Windows Service implementation, which is why I am puzzled about why this is a problem with my Windows Services, and not a known issue with the use of "SC.EXE" with this application base class.

[PaulAdams]

Having read a bit more about Embarcadero service applications, there appears to be something a little bit "odd" about them, although I must admit I do not know anything about the structure and arrangement of service applications in general.

The online wiki states:

After your service application is built, you can install its services with the Service Control Manager (SCM). Other applications can then launch your services by sending requests to the SCM.

There are two direct implications in this that I do not understand fully.

The first is that a single service application may include multiple services, which I have established is a correct understanding.

The second is the rather ambiguous reference to "the Service Control Manager (SCM)", unclearly implying this may be either part of the installed application, or something that exists in Windows. Obviously, if this is some part of the installed application, and acts as some form of intermediary between the Windows Service Manager and the application's services, the registration process is non-negotiable.

However, a Google search for "Service Control Manager" implies that it is part of Windows, which then takes me back to the original question, which I guess is now better stated as "Why does an Embarcadero service application require command line installation?".

Obviously, this is a question for Embarcadero, not InstallAware. If I get a meaningful answer from their forums, I will post pertinent quotes here.

[FrancescoT]

I don't know so much about Embarcadero projects.
Visual Studio has a similar project template for a C++ Service App. For what I recall, the service does also some extra stuffs (ex. assigns the service account, interactively mode settings, and so on) when this get invoked using the -install parameter. With such kind of service I always used "Run Program" to register the service from the setup script.

At any rate, for testing purpose, you may try to register your service via SC from CMD prompt. At least just to see what happens.

Then ...Run Program has two useful options:

Hide Program Window
If you wish to hide the window of the executable, check this checkbox.

Wait For Program to Finish
If you wish to pause the installation script until the indicated program completes executing, check this checkbox.

Hope this helps you.

[PaulAdams]

Hi Francesco,

I have been using the "Wait for program to finish" with my attempts at service registration, because of an addition issue I mention below. This was an attempt to address this issue through using the elevated user context of the installer to add a registry setting. However, it appears that the installation occurs in a different "control set" context to that of the non-elevated user, meaning that it is not "applied" to the "CurrentControlSet" of the interactive user.

The mentioned issue...
While I can register the service, I cannot set a description for the service. Within InstallAware, there is an ability to define a description, which is shown against with the service in the Services console. However, the "-install" option of the Embarcadero service doesn't seem to have any support for specifying this, leaving the service installed, but with a blank description.

My "hack" was to use "Run program" to run regedit.exe after the "Run program" that performs the service installation has finished, to set the desired description into the "CurrentControlSet" key that relates to this service. However, regardless of what "ControlSet" I specify for the registry key set, the value is set in "ControlSet002", and not "CurrentControlSet" for the interactive user. If the same registry file is merged by the interactive user, it correctly sets the service description. It is scarcely a "professional image" to provide an installer that requires the manual addition of registry settings after the installer finishes...

Of even greater frustration, Embarcadero appear to have completely destroyed the functionality of their forums web-pages. While a search on their forum gives me a link to a forum post on installing services using "SC.EXE", clicking that link simply take me to the forums index page. If I attempt to navigate from there to the post, these efforts are equally unsuccessful - its almost as though they have somehow purged all historical posts, except that you can see references to them in searches.

[PaulAdams]

I conducted an experiment that produced an interesting result.

Thinking about the fact that the Embarcadero TServiceApplication class is able to contain multiple TService instances, I decided to change the registration setting under the InstallAware Services installation to being a shared executable instance.

This registered the service (as it had before) but, rather than stalling when the service was asked to start, after a very brief pause, caused display of a message:

Windows could not start the TestService service on Local Computer.

Error 1083: The executable program that this service is configured to run in does not implement the service.

I'm not sure that this helps me at all, but it is an interesting difference.

[FrancescoT]

I suggest you to have a look at this link about win32 Service types.
https://docs.microsoft.com/en-us/windows/win32/services/service-programs

At any rate, I am also suspecting that you are not elevating "as necessary" your installer package at setup runtime.

My "hack" was to use "Run program" to run regedit.exe after the "Run program"

.
In the Project Options (SHIFT+CTRL+F11), did you set "highestAvailable" with the "UAC Elevation" settings?
https://www.installaware.com/forums/viewtopic.php?f=2&t=6787
To install a service your whole "setup process" has to run under a Full Administrative User Context.

Finally, "Install Service" command is a Windows Installer command (PURPLE COMMAND). If your setup project is based on Windows Installer Engine (which is by default), the command doesn't get executed immediately, but deferred to "Apply Install" execution.
https://www.installaware.com/forums/viewtopic.php?f=2&t=4338
Due of this, a registry key created during service registration ("Install Service"), it will only exist once "Apply Install" execution has completed (SUCCESSFULLY).

Hope this helps you.

[PaulAdams]

Hi Francesco,

Thanks for the link to the Microsoft article on service types - I will check through that.

I have UAC Elevation set to "Always Elevate (requireAdministrator)", which I perceived to be the highest possible - certainly, because of what is happening, this installer should never be permitted to run by a non-Administrator. I will have a look at the topic you linked.

In any case, I don't perceive that there is a problem with elevation - neither the install command "MyService.exe -install" nor the registry write would work if the command were not running at an administrator level - no write to the HKLM registry hive is possible from a lower user level; it would simply be refused (or virtualised if it was from a 32-bit process).

w.r.t. the registry key not existing, that doesn't apply in this situation - I am not using the PURPLE COMMAND to install my service, so the commands are being run inline.

Looking at the MSI code, the two commands are being run consecutively after the RED COMMAND Apply Install.

Code: Select all

Run Program $TARGETDIR$\MyService.exe /s /install (WAIT)
Run Program regedit.exe /s SetServiceName.reg (WAIT)


However, having attempted to paste these from the MSI window into this post, I have found that the order of the commands is the opposite to what is shown above.

Code: Select all

~InstallAware Clipboard Data~
~Run Program~
~{8789ADE9-7FC5-4C34-9884-9763549803A5}~
~regedit.exe~
~FALSE~
~/s SetServiceName.reg~
~TRUE~
~~
~Run Program~
~{56298676-D416-4F0B-A427-B56917DAF768}~
~$TARGETDIR$\MyService.exe~
~FALSE~
~/s /install~
~TRUE~
~~


What is even more puzzling (concerning) is that it doesn't matter what order they appear in the Run Program, or what order I create them - they always are in the same order in the clipboard data, suggesting that I cannot control which one runs first...

This is hinting to me that I perhaps should try running a batch script...

Code: Select all

cmd.exe $TARGETDIR$\RegisterService.bat


I will give that a try.

[FrancescoT]

There are no errors with the clipboard data. This has to be in reverse order.

Some notes:

- please check that both "Run Program" commands are sequenced successively Apply Install (I'm supposing you used Install File(s) to install the service.exe into your target dir).

- Run Program regedit.exe /s SetServiceName.reg (WAIT) - Here you have to specify the full path of the "SetServiceName.reg" file.

- Then, select "Hide Program Window" with both commands ...to hide the window of the executables.

Hope this helps you.