Delphi Service on Vista
Andrew Venmore
and would appreciate any help solving the problems.
I deploy an application to provide a user interface (similar to MSSQL2000's
SQL Service Manager) which can install, start and stop a Service in another
.exe. The Service reads it's configuration from an ini file, fetches mail
from a POP3 server and creates records in an MSSQL database. The application
installs the Service by executing the .exe with the /install parameter, and
must be "Run as Administrator" to launch the Service .exe with enough
privileges to make it's registry entries, so I have included in the manifest
requestedExecutionLevel requireAdministrator (a note on this: if this is in
the .exe's manifest, trying to run the Delphi debugger results in the
message "Unable to create process." unless Delphi is also Run as
Administrator).
Now the service installs correctly when commanded, but if I try to start the
service it appears briefly in the Task Manager's Processes list and then
shuts down. Examining the Windows Application Event Log shows a message
about "...faulting module IndySystem110.bpl...".
Opening the installed Service's properties shows that it is set to run under
the Local System's account. After changing this to run under an
Administrator's account, the Service starts normally. This would indicate
that the Service is trying to access resources that it does not have
permission to under the Local System account. Research led me to:
Services Hardening in Windows Vista
(http://www.microsoft.com/technet/technetmag/issues/2007/01/SecurityWatch/);
Per-service SID
(http://blogs.technet.com/voy/archive/2007/03/22/per-service-sid.aspx);
Tools for Managing ACLs
(http://www.microsoft.com/technet/technetmag/issues/2007/07/SecurityWatch/default.aspx);
To summarize: the Local System account in Vista has minimal privileges; in
order to avoid giving this account (and hence other services) permissions to
resources, a per-service SID (Security Identifier) can be created; this is
done via the ChangeServiceConfig2 API or the command-line tool "sc sidtype
[service name] unrestricted"; this SID is generated from the service name,
so is static across systems, enabling deployment scripts to be created that
use the Vista command-line tool icacls.exe; this SID can be added to
resources using the shell ACL editor (e.g.
right-click-<folder>|Properties|Security - the Service will appear as a user
with its service name and permissions can be assigned - same for RegEdit).
If I change my installed Service's sidtype, I do not see the Service as a
user in a folder's ACL editor when trying to edit the permissions. This may
be because the Service is not running (and it won't start), or more likely
because I haven't understood something.
My first question is: has anyone had experience deploying a service that
requires access to restricted resources on Vista?
But even if I solve the problem of permissions, I still don't know which
resources my application requires (it uses a number of 3rd party libraries,
so not all the code is my own). I thought I would be clever and added
Sleep(30000) at the start of the application and in the initialization of
the first unit to give time to "Attach to Process", but the Service still
shuts down before the debugger can be attached.
An option I found is to use SvCom's
(http://www.aldyn-software.com/svcom.html) service emulator and TService
Delphi-component replacement so that the Service initialization code can be
debugged, otherwise I will be reduced to brute-force chopping of code until
it makes a difference.
My second question is: does anyone have a strategy for debugging service
initialization code?
Many thanks,
Andrew
Andrew Venmore
news:46c62e2d$1...@newsgroups.borland.com...
> Now the service installs correctly when commanded, but if I try to start
> the service it appears briefly in the Task Manager's Processes list and
> then shuts down. Examining the Windows Application Event Log shows a
> message about "...faulting module IndySystem110.bpl...".
>
Without solving either of the problems I thought I needed to, I found it was
something else. The full Event Log message was:
"Faulting application MyService.exe, version 1.0.0.0, time stamp 0x46d320f9,
faulting module MyBPL.bpl, version 6.0.6000.16386, time stamp 0x4549bdc9,
exception code 0xc0000135, fault offset 0x00008fc7, process id 0x608,
application start time 0x01c7e8e2ce14fdf1."
The key was "exception code 0xc0000135" which is the ntstatus.h code
STATUS_DLL_NOT_FOUND. The version number is also suspicious. In my
development enviroment I output my BPLs to a single, different folder to the
.exes which remain in the project folders, and have the BPL folder on the
path. The Local System user doesn't have this folder on its path, so it was
simply not finding the BPLs. I had installed the service .exe which uses
runtime packages from a folder without the BPLs, so copying the BPLs into
the same folder (as I do when I deploy them) solved the problem. This also
makes sense why no initialization code got to run.
--
Andrew