Как работают службы в windows

Время на прочтение
16 мин

Количество просмотров 6.4K

Один из способов доморощенной классификации служб основывается на времени их жизни: некоторые из них запускаются сразу же при старте ОС, оставаясь активными постоянно (сюда, скажем, можно отнести веб-серверы и СУБД), другие же запускаются лишь при необходимости, делают свои архиважные дела и сразу завершаются; при этом, ни один из вариантов сам по себе не делает реализацию службы сложнее, однако второй требует от разработчика как минимум ещё и умения программно стартовать, а при необходимости и досрочно останавливать её работу. Именно указанный аспект управления службой, плюс добавление некоторых отсутствующих в штатной поставке Delphi возможностей, и сподвиг автора на данный опус.

Чтобы статья воспринималась максимально полезной и практичной, в ней предлагается заготовка (почти готовый к употреблению шаблон) службы, обрабатывающей очередь неких задач (или заданий – кому как больше нравится); после того, как все из них обработаны, служба тут же завершается. Если представить графически, то читатель познакомится со следующей конструкцией:

Техническое задание

Предложенное решение будет обладать перечисленными возможностями, а также предполагать следующее:

• Очередь рассматривается как некая абстрактная структура, то есть кем она реализована, где хранится (в файле, БД или где-то ещё) и как конкретно с ней взаимодействовать (в виде программного кода) – всё это непринципиально и слабо пересекается с темой материала, однако предполагается, что задачи в ней обладают как минимум двумя свойствами:
  • Приоритетом, задающим порядок обработки.
  • Статусом, допускающим три значения:
    1. Ожидает обработки.
    2. Успешно обработана.
    3. Ошибка (не удалось обработать).
• Служба:
  • Сразу после старта принимается за тяжкие труды и начинает, с учётом приоритета, извлекать из очереди задачи с первым статусом (который «ожидающий»), после чего, в зависимости от результата обработки, обновляет статус у каждой из них; работа прекращается после того, как в очереди не осталось необработанных элементов.
  • Если поступает команда на остановку, то обработка текущей задачи прерывается и служба завершается.
  • Во время работы может принять особую (нестандартную) команду от управляющего приложения (УП), суть которой описана чуть ниже.
  • Дабы не наделять службу чрезмерным набором прав, из-за которых может пострадать безопасность всей ОС, вместо обычно применяемого аккаунта LocalSystem станет использоваться специальный пользователь, создаваемый на лету.
  • При установке происходит автоматическое назначение минимально необходимых прав как пользователю самой службы (от имени которого она должна запускаться – о нём шла речь в предыдущем пункте), так и пользователю управляющего приложения.
• Управляющее приложение:
  • Подаёт команды на запуск и остановку службы, т. е. примерно то, что вручную делается через Диспетчер служб:

    

  • Также, когда служба уже активна, может подать ей команду заново обработать «ошибочные» задачи (те, что с третьим статусом) – необходимость в этом обычно возникает после устранения внешних проблем, помешавших штатно справиться с такими задачами в прошлом.

Служба

В данном случае, веских причин изобретать велосипед для реализации службы не имеется, поэтому основа дальнейшего кода – это стандартный для IDE подход к созданию, основанный на классе TService. Также необходимо отметить, что автор использует не самую новую версию Delphi (10.1 Berlin), в связи с чем в иных выпусках могут иметься свои особенности (в более свежих, к примеру, часть предложенного функционала может быть уже реализована, однако подобное маловероятно, учитывая стойкое нежелание разработчиков Delphi развивать TService).

Описание кода службы логично вести в соответствии с циклом её жизни в системе – то есть начать с момента установки (регистрации).

Установка

Собственно самостоятельно реализовывать регистрацию и не требуется, т. к. запуск исполняемого файла службы с ключом /install сделает всё необходимое – программист от данной рутины избавлен. Намного интересней выглядит момент сразу после установки (чему соответствует событие AfterInstall), где и удобно приступить к воплощению части означенного в ТЗ; однако, хотелось бы начать с малого и показать на простом примере как происходит изменение параметра установленной службы – будет сделано то, чего уже так давно не добавляют в Delphi – реализована возможность указать описание, отображаемое, например, в Диспетчере:

Основа обработчика указанного события, постепенно расширяемая далее, выглядит так:

interface

uses
  System.SysUtils, Vcl.SvcMgr;

...

implementation

uses
  Winapi.WinSvc;

resourcestring
  ServiceDescription = 'Шаблон (заготовка) службы, обрабатывающей очередь неких задач.';

procedure TQueueService.ServiceAfterInstall(Sender: TService);
var
  ManagerHandle, ServiceHandle: SC_HANDLE;
  Description: SERVICE_DESCRIPTION;
begin
  ManagerHandle := OpenSCManager(nil, nil, 0);

  if ManagerHandle = 0 then
    RaiseLastOSError;

  try
    ServiceHandle := OpenService( ManagerHandle, PChar(Name), SERVICE_CHANGE_CONFIG );

    if ServiceHandle = 0 then
      RaiseLastOSError;

    try
      Description.lpDescription := PChar(ServiceDescription);
      Win32Check( ChangeServiceConfig2(ServiceHandle, SERVICE_CONFIG_DESCRIPTION, @Description) );
    finally
      CloseServiceHandle(ServiceHandle);
    end;
  finally
    CloseServiceHandle(ManagerHandle);
  end;
end;

Здесь, прежде всего, выполняется получение дескриптора Менеджера служб (Service Control Manager), после чего у него запрашивается дескриптор уже нашей (только что установленной) службы по её имени; доступ к обоим объектам выбран минимально необходимый – SC_MANAGER_CONNECT и SERVICE_CHANGE_CONFIG, причём SC_MANAGER_CONNECT не требуется указывать, т. к. он подразумевается неявно (именно поэтому последний параметр функции OpenSCManager равен нулю).

Пользователь

Далее, чтобы непосредственно перейти к реализации описанных в начале требований, определимся с пользователем, от имени которого служба станет выполняться: до Windows 7 и Windows Server 2008 R2, если требовалось максимально ограничить службу в правах, дав ей исключительно те, что действительно нужны, было необходимо самостоятельно создавать обычного пользователя ОС – а теперь же появился виртуальный пользователь (virtual account), все заботы по управлению которым берёт на себя Windows. Применительно к службе (если делать это вручную через Диспетчер), для создания такого пользователя нужно лишь при указании его имени добавить префикс NT Service\, а пароль оставить пустым:

Казалось бы, чего проще – действуем аналогично в Инспекторе объектов Delphi и получаем тот же результат:

Но не тут-то было! В случае виртуального пользователя, WinAPI-функция CreateService, применяемая в модуле Vcl.SvcMgr для установки службы, в последнем параметре, содержащем пароль, должна получить значение nil, а не пустую строку,

Svc := CreateService(SvcMgr, PChar(Name), PChar(DisplayName),
  SERVICE_ALL_ACCESS, GetNTServiceType, GetNTStartType, GetNTErrorSeverity,
  PChar(Path), PChar(LoadGroup), PTag, PChar(GetNTDependencies),
  PSSN, PChar(Password));

Собственно подобное даже нельзя назвать ошибкой – скорее всего, разработчики Delphi просто-напросто не стали улучшать TService и добавлять распознавание префикса NT Service\ в имени, ведь до Windows 7 такой особенности элементарно не существовало. Поэтому, дабы не править стандартный модуль, ограничимся заданием пользователя уже после установки службы (т. е. предполагается, что свойства ServiceStartName и Password оставлены пустыми), для чего достаточно вызова лишь одной функции (часть ранее приводимого кода, ответственного за получение дескрипторов, опущена):

procedure TQueueService.ServiceAfterInstall(Sender: TService);
const
  VirtualAccountPrefix = 'NT Service\';
var
  ManagerHandle, ServiceHandle: SC_HANDLE;
  Description: SERVICE_DESCRIPTION;
  VirtualAccount: string;
begin
  ...

  Description.lpDescription := PChar(ServiceDescription);
  Win32Check( ChangeServiceConfig2(ServiceHandle, SERVICE_CONFIG_DESCRIPTION, @Description) );

  VirtualAccount := VirtualAccountPrefix + Name;
  Win32Check
    (
    ChangeServiceConfig
      (
      ServiceHandle,
      SERVICE_NO_CHANGE, SERVICE_NO_CHANGE, SERVICE_NO_CHANGE,
      nil, nil, nil, nil,
      PChar(VirtualAccount), nil,
      nil
      )
    );

  ...
end;

Надо сказать, что имя виртуального пользователя, указываемое после префикса, совсем не обязательно должно совпадать с именем службы – главное обеспечить его уникальность.

Права

На следующем этапе необходимо позаботиться о правах двух пользователей:

• Первым из них идёт вышеупомянутый виртуальный, проблема с которым такова: если попробовать запустить службу в текущем виде, то система сообщит об отказе в доступе, ибо только что созданный аккаунт не имеет прав на запуск исполняемого файла службы (их у него вообще кот наплакал – за это и выбран). Другими словами, требуется добавить вот такую запись:

  

• Вторым пользователем является тот, от имени которого запускается управляющее приложение, – дело в том, что любая команда (запуск, приостановка и т. п.) проверяется на наличие соответствующих прав у её инициатора, пока их, увы, не имеющего. Хотя в общем случае про УП служба может ничего не знать (оно, скажем, создаётся другим программистом на ином ЯП), но ситуация в статье иная и позволяет возложить на службу и данное бремя, а чтобы она знала какому пользователю выдать такие права, добавим новый ключ запуска /ControlUser, где после двоеточия необходимо указать имя; если привести конкретный пример, то теперь установку службы следует производить с такими ключами – /install /ControlUser:SomeUser1.

Доработки события под описанное выглядят следующим образом:

interface

uses
  System.SysUtils, Winapi.Windows, Vcl.SvcMgr;

...

implementation

uses
  Winapi.WinSvc, Winapi.AccCtrl, Winapi.AclAPI;

procedure TQueueService.ServiceAfterInstall(Sender: TService);

  procedure GrantAccess(const UserName, ObjectName: string; const ObjectType: SE_OBJECT_TYPE; const Rights: ACCESS_MASK);
  begin
    // Реализация процедуры приведена чуть ниже в статье.
    ...
  end;

const
  VirtualAccountPrefix = 'NT Service\';
  ControlUserSwitch = 'ControlUser';
var
  ManagerHandle, ServiceHandle: SC_HANDLE;
  Description: SERVICE_DESCRIPTION;
  VirtualAccount, ControlUserName: string;
begin
  ...

  Description.lpDescription := PChar(ServiceDescription);
  Win32Check( ChangeServiceConfig2(ServiceHandle, SERVICE_CONFIG_DESCRIPTION, @Description) );

  VirtualAccount := VirtualAccountPrefix + Name;
  Win32Check
    (
    ChangeServiceConfig
      (
      ServiceHandle,
      SERVICE_NO_CHANGE, SERVICE_NO_CHANGE, SERVICE_NO_CHANGE,
      nil, nil, nil, nil,
      PChar(VirtualAccount), nil,
      nil
      )
    );
  GrantAccess( VirtualAccount, ParamStr(0), SE_FILE_OBJECT, GENERIC_READ or GENERIC_EXECUTE );

  if FindCmdLineSwitch(ControlUserSwitch, ControlUserName) then
    GrantAccess(ControlUserName, Name, SE_SERVICE, SERVICE_START or SERVICE_STOP or SERVICE_USER_DEFINED_CONTROL);

  ...
end;

Константа SERVICE_USER_DEFINED_CONTROL у пользователя УП отвечает за право на передачу нестандартной команды, указанной в требованиях. Реализация же GrantAccess основана на C++-примере из документации Microsoft:

procedure GrantAccess(const UserName, ObjectName: string; const ObjectType: SE_OBJECT_TYPE; const Rights: ACCESS_MASK);
var
  SecurityDescriptor: PSECURITY_DESCRIPTOR;
  OldDACL, NewDACL: PACL;
  UserAccess: EXPLICIT_ACCESS;
begin
  CheckOSError
    (
    GetNamedSecurityInfo
      (
      PChar(ObjectName),
      ObjectType,
      DACL_SECURITY_INFORMATION,
      nil,
      nil,
      @OldDACL,
      nil,
      SecurityDescriptor
      )
    );
  try
    BuildExplicitAccessWithName( @UserAccess, PChar(UserName), Rights, SET_ACCESS, NO_INHERITANCE );
    CheckOSError( SetEntriesInAcl(1, @UserAccess, OldDACL, NewDACL) );
    try
      CheckOSError
        (
        SetNamedSecurityInfo
          (
          PChar(ObjectName),
          ObjectType,
          DACL_SECURITY_INFORMATION,
          nil,
          nil,
          NewDACL,
          nil
          )
        );
    finally
      LocalFree( HLOCAL(NewDACL) );
    end;
  finally
    LocalFree( HLOCAL(SecurityDescriptor) );
  end;
end;

Завершая изыскания с AfterInstall, необходимо отметить, что любое исключение в этом событии приведёт к удалению только что установленной службы (с записью текста исключения в журнал Windows), а в приведённом коде его может сгенерировать, к примеру, функция Win32Check.

В заключение подраздела также хочется остановиться на моменте, связанном с правами, назначенными выше пользователю УП: если, предположим в целях отладки, их необходимо поменять, то совершенно не обязательно для этого удалять и заново устанавливать службу – достаточно воспользоваться всем известной утилитой Process Explorer: когда служба запущена, следует открыть её свойства и перейти на вкладку Services, после чего пройтись по показанным шагам:

Обработка очереди

Как известно, Delphi предлагает два подхода к реализации службы (подробнее о них можно узнать в материале на другом ресурсе в разделе «3. События службы»):

1. На основе событий OnStart и OnStop, что подразумевает самостоятельное создание потоков, содержащих нужный функционал.
2. На основе события OnExecute, обработчик которого выполняется в заранее заботливо созданном TService потоке, причём служба сразу же остановится после выхода из события; именно данный вариант хорошо подходит под поставленную в статье цель – как только в очереди обработаны все задачи, делать больше нечего и необходимо завершиться.

Основа события

В первом приближении код OnExecute прост и незатейлив – идёт извлечение задач до тех пор, пока они имеются в очереди:

procedure TQueueService.ServiceExecute(Sender: TService);
type
  TTask = ...; // Конкретный тип зависит от деталей Вашей реализации.
  TTaskList = array of TTask; // Массив использован лишь для иллюстрации, допустимы любые другие структуры данных (TList<TTask>, например).

  function ExtractTaskPortion(out Tasks: TTaskList): Boolean;
  begin
    // Функция вернёт True в случае, если в очереди ещё есть задачи для обработки (при этом
    // содержаться они будут в параметре Tasks).
    ...

    Result := Length(Tasks) > 0;
  end;

  procedure ProcessTask(const Task: TTask);
  begin
    // После обработки задачи, процедура должна обновить её статус (на 2-й или 3-й).
    ...
  end;

var
  Task: TTask;
  Tasks: TTaskList;
begin
  while ExtractTaskPortion(Tasks) do
    for Task in Tasks do
      ProcessTask(Task);
end;

Стоит пояснить, что задачи берутся не по одиночке, а именно порциями исходя из соображения, что в реальном мире обычно затраты на получение сразу нескольких элементов из хранилища значительно ниже, чем их выборка по одному (именно так, скажем, обстоит дело с базами данных).

Прерывание обработки

Несложно заметить, что в текущем виде не предусмотрено никакого механизма по прекращению цикла извлечения задач, а ведь причин такого прерывания, согласно ТЗ, может быть две:

1. Команда на остановку службы, после которой никакого ожидания обработки текущей задачи быть не должно – она прерывается как можно быстрее, после чего все оставшиеся в порции задачи тоже отбрасываются и служба завершается.
2. Команда на повторную обработку задач с третьим статусом, для чего необходимо прервать работу по текущей (как и в случае команды на остановку), обновить статус всех означенных задач на первый, запросить новую порцию и далее действовать как обычно; надобность прерывать обработку текущей порции связана с тем, что среди задач с только что установленным первым статусом могут иметься обладающие бо́льшим приоритетом.

В качестве решения данной проблемы предлагается воспользоваться исключениями – они в этом случае выступят в полном соответствии со своим названием, то есть будут сигнализировать не об ошибке, а именно об исключительной, прерывающей нормальное течение алгоритма ситуации (в нашем случае таковой являются команды от Менеджера служб и УП). Для этого сначала объявим новый класс исключения, содержащий поле с причиной прерывания:

...

implementation

...

type
  EInterruption = class(Exception)
  public
    type
      TReason = (irStop, irErrorsReset);
  public
    Reason: TReason;
    constructor Create(const Reason: TReason);
  end;

constructor EInterruption.Create(const Reason: TReason);
begin
  inherited Create(string.Empty);
  Self.Reason := Reason;
end;

...

Это исключение станет генерироваться в новой локальной процедуре CheckInterruption (как – об этом чуть позже), а реакция на него имеет следующий вид:

procedure TQueueService.ServiceExecute(Sender: TService);
type
  TTask = ...;
  TTaskList = array of TTask;

  function ExtractTaskPortion(out Tasks: TTaskList): Boolean;
  begin
    ...
  end;

  procedure CheckInterruption;
  begin
    // Отвечает за возбуждение исключения EInterruption.
    ...
  end;

  procedure ProcessTask(const Task: TTask);
  begin
    ...
  end;

  procedure ResetQueueErrors;
  begin
    // Меняет 3-й статус на первый у всех задач в очереди.
    ...
  end;

var
  Task: TTask;
  Tasks: TTaskList;
begin
  while ExtractTaskPortion(Tasks) do
    try
      for Task in Tasks do
        ProcessTask(Task);
    except
      on E: EInterruption do
        case E.Reason of
          irStop: Break;
          irErrorsReset: ResetQueueErrors;
          else raise;
        end;
    end;
end;

От разработчика требуется лишь вставлять вызов CheckInterruption периодически, через небольшие этапы обработки задачи в ProcessTask, навроде такого:

procedure ProcessTask(const Task: TTask);
begin
  // Некие действия (например инициализация обработки).
  CheckInterruption;
  ...

  // Ещё какой-то этап.
  CheckInterruption;
  ...

  // Некий этап-цикл.
  for ... to ... do
  begin
    CheckInterruption;
    ...
  end;

  // Обновление статуса задачи.
  CheckInterruption;
  ...
end;

Взаимодействие с Менеджером служб

В рассматриваемом событии осталось реализовать ещё три вещи, две из которых удобно объединить в одной CheckInterruption – во-первых, требуется наконец уже реальная генерация исключения, а во-вторых, служба обязана периодически извещать Менеджер о своём статусе, а также получать пришедшие от него же сообщения и реагировать на них. Если сообщение об остановке службы TService в основном обрабатывает сам, то вот специальная команда от УП требует дополнительного кодирования, заключающегося, прежде всего, в переопределении виртуального метода DoCustomControl – в нашем случае там достаточно всего лишь сохранять переданный службе целочисленный код команды в заведённом для этой цели поле FCustomCode:

interface

...

type
  TQueueService = class(TService)
    procedure ServiceAfterInstall(Sender: TService);
    procedure ServiceExecute(Sender: TService);
  private
    FCustomCode: DWORD;
  protected
    function DoCustomControl(CtrlCode: DWord): Boolean; override;
  ...
  end;

...

implementation

...

function TQueueService.DoCustomControl(CtrlCode: DWord): Boolean;
begin
  Result := inherited;
  FCustomCode := CtrlCode;
end;

Теперь можно полностью реализовать процедуру:

procedure CheckInterruption;
begin
  ReportStatus;
  FCustomCode := 0;
  ServiceThread.ProcessRequests(False); // Внутри вызывается DoCustomControl.

  if Terminated then
    raise EInterruption.Create(irStop);

  case FCustomCode of
    RESET_QUEUE_ERRORS_CONTROL_CODE: raise EInterruption.Create(irErrorsReset);
  end;
end;

Здесь методы ReportStatus и ProcessRequests отвечают за взаимодействие с Менеджером, а константа RESET_QUEUE_ERRORS_CONTROL_CODE (её допустимые значения см. в описании параметра dwControl) объявлена в новом модуле Services.Queue.Constants:

unit Services.Queue.Constants;

interface

const
  RESET_QUEUE_ERRORS_CONTROL_CODE = 128;

implementation

end.

Полезность добавления модуля проистекает из того факта, что управляющее приложение в нашем случае тоже написано на Delphi и при отправке специальной команды эта константа в нём тоже потребуется:

Кстати, если читатель задаётся вопросом о целесообразности добавления поля FCustomCode, когда, казалось бы, можно сгенерировать исключение прямо в методе DoCustomControl,

function TQueueService.DoCustomControl(CtrlCode: DWord): Boolean;
begin
  Result := inherited;

  case CtrlCode of
    RESET_QUEUE_ERRORS_CONTROL_CODE: raise EInterruption.Create(irErrorsReset);
  end;
end;

то ответ довольно прост – в модуле Vcl.SvcMgr вызов DoCustomControl окружён конструкцией try...except, перехватывающей любые исключения без разбора (а вся обработка сводится к добавлению записей с их текстом в Windows-лог).

Окончательный вариант

В качестве последнего штриха к реализации службы, необходимо разобраться хоть и с небольшой (в плане устранения), но всё же загвоздкой, а именно: в текущем виде, если в очереди все задачи обработаны, но некоторые из них имеют третий статус (завершились ошибкой), то заново такие взять в работу не получится – служба после старта станет сразу завершаться, а, соответственно, и не сможет никогда принять команду от УП на повторную обработку ошибок. К счастью, при запуске службы можно передать ей произвольное количество текстовых параметров, хотя в данном случае достаточно одного параметра-флага – факт его наличия будет говорить о том, что ещё перед циклом по очереди требуется вызвать уже применявшуюся процедуру ResetQueueErrors:

procedure TQueueService.ServiceExecute(Sender: TService);

  ...

  procedure ResetQueueErrors;
  begin
    // Меняет 3-й статус на первый у всех задач в очереди.
    ...
  end;

var
  I: Integer;
  Task: TTask;
  Tasks: TTaskList;
begin
  for I := 0 to ParamCount - 1 do
    if Param[I] = ResetQueueErrorsParam then
    begin
      ResetQueueErrors;
      Break;
    end;

  while ExtractTaskPortion(Tasks) do
    try
      for Task in Tasks do
        ProcessTask(Task);
    except
      on E: EInterruption do
        case E.Reason of
          irStop: Break;
          irErrorsReset: ResetQueueErrors;
          else raise;
        end;
    end;
end;

Важно понимать, что эти параметры не имеют ничего общего с ключами, использующимися при установке и удалении, – те применяются при самостоятельном запуске исполняемого файла службы, а свойство Param содержит то, что было передано специальной WinAPI-функции, предназначенной для старта служб (она будет упомянута в следующем разделе). Что касается константы ResetQueueErrorsParam, то она объявлена в модуле Services.Queue.Constants:

unit Services.Queue.Constants;

interface

const
  RESET_QUEUE_ERRORS_CONTROL_CODE = 128;

  ResetQueueErrorsParam = 'ResetErrors';

implementation

end.

Управляющее приложение

В целях сосредоточения на главном, и дабы не отвлекаться на второстепенные нюансы, УП представляет собой обычный VCL-проект из одной простейшей формы, состоящей из 4-х кнопок; вместе с тем, весь приводимый код использует только WinAPI, поэтому применять его можно где угодно – хоть в другой службе, хоть вообще поместить в DLL.

Кнопки отвечают за уже знакомые действия:

1. Запуск без изысков (как будто через Диспетчер служб).
2. Аналогично первой кнопке, но с параметром, отвечающим за предварительный сброс у задач третьего статуса.
3. Передача службе специальной команды (см. константу RESET_QUEUE_ERRORS_CONTROL_CODE).
4. Остановка службы (как будто через Диспетчер служб).

Предварительные действия

В дальнейшем довольно часто будет требоваться дескриптор Менеджера служб, поэтому, чтобы не получать его каждый раз заново, сделаем это при создании формы; также сотворим полезный метод OpenService, избавляющий далее от дублирования кода и возвращающий дескриптор службы:

interface

uses
  Winapi.Windows, System.SysUtils, ..., Winapi.WinSvc;

type
  TForm1 = class(TForm)
    ...
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
  private
    FSCMHandle: SC_HANDLE;

    function OpenService(const Access: DWORD): SC_HANDLE;
  end;

...

implementation

procedure TForm1.FormCreate(Sender: TObject);
begin
  FSCMHandle := OpenSCManager(nil, nil, 0);
  if FSCMHandle = 0 then
    RaiseLastOSError;
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  CloseServiceHandle(FSCMHandle);
end;

function TForm1.OpenService(const Access: DWORD): SC_HANDLE;
begin
  Result := Winapi.WinSvc.OpenService( FSCMHandle, PChar('QueueService'), Access );
  if Result = 0 then
    RaiseLastOSError;
end;

Основной код

Запуск службы – без параметров и с ними – отличается незначительно (и там и там применяется одна и та же WinAPI-функция), поэтому видится разумным создать у формы метод, который затем и вызывать при нажатии на первые две кнопки:

interface

...

type
  TForm1 = class(TForm)
    ...
  private
    ...
    procedure RunService(const Parameters: array of string);
  end;

...

implementation

...

procedure TForm1.RunService(const Parameters: array of string);
var
  ServiceHandle: SC_HANDLE;
  Arguments: array of PChar;
  I: Integer;
begin
  ServiceHandle := OpenService(SERVICE_START);
  try
    if Length(Parameters) = 0 then
      Win32Check( StartService(ServiceHandle, 0, PPChar(nil)^) )
    else
    begin
      SetLength( Arguments, Length(Parameters) );

      for I := Low(Parameters) to High(Parameters) do
        Arguments[I] := PChar(Parameters[I]);

      Win32Check( StartService(ServiceHandle, Length(Arguments), Arguments[0]) );
    end;
  finally
    CloseServiceHandle(ServiceHandle);
  end;
end;

Параметр-массив Parameters позволяет указать как раз тот набор параметров запуска службы, о которых шла речь выше. Итак, имея новый метод, очень легко закодировать обработчики у первой половины кнопок:

...

implementation

uses
  Services.Queue.Constants;

...

procedure TForm1.bStartClick(Sender: TObject);
begin
  RunService([]);
end;

procedure TForm1.bStartAndResetErrorsClick(Sender: TObject);
begin
  RunService([ResetQueueErrorsParam]);
end;

Две последние кнопки тоже позволяют обойтись вызовом одного и того же дополнительного метода, с совсем уж простой реализацией:

interface

...

type
  TForm1 = class(TForm)
    ...
  private
    ...
    procedure SendCommandToService(const Access, ControlCode: DWORD);
  end;

...

implementation

...

procedure TForm1.SendCommandToService(const Access, ControlCode: DWORD);
var
  ServiceHandle: SC_HANDLE;
  ServiceStatus: TServiceStatus;
begin
  ServiceHandle := OpenService(Access);
  try
    Win32Check( ControlService(ServiceHandle, ControlCode, ServiceStatus) );
  finally
    CloseServiceHandle(ServiceHandle);
  end;
end;

Здесь в переменной ServiceStatus возвращается последнее, самое свежее состояние службы, однако оно в данном контексте неинтересно, поэтому полученное значение просто игнорируется. Таким образом, 3-я и 4-я кнопки на нажатие реагируют так:

...

implementation

...

procedure TForm1.bResetErrorsClick(Sender: TObject);
begin
  SendCommandToService(SERVICE_USER_DEFINED_CONTROL, RESET_QUEUE_ERRORS_CONTROL_CODE);
end;

procedure TForm1.bStopClick(Sender: TObject);
begin
  SendCommandToService(SERVICE_STOP, SERVICE_CONTROL_STOP);
end;

Последнее, о чём хочется сказать, касается нестандартных команд (рассмотренная служба реагирует только на одну – RESET_QUEUE_ERRORS_CONTROL_CODE): если они в Вашем случае являются более сложными, требующими для выполнения дополнительную информацию, а не просто факт получения службой одного числового кода, то для передачи таких сведений придётся задействовать механизмы межпроцессного обмена – разделяемую память, неименованные каналы и т. п.

Весь показанный исходный код можно скачать здесь.

From Wikipedia, the free encyclopedia

In Windows NT operating systems, a Windows service is a computer program that operates in the background.^[1] It is similar in concept to a Unix daemon.^[1] A Windows service must conform to the interface rules and protocols of the Service Control Manager, the component responsible for managing Windows services. It is the Services and Controller app, services.exe, that launches all the services and manages their actions, such as start, end, etc.^[2]

Windows services can be configured to start when the operating system is started and run in the background as long as Windows is running. Alternatively, they can be started manually or by an event. Windows NT operating systems include numerous services which run in context of three user accounts: System, Network Service and Local Service. These Windows components are often associated with Host Process for Windows Services. Because Windows services operate in the context of their own dedicated user accounts, they can operate when a user is not logged on.

Prior to Windows Vista, services installed as an «interactive service» could interact with Windows desktop and show a graphical user interface. In Windows Vista, however, interactive services are deprecated and may not operate properly, as a result of Windows Service hardening.^[3][4]

Administration[edit]

Windows administrators can manage services via:

• The Services snap-in (found under Administrative Tools in Windows Control Panel)
• Sc.exe
• Windows PowerShell

Services snap-in[edit]

The Services snap-in, built upon Microsoft Management Console, can connect to the local computer or a remote computer on the network, enabling users to:^[1]

• view a list of installed services along with service name, descriptions and configuration
• start, stop, pause or restart services^[5]
• specify service parameters when applicable
• change the startup type. Acceptable startup types include:
  • Automatic: The service starts at system startup.
  • Automatic (Delayed): The service starts a short while after the system has finished starting up. This option was introduced in Windows Vista in an attempt to reduce the boot-to-desktop time. However, not all services support delayed start.^[6]
  • Manual: The service starts only when explicitly summoned.
  • Disabled: The service is disabled. It will not run.
• change the user account context in which the service operates
• configure recovery actions that should be taken if a service fails
• inspect service dependencies, discovering which services or device drivers depend on a given service or upon which services or device drivers a given service depends
• export the list of services as a text file or as a CSV file

Command line[edit]

The command-line tool to manage Windows services is sc.exe. It is available for all versions of Windows NT.^[7] This utility is included with Windows XP^[8] and later^[9] and also in ReactOS.

The sc command’s scope of management is restricted to the local computer. However, starting with Windows Server 2003, not only can sc do all that the Services snap-in does, but it can also install and uninstall services.^[9]

The sc command duplicates some features of the net command.^[10]

The ReactOS version was developed by Ged Murphy and is licensed under the GPL.^[11]

Examples[edit]

The following example enumerates the status for active services & drivers.^[12]

The following example displays the status for the Windows Event log service.^[12]

PowerShell[edit]

The Microsoft.PowerShell.Management PowerShell module (included with Windows) has several cmdlets which can be used to manage Windows services:

• Get-Service^[13]
• New-Service^[14]
• Restart-Service^[15]
• Resume-Service^[16]
• Set-Service^[17]
• Start-Service^[18]
• Stop-Service^[19]
• Suspend-Service^[20]

Other management tools[edit]

Windows also includes components that can do a subset of what the snap-in, Sc.exe and PowerShell do. The net command can start, stop, pause or resume a Windows service.^[21] In Windows Vista and later, Windows Task Manager can show a list of installed services and start or stop them. MSConfig can enable or disable (see startup type description above) Windows services.

Installation[edit]

Windows services are installed and removed via *.INF setup scripts by SetupAPI; an installed service can be started immediately following its installation, and a running service can be stopped before its deinstallation.^[22][23][24]

Development[edit]

Writing native services[edit]

For a program to run as a Windows service, the program needs to be written to handle service start, stop, and pause messages from the Service Control Manager (SCM) through the System Services API. SCM is the Windows component responsible for managing service processes.

Wrapping applications as a service[edit]

The Windows Resource Kit for Windows NT 3.51, Windows NT 4.0 and Windows 2000 provides tools to control the use and registration of services: SrvAny.exe acts as a service wrapper to handle the interface expected of a service (e.g. handle service_start and respond sometime later with service_started or service_failed) and allow any executable or script to be configured as a service. Sc.exe allows new services to be installed, started, stopped and uninstalled.^[25]

See also[edit]

Windows services

• List of Microsoft Windows components § Services
• Windows Service Hardening
• svchost.exe

Concept

• Background process
  • Daemon (computing)
  • DOS Protected Mode Services
  • Terminate-and-stay-resident program
  • Device driver
• Operating system service management
  • Service Control Manager
  • Service Management Facility
• Service wrapper

References[edit]

Further reading[edit]

• Savill, John (5 March 1999). «What are the ErrorControl, Start and Type values under the Services subkeys?». Windows IT Pro. Penton Media. Retrieved 29 March 2013.
• David B. Probert, Windows Service Processes

External links[edit]

• Windows Sysinternals: Autoruns for Windows v13.4 – An extremely detailed query of services
• Service Management With Windows Sc From Command Line – Windows Service Management Tutorial
• Windows Service Manager Tray

Операционная система для своей работы запускает достаточно большое количество процессов, которые создаются программами, запущенными на ПК, а также системными службами ОС.

Данные службы представляют собой системные программы, запускаемые на ПК совместно с запуском Windows для выполнения своих функций. При этом некоторые системные программы не нужны пользователю, но во время своей работы используют ресурсы компьютера. Также не следует забывать о том, что некоторые такие программы могут нести в себе потенциальную опасность для системы. Все дело в том, что системные программы используют в своей работе сеть интернет, создавая дополнительные порты открытого типа. Для тех пользователей, которые не знают что означает порт, следует разъяснить, что речь идет о канале, который позволяет попасть информации на компьютер из внешнего мира.

Как правило в процессе работы программы, несущие потенциальную опасность ПК, осуществляют сканирование его на наличие таких открытых портов. Это осуществляется для того, чтобы через них передать некую информацию, несущую вред компьютеру.

Из вышеизложенного следует, что опасность заразиться каким-либо вирусом пропорциональна количеству открытых портов. Различные стандартные службы запускаются автоматически без разрешения пользователя, который просто не обращает на них внимание. Имеются специальные программы, цель которых сканировать сеть на наличие ПК с различными типами уязвимости, чтобы ими воспользоваться.

Поэтому многие пользователи задумываются над тем, имеется ли возможность влиять на запуск системных служб. Оказывается, что такая возможность имеется, однако необходимо тщательно продумывать собственные действия. Речь идет о том, многие системные службы настолько взаимосвязаны друг с другом, что повлияв на одну, можно повредить рабочий процесс самой операционной системы. Перед тем как отключать не нужный процесс, следует определить чем занимается данная служба. Это можно осуществить несколькими способами, первый из которых описание службы в самой системе, а второй — поиск описания в Интернете.

Система подскажет чем занимается служба в соответствующей консоли, которая расположена в Панели управления или же в консоле управления ПК. Пользователю следует зайти в Пуск, в котором имеется опция Управление, а в ней уже раздел Службы. Уже там будет предоставлен список служб, которые имеются в данной операционной системе. Из этого списка выделяется  искомая служба, нажатием левой клавиши мышки, чтобы иметь возможность изменить ее. Пользователю будет предложено выбрать из трех вариантов запуска: автоматический режим, ручной и отключение. При полной уверенности ненужности данной службы пользователю необходимо выбрать третий вариант.

Статья о службах Windows, их предназначении и настройке.

Сегодняшнюю статью, пожалуй-ка, начну я с небольшой присказки :)…

Случилось это, когда я был еще только чуть продвинутее простого «чайника» (ну, там, Windows умел переустанавливать, да программы разные). Был у меня принтер (кстати, до сих пор еще верой и правдой служит!), которым пользовались только время от времени.

И вот как-то раз, после того, как он простоял без дела пару месяцев, случилась сиюминутная необходимость что-то распечатать. Отправил я документ на печать, а принтер-то и не работает. При этом все огоньки-индикаторы горят, в Диспетчере устройств мой Canon IP1500 отображается, но в Очереди печати – пустота…

Вот так, товарищи, и произошло мое первое (и не совсем приятное) знакомство со Службами Windows. Оказалось, что всему виной были не драйверы, которые я кинулся переустанавливать, не поломка принтера, а просто отключение системной оснастки Диспетчер очереди печати!

Зачем нужны службы

Наверное, все знают, что при переустановке Windows требуется установить не только все нужные программы, но еще и драйверы. Драйверы представляют собой подпрограммы и наборы библиотек всяческих команд, которые позволяют системе максимально продуктивно взаимодействовать с аппаратной частью Вашего ПК.

Например, если в системе нет драйвера Вашего принтера, то она не сможет опознать его как устройство и, соответственно, мы не сможем на нем печатать. И так со всеми компонентами, основными из которых являются:

• чипсет;
• видеокарта;
• звуковая карта;
• сетевая карта;
• модули беспроводной связи (WiFi, Bluetooth, NFC и т.п.).

Так вот, служба, выражаясь по-просту, является системной программой, которая позволяет Windows обращаться ко всем установленным драйверам, управляющим той или иной частью аппаратной «начинки» Вашего компьютера:

Например, если вернуться к описанной выше проблеме, служба Диспетчер очереди печати сама по себе не является драйвером принтера. Она служит своеобразным тумблером, который позволяет (или не позволяет) системе распечатывать что-либо, обращаясь к драйверу.

Особенности работы служб

Все активные службы запускаются автоматически вместе с Windows и иногда, наряду с программами, могут сильно тормозить загрузку системы. Но об этом немного позже. Сейчас нам важно знать, что службы работают одинаково для всех учетных записей на ПК и зачастую не требуют вмешательства пользователя.

Однако, случаются ситуации, когда та или иная служба дает сбой. Причин может быть несколько:

1. Ошибочное или злонамеренное действие пользователя ПК (отключение службы, удаление ее файла или записи в реестре).
2. Последствия деятельности компьютерных вирусов.
3. Системный сбой (вызванный, например, механическим воздействием или перепадом напряжения).

Поскольку, мы уже знаем, что службы по своей сути являются своеобразными выключателями тех или иных функций, то во всех случаях решения может быть фактически только два. Неработающую службу нужно либо просто повторно запустить (что требуется чаще всего), либо переустановить (некоторые службы без переустановки самой системы переустановить, увы, нереально).

Думаю, с теорией на сегодня покончено, поэтому переходим к практике…

Просмотр и настройка служб

Посмотреть список всех установленных служб в новых версиях Windows (начиная с Vista) можно прямо в Диспетчере задач, который вызывается сочетанием клавиш CTRL+SHIFT+Esc:

Управлять службами в Диспетчере задач удобно, если требуется просто быстро проверить, активна ли определенная служба и запустить (либо отключить) ее. Для этих действий используется контекстное меню.

Кроме функций запуска/перезапуска/остановки и открытия оснастки служб, в Windows 8 в меню появилась приятная возможность – «Поиск в Интернете». Она позволяет быстро найти информацию по выбранной службе во Всемирной Сети.

Однако, далеко не все пользуются современными операционными системами. У многих еще стоит старая добрая Windows XP. И там Диспетчер задач довольно скудный. Получить доступ к службам во всех без исключения Windows можно альтернативным способом – через одноименную системную оснастку. Открывается она так: «Пуск» (или «Компьютер» в Windows → Панель управления → Администрирование → Службы (либо при помощи команды «services.msc» (без кавычек) в строке «Выполнить»):

Перед нами откроется окно, содержащее список установленных на компьютере служб. В нижней части окна есть две вкладки, позволяющие переключаться между Стандартным и Расширенным видом списка. Советую сразу переключиться в «Расширенный» режим, чтобы видеть все свойства служб.

Каждая служба в списке имеет ряд характеристик:

1. Имя (по этому имени можно найти данные о службе в Интернете).
2. Описание (если описания нет или оно на английском, значит служба не является системной).
3. Состояние (индикатор активности службы).
4. Тип запуска (определяет вариант загрузки службы).
5. Вход от имени (указывает на то, используется ли служба каким-то системным компонентом или другой службой).

В расширенном режиме слева от списка служб имеется поле, в котором выводится основная информация о выбранном сервисе и действия для его запуска/перезапуска или остановки. Эти же действия можно осуществить при помощи контекстного меню.

Если же по службе кликнуть дважды левой кнопкой мыши или выбрать в контекстном меню пункт «Свойства», то мы сможем добраться до настроек:

В разных версиях Windows количество вкладок со свойствами службы будет разное, но везде первой открывается вкладка «Общие». Она позволяет увидеть все основные параметры выбранного сервиса и здесь же настроить тип его запуска. Типов, в зависимости от установленной версии Windows, может быть 3 или 4:

1. Автоматически (отложенный запуск). Данный тип запуска появился впервые в Windows Vista и позволяет автоматически запустить службу с низким приоритетом после полной загрузки ПК.
2. Автоматически. Тип запуска активный по умолчанию для большинства системных служб. Запускает сервис автоматически с высоким приоритетом при загрузке Windows.
3. Вручную. При выборе данного типа служба не загружается вместе с системой, но может быть активирована автоматически, если Вы запустите программу, требующую активности данного сервиса, либо включите службу вручную.
4. Отключена. При таком типе запуска включить службу можно только вручную.

О том, какие типы запуска и для каких служб лучше применить мы рассмотрим далее, а сейчас пройдемся по оставшимся вкладкам Свойств.

• «Вход в систему». Если Вы являетесь Администратором ПК, то здесь можете выбрать будет ли служба запускаться от имени системы или же будет работать только с определенной учетной записью (требуется ввод логина и пароля профиля пользователя, для которого запускается служба).
• «Восстановление». Здесь можно указать действия, которые должны выполняться при неудачном запуске службы (попытка перезапуска, сохранение отчета или запуск определенной программы).
• «Зависимости». Эта вкладка нужна для просмотра того, зависят ли от выбранной службы какие-либо компоненты системы.

Последняя вкладка может пригодиться в том случае, если Вы не уверены, нужна служба или от нее ничего не зависит и ее можно отключить.

Отключение служб

И вот мы добрались до самого главного Как мы уже поняли, службы в Windows играют важную, но далеко не критическую, роль. Поэтому для ускорения загрузки ПК иной раз бывает целесообразно либо полностью отключить некоторые сервисы, либо активировать их отсроченный старт или запуск по требованию.

При этом важно понимать, что, отключив определенную службу, мы лишимся какой-то части функционала операционной системы. Поэтому, здесь действует принцип «не навреди». То есть, если не знаете, для чего нужна та или иная служба, лучше ее не трогайте. А еще лучше, поищите о ней сведения в Интернете, а потом решайте.

Увы, универсального рецепта настройки служб не существует. У каждого на компьютере, помимо десятков стандартных сервисов, имеется еще ряд сторонних, которые были установлены различными программами (например, антивирусом, каким-либо эмулятором и т.п.). Службы антивирусного ПО нельзя отключать, а вот, например, тип запуска службы эмулятора виртуального дисковода Daemon Tools или виртуальной машины BlueStack вполне себе можно сделать «Вручную».

Есть здесь и еще один «фокус». Для всех нестандартных служб (как мы помним, у них зачастую нет русского описания) можно установить тип запуска «Автоматически (отложенный запуск)». Так мы сохраним их работу (а то мало ли что :)) и немного облегчим загрузку системе. Единственный нюанс – на ноутбуках так нежелательно тормозить службы, которые взаимодействуют с драйверами чипсета.

Наконец, есть и ряд системных служб, которые при определенных условиях можно безболезненно отключить вовсе. Приведу их список ниже в виде таблички с именем службы и тем, что мы потеряем при ее отключении:

Имя службы	Что мы потеряем при отключении
KtmRm для координатора распределенных транзакций	какая-то системная служба, которую даже сама Windows рекомендует отключать, если Вы не знаете зачем она нужна
Автономные файлы	поддержка автономных файлов, к которым запрещен доступ из сети (в принципе, пока мы не дадим доступ к определенной папке, все файлы и так автономны :))
Агент политики IPSec	защита протокола TCP/IP на сетевом уровне (в принципе, современные браузеры по умолчанию проверяют все пакеты ничуть не хуже и на программном уровне)
Адаптивная регулировка яркости	работа сенсора освещенности (если его нет, то смело отрубаем)
Брандмауэр Windows	работа встроенного брандмауера (можно отключать, если хотите установить сторонний файрволл или отключить его вообще :))
Браузер компьютеров	отображение других компьютеров в Сетевом окружении (если компьютер не подключен к локальной сети, можно отключать)
Вспомогательная служба IP	поддержка протокола IPv6 (пока не особо нужна)
Вторичный вход в систему	возможность запуска процессов от имени других пользователей (лучше отключить, хотя бы в целях безопасности)
Диспетчер печати	поддержка принтеров (в т.ч. и виртуальных)(если нет принтера и не нужно ничего сохранять в PDF можно отключать)
Доступ к HID-устройствам	поддержка USB-клавиатур и мышей (отключать можно только на ПК с устройствами ввода подключенными к портам PS/2)
Защитник Windows	работа штатной системы защиты от вирусов (лучше отключить и заменить его нормальным полноценным антивирусом)
Клиент отслеживания изменившихся связей	функция отслеживания и протоколирования перемещения файлов в пределах ПК или по сети (смело отключайте для экономии ресурсов)
Модули ключей IPsec для обмена ключами в Интернете и протокола IP с проверкой подлинности	параноидальный способ защиты сетевого подключения
Обнаружение SSDP	собственно, работа с удаленными устройствами по протоколу SSDP (вряд ли Вы пользуетесь чем-то подобным :))
Поиск Windows	стандартный поиск при помощи кнопки F3 (можно отключить, если Вы редко что-то ищете)
Политика удаления смарт-карт	блокировка компьютера при извлечении смарт-карты (сомневаюсь, что у кого-то есть такие :))
Служба ввода планшетного ПК	поддержка сенсорного экрана (если у Вас нет сенсорного экрана – отключайте)
Служба инициатора Майкрософт iSCSI	поддержка устройств с интерфейсом iSCSI
Служба поддержки Bluetooth	собственно, поддержка блютуза (если такового нет – выключаем)
Служба регистрации ошибок Windows	отправка отчетов об ошибках «любимому» MicroSoft’у
Удаленный реестр	доступ к реестру по локальной сети
Факс	поддержка приема факса через встроенный модем (в современных компьютерах такого уже нет)
Шифрованная файловая система (EFS)	штатная функция шифрования файлов (если шифроваться не от кого – выключаем :))

Фу-у-ух В моем списке, вроде, все. Может, я что-то и пропустил, но о большей части второстепенных стандартных служб упомянул точно. Можете свериться с приведенным списком и безболезненно отключить большинство из упомянутых служб у себя.

Выводы

Настройка служб, как Вы могли убедиться, дело не такое уж и страшное, но и тут не помешает осторожность. Еще раз напомню, что, если Вы не уверены в том, нужна Вам определенная служба или нет, лучше поищите о ней информацию в Интернете, и только потом решайте, что с ней делать.

В любом случае, вот Вам еще одна подстраховка. Практически все настройки служб хранятся в реестре по адресу: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services. Чтобы обезопасить себя от возможных ошибок, перед началом правки параметров служб экспортируйте данную ветку (контекстное меню – Экспортировать) в reg-файл, чтобы иметь возможность быстро восстановить все, как было.

Успешных Вам настроек и быстрой загрузки компьютера!

P.S. Разрешается свободно копировать и цитировать данную статью при условии указания открытой активной ссылки на источник и сохранения авторства Руслана Тертышного.

Среди программ любой операционной системы и, в частности — ОС Windows, есть такие, которые работают в фоновом режиме и выполняют функции посредника. Эти программы организуют взаимодействие приложений между собой, а также с драйверами устройств и компонентами операционной системы. Фоновые процессы подобного рода принято называть службами операционной системы.

Что представляют собой службы Windows

Службы операционной системы — это программный процесс, предназначенный для организации взаимодействия различных программных и аппаратных компонентов компьютерной системы. Запуск служб Windows происходит автоматически в момент загрузки компьютера, важнейшие службы продолжают работу до момента его выключения. Остальные службы (активируются) задействуются по мере необходимости.

В частности, операционная система Windows постоянно контролирует состав оборудования с целью обнаружить подключение или отключение устройств, выполняет сетевые операции независимо от прочих работ и вообще следит за происходящим на компьютере. Все подобные действия выполняются с помощью служб.

Функции служб

Каждая служба Windows предназначена для выполнения конкретной операции. Существуют, например, службы обновления, служба времени, служба печати, служба безопасности, сетевые службы Windows и другие.

Автоматический запуск и постоянная работа служб Windows позволяет операционной системе выполнять необходимые операции, причем пользователь не должен явно давать какую-либо команду или запускать соответствующую программу.

Преимущество концепции служб, впервые введенной в операционной системе Windows NT, состоит в том, что становятся доступным независимые средства управления компьютерной системы. Имеются возможность запускать службы, а также корректно останавливать или приостанавливать их. Если на операционную систему возлагаются новые функции, для их выполнения задействуются дополнительные службы.

Как работают службы Windows

Любая программа может обратиться к активной службе операционной системы для выполнения соответствующих действий. В результате ряд операций выносится за пределы приложений и, тем самым, программы становятся проще и эффективнее. Постоянная активность процесса, представляющего службу, не приводит к значительной потере в производительности системы. Каждая активная служба занимает определенный участок в оперативной памяти, но не расходует впустую ресурсы процессора.

Работа служб Windows  организована по принципу “запрос-ответ“. Приложение обращается к службе для выполнения конкретных действий. Служба активизируется, выполняет запрошенную операцию, сообщает приложению о результате и снова возвращается в пассивное состояние до очередного запроса.

К некоторым службам приложения обращаются регулярно, другие могут ни разу не потребоваться на протяжении месяцев работы. В последнем случае приходится говорить о бесполезных затратах оперативной памяти, выделенной неиспользуемой службе. В этом случае удается повысить эффективность работы компьютера, изменив настройки служб.

Отключение служб Windows

К сожалению, каких- либо средств прямого управления набором служб, имеющихся на компьютере, не предусмотрено. Однако пользователь может доступные ему службы подключать и отключать. Отключением служб Windows обычно занимаются по двум причинам.

• Во-первых, отключение неиспользуемых служб позволяет более эффективно использовать оперативную память компьютера. Оперативная память — это один из наиболее ценных ресурсов, сильно влияющий на производительность. Если объем оперативной памяти близок к минимальным техническим требованиям операционной системы, даже небольшая экономия дает заметный эффект.
• Вторая причина для отключения ненужных служб — это безопасность работы. Каждый активный процесс — это потенциальная уязвимость системы. В первую очередь это касается служб, предназначенных для выполнения сетевых функций. К таким сетевым службам Windows часто разрешено обращаться извне, через сеть, и вредоносная программа при определенных условиях может использовать недочеты в службе для проникновения на компьютер. Если соответствующая служба операционной системы отключена, то доступа к ней нет, и данное направление проникновения вредоносных программ перекрыто.

Читать далее:

Серверная операционная система: особенности и критерии выбора

Надежная платформа, обеспечивающая максимальные возможности