Статья:
Программирование служб: подробности

Автор(ы): Сергей Холодилов
Дата: 22.06.2003
В статье описаны некоторые детали программирования служб Windows NT/2000/XP. Большая часть содержащихся в статье утверждений описывает реакцию Windows на какие-то действия службы. Если вы написали первую службу и хотите двигаться дальше, эта статья вам поможет.

Авторы:
Сергей Холодилов

Аннотация:
В статье описаны некоторые детали программирования служб Windows NT/2000/XP. Большая часть содержащихся в статье утверждений описывает реакцию Windows на какие-то действия службы. Если вы написали первую службу и хотите двигаться дальше, эта статья вам поможет.

Здравствуйте, SergH, Вы писали:

SH>Здравствуйте, SLI, Вы писали:

SLI>>И зачем было писать в статье вот такой бред:
SLI>>"На первый взгляд задействовано три потока: один исполняет main/WinMain, второй – ServiceMain, третий – Handler[Ex] (не совсем так, см. «Мелочи»). Очевидно, что первый и третий потоки не подходят."

SLI>>Кто тебе это сказал про HandlerEx, или ты свои догадки помещаешь сюда? Какой отдельный поток для HandlerEx? У тебя на один поток больше указано.

SH>Учись читать. Написано же ясно: "На первый взгляд... (не совсем так, см. «Мелочи»)". Я вкурсе, что Handler[Ex] и main/WinMain это один поток, это не мои догадки, я проверял с помощью GetCurrentThreadId(). Но я не считаю этот факт скольконибудь важным, поэтому упомянул его только в разделе Мелочи. На который и ссылаюсь.

Учись писать- это тупая догадка ни на чем не основана, это ощущение лишнего потока возникло у тебя лично и к другим не относится. Потока-то нет. Разберись с тем что такое поток!

Какой умный мальчик — и Соломона с Руссиновичем он прочитал даже. Дак вот только :"Смотрю в книгу- вижу..." А рекомендовать не буду. Ты любишь учить- ну и учи.
У меня кстати не возникло подозрения про лишний поток. Так что это только у тебя.

Здравствуйте, dimchick, Вы писали:

D>структурка маленькая — ~80 байт. просто я не люблю такой подход.

Я тоже. Но в данном случае процесс заверщается почти сразу по завершению ServiceMain.. Моей совести этого достаточно

D>я тут подумал, _endthread тоже некорректно. По прототипу ServiceMain не подходит для создания потока, Значит ее кто-то вызывает и по возвращению из нее может что-то делать.

Логично. Хуже того, этот "кто-то" может быть написан на C и использовать RTL.

D>Почему MS не дала возможность создавать поток нам?

При большом желании можно обойти ситуацию "вручную". Т.е. вначале ServiceMain определять, была ли RTL инициализирована, и, если нет — инициализировать. А в конце очищать, если в начале инициализировали. Сделать логично в виде объекта, который в конструкторе проверяет и инициализирует, а в деструкторе очищает.

Здравствуйте, SergH, Вы писали:

ПРИМЕЧАНИЕ
Для реализации этой возможности привлечены неслабые средства. В Spy++ видно, что окна (MessageBox) принадлежат одному из потоков CSRSS.EXE. Это имеет забавный побочный эффект: сообщение может висеть на экране даже после завершения приложения. Соберите и запустите такую программку:
.
#define _WIN32_WINNT 0x0500
#include <windows.h>
int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
MessageBox(NULL, "try to kill me", "undead", MB_SERVICE_NOTIFICATION);
return 0;
}
.
А теперь попробуйте убить процесс из Task Manager’а. Если сделать несколько потоков, можно проверить ExitProcess, она в этой ситуации тоже не помогает.

На XP (pro-sp2) такой MessageBox принадлежит своему приложению, а не CSRSS.

Чтобы принадлежал CSRSS (с сопутствуюшими эффектами):

.code

ThreadProc proc lparam:LPARAM
  invoke MessageBox,0,"message","caption",MB_SERVICE_NOTIFICATION
  ret
ThreadProc endp

start:
  invoke CreateThread,0,0,offset ThreadProc,0,0,0
  invoke CloseHandle,eax
  invoke Sleep,10
  invoke ExitProcess,0
end start

.

По всему, пашиным хозяевам позарез нужна война в Европе
(уверены — к ним не залетит, в предыдущих двух не залетало жеж)

P>Спасибо за ответы.

P>1) А что такое SFL? Где о нём почитать?
В "Исходниках".

P>2) Так я не понял, приложенные к статье сервисы только у меня не запускаются или у всех на Win 2003 под Local System? Как их (или настройки винды) подправить, чтобы запускались?

Не знаю, меня эти сервисы не интересовали. Попробуйте устанавливать эти сервисы при помощи sc.exe, а не встроенными инсталляторами. Встроенные инсталляторы, вообще говоря, не совсем удачны.

Здравствуйте, potap, Вы писали:

P>1) А что такое SFL? Где о нём почитать?

http://rsdn.ru/article/baseserv/sfl.xml

Автор(ы): Igor Vartanov
Дата: 14.03.2005
В переписке с одним из членов RSDN Team я как-то неосторожно заявил, что не пишу сервисы направо и налево, подразумевая, что пишу я их очень редко. Да, я ошибался. Случилось так, что я был вынужден за достаточно короткий срок написать несколько сервисов – сначала один, и затем, спустя совсем небольшое время, еще парочку. Приступив к написанию второго, я вдруг почувствовал острое ощущение бессмысленности траты времени на тупое копирование типового кода. А впереди ведь ожидал еще и третий проект… Поэтому работа над вторым сервисом была отложена в сторону (по принципу «лучше день потерять, зато потом за пять минут долететь»), и был написан код, впоследствии легший в основу SFL.

P>2) Так я не понял, приложенные к статье сервисы только у меня не запускаются или у всех на Win 2003 под Local System? Как их (или настройки винды) подправить, чтобы запускались?

попробовал serv_tiny (ShutdownCounter) на win2003 sp2 — установился, под Local System запускается

Здравствуйте, Odi$$ey, Вы писали:

OE>попробовал serv_tiny (ShutdownCounter) на win2003 sp2 — установился, под Local System запускается

SERV ("My cool Service") — тоже все OK

Здравствуйте, Аноним, Вы писали:

А>Учись писать-

Учусь.

А>это тупая догадка ни на чем не основана, это ощущение лишнего потока возникло у тебя лично и к другим не относится.

У тебя не возникло? Верю. Только за всех не надо.

А>Потока-то нет.

Вот ведь блин! Оказывается и нет! Чувствовал же, что-то там не так...

А>Разберись с тем что такое поток!

Напиши статью на эту тему. Буду рад, если почерпну что-нибудь новое. Ссылки на нечитанные мною материалы по этому поводу также приветствуюся. Рихтера, Соломона с Руссиновичем и MSDN я вроде читал, ссылки на них не предлагать.

Это еще не все особенности...
Во первых в Win2003 в SericeMain не передаются параметры и второе — не устанавливается текущим фолдер откуда было запущено приложение, а остается в System32 — откуда запускается ServiceManager.

Здравствуйте, Сергей Холодилов, Вы писали:

СХ>Статья:
СХ>Программирование служб: подробности

СХ>Авторы:
СХ> Сергей Холодилов

СХ>Аннотация:
СХ>В статье описаны некоторые детали программирования служб Windows NT/2000/XP. Большая часть содержащихся в статье утверждений описывает реакцию Windows на какие-то действия службы. Если вы написали первую службу и хотите двигаться дальше, эта статья вам поможет.

И зачем было писать в статье вот такой бред:
"На первый взгляд задействовано три потока: один исполняет main/WinMain, второй – ServiceMain, третий – Handler[Ex] (не совсем так, см. «Мелочи»). Очевидно, что первый и третий потоки не подходят."

Кто тебе это сказал про HandlerEx, или ты свои догадки помещаешь сюда? Какой отдельный поток для HandlerEx? У тебя на один поток больше указано.

Здравствуйте, SLI, Вы писали:

SLI>И зачем было писать в статье вот такой бред:
SLI>"На первый взгляд задействовано три потока: один исполняет main/WinMain, второй – ServiceMain, третий – Handler[Ex] (не совсем так, см. «Мелочи»). Очевидно, что первый и третий потоки не подходят."

SLI>Кто тебе это сказал про HandlerEx, или ты свои догадки помещаешь сюда? Какой отдельный поток для HandlerEx? У тебя на один поток больше указано.

Учись читать. Написано же ясно: "На первый взгляд... (не совсем так, см. «Мелочи»)". Я вкурсе, что Handler[Ex] и main/WinMain это один поток, это не мои догадки, я проверял с помощью GetCurrentThreadId(). Но я не считаю этот факт скольконибудь важным, поэтому упомянул его только в разделе Мелочи. На который и ссылаюсь.

Здравствуйте все.

Код, про который так много написано в статье:
http://sergh.pisem.net/articles/service_code.zip

Здравствуйте, SergH, Вы писали:

SH>Код, про который так много написано в статье:
SH>http://sergh.pisem.net/articles/service_code.zip

http://www.rsdn.ru/article/baseserv/services_details/service_code.zip

Здравствуйте, SergH, Вы писали:

SH>Здравствуйте, SLI, Вы писали:

SLI>>И зачем было писать в статье вот такой бред:
SLI>>"На первый взгляд задействовано три потока: один исполняет main/WinMain, второй – ServiceMain, третий – Handler[Ex] (не совсем так, см. «Мелочи»). Очевидно, что первый и третий потоки не подходят."

SLI>>Кто тебе это сказал про HandlerEx, или ты свои догадки помещаешь сюда? Какой отдельный поток для HandlerEx? У тебя на один поток больше указано.

SH>Учись читать. Написано же ясно: "На первый взгляд... (не совсем так, см. «Мелочи»)". Я вкурсе, что Handler[Ex] и main/WinMain это один поток, это не мои догадки, я проверял с помощью GetCurrentThreadId(). Но я не считаю этот факт скольконибудь важным, поэтому упомянул его только в разделе Мелочи. На который и ссылаюсь.

Вот ты советуешь научиться читать, а сам то не очень это умеешь. Про то где исполняется HandlerEx разжовано у Рихтера с Кларком. Ты пишешь что прочитал их, и тут же выдаешь такой ляп про "кажется". А еще и проверять умудряешься с помощью получения TID. Тяжелый случай.

Здравствуйте, Аноним, Вы писали:

А>Вот ты советуешь научиться читать, ...

Нахамил напрасно. Ивиняюсь перед всеми собравшимися.

А>Про то где исполняется HandlerEx разжовано у Рихтера с Кларком. Ты пишешь что прочитал их, и тут же выдаешь такой ляп про "кажется". А еще и проверять умудряешься с помощью получения TID. Тяжелый случай.

1. Мало ли у кого что написано. Проверить никогда не мешает. Предложи другой метод проверки.
2. Нормальному человеку, который не читал Рихтера, Кларка, MSDN и прочее в голову не придёт предположить, что Handle[Ex] и WinMain выполняются одним потоком. Это и называется на первый взгляд.
3. То, что это один поток практически не влияет на програмирование служб. Поэтому я почти не уделяю этому факту внимание. Если ты считешь, что влияет, укажи как.

Здравствуйте, SergH, Вы писали:

Меня что возмутило- ты приводишь свою догадку, а опровергаешь ее в конце статьи. Нафиг так делать?
Слова "не совсем так" означают небольшое расхождение- а тут разница в том есть поток или нет- это принципиально!
Это меня очень разозлило. И как только редакторы эту строчку пропустили.

Здравствуйте, Аноним, Вы писали:

А>Меня что возмутило- ты приводишь свою догадку, а опровергаешь ее в конце статьи.

Это — не моя догадка. Мне догадываться не надо. Я знаю, что там потока два, а не три, я читал об этом и сам проверял.
Я нигде не говорю, что это правда. Я говорю: "На первый взгляд .. " и тут же уочняю, что это первый взгляд несколько ошибочен. Я сомневаюсь, что всем с первого взгляда очевидно, где какой поток. Так как не вижу никаких серьёзных предпосылок к использованию именно такой архитектуры. Возможно так немного удобнее разработчикам ОС. Но разве это аргумент для Microsoft?

А>Нафиг так делать?

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

А>Слова "не совсем так" означают небольшое расхождение- а тут разница в том есть поток или нет- это принципиально!

В отличии от тебя я считаю это не принципиальным. Потому как могли сделать так, а могли иначе, а могут поменять. Повторюсь — глубоких причин, по которым лишний поток не создаётся я не вижу. Ну, окромя оптимизации ресурсов, но она не очень-то глубокая. А как всё это влияет на программиста я вообще не понимаю. Мне, как разработчику службы, плевать на то в одном потоке выполняется Hannler и main или в разных. Если вдруг начнут создавать отдельный поток, я, скорее всего, ни строчки не поменяю.

А>Это меня очень разозлило.

А зря.

А>И как только редакторы эту строчку пропустили.

Это на support@rsdn.ru — пусть adontz порадуется

Здравствуйте, Сергей Холодилов, Вы писали:

СХ>Статья:


СХ>Авторы:
СХ> Сергей Холодилов

СХ>Аннотация:
СХ>В статье описаны некоторые детали программирования служб Windows NT/2000/XP. Большая часть содержащихся в статье утверждений описывает реакцию Windows на какие-то действия службы. Если вы написали первую службу и хотите двигаться дальше, эта статья вам поможет.
Прошу прощения, я взял ваш код и попытался его скомпилировать, но VC упорно не хочет его линковать и выдаёт ошибку линкера в стиле "не найдена функция WinMain". В чём может быть проблема?

Здравствуйте, Bob Kotl, Вы писали:

BK>Прошу прощения, я взял ваш код и попытался его скомпилировать, но VC упорно не хочет его линковать и выдаёт ошибку линкера в стиле "не найдена функция WinMain". В чём может быть проблема?

Наверное в том, что пример — консольное приложение, в нем действительно нет WinMain.

Здравствуйте, SergH, Вы писали:

SH>Здравствуйте, Bob Kotl, Вы писали:

BK>>Прошу прощения, я взял ваш код и попытался его скомпилировать, но VC упорно не хочет его линковать и выдаёт ошибку линкера в стиле "не найдена функция WinMain". В чём может быть проблема?

SH>Наверное в том, что пример — консольное приложение, в нем действительно нет WinMain.
так я меняю define _WINDOWS на _CONSOLE, и всё равно не хочет... почему?

Здравствуйте, Bob Kotl, Вы писали:

BK>так я меняю define _WINDOWS на _CONSOLE, и всё равно не хочет... почему?

В примере проект полностью, т.е с dsp и dsw-файлами. Попробуй его так и собирать. Только что взял код с сайта, проверил проекты Serv и serv_tiny, компилится и собирается без проблем. Среда — VC6 SP5

Здравствуйте, SergH, Вы писали:

SH>Здравствуйте, Bob Kotl, Вы писали:

BK>>так я меняю define _WINDOWS на _CONSOLE, и всё равно не хочет... почему?

SH>В примере проект полностью, т.е с dsp и dsw-файлами. Попробуй его так и собирать. Только что взял код с сайта, проверил проекты Serv и serv_tiny, компилится и собирается без проблем. Среда — VC6 SP5
пардон, недосмотрел кое-что в установках проекта. В опциях линкера почему-то стояло /subsystem:windows. Поставил /subsystem:console — помогло.
Sorry

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

Мне интересен следующий вопрос.
MS рекомендует работать в ServiceMain. Поток для него создает SCM с помощью CreateThread (это предположение — потому как других вариантов нет).
В MSDN'не же не рекомендуется пользоватся CreateThread. Вместо этого нужно пользоваться родными ф-ми создания потока (_beginthread напр). Почему? Объяснять наверное не надо.

как быть? у меня 2 варианта
1. Создавать в ServiceMain новый поток и возвращать управление
2. завершать ServiceMain _endthread

какие варианты будут у Вас?
-----
zap

Здравствуйте, Аноним, Вы писали:

А>безполезная трата времени, трафика и нервов.

Нервы то зачем? Не надо их тратить на дурацкие статьи, не стоят они того.. И не не дурацкие не надо, всё равно не стоят..

А>Мне интересен следующий вопрос.
А>MS рекомендует работать в ServiceMain. Поток для него создает SCM с помощью CreateThread (это предположение — потому как других вариантов нет).
А>В MSDN'не же не рекомендуется пользоватся CreateThread. Вместо этого нужно пользоваться родными ф-ми создания потока (_beginthread напр). Почему? Объяснять наверное не надо.

Я только одну причину знаю — инициализируется библиотека C. И деинициализируется при завершениии потока. Если имеется ввиду что-то иное, объясни.

А>как быть? у меня 2 варианта
А>1. Создавать в ServiceMain новый поток и возвращать управление
А>2. завершать ServiceMain _endthread
3. Я бы забил на диенициализацию. Смерть процесса всё очистит. А инициализация произойдёт при первом обращении к функциям, которые в ней нуждаются. Во всяком случае, так написано у Рихтера и практика, вроде подтверждает. Исходники CRT на эту тему, правда, не смотрел.

А>какие варианты будут у Вас?

Извини, я привык на ты. Предлагаю и тебе, хотя бы в общении со мной.

Здравствуйте, SergH, Вы писали:

SH>Я только одну причину знаю — инициализируется библиотека C. И деинициализируется при завершениии потока. Если имеется ввиду что-то иное, объясни.

это и имел ввиду. для каждого потока создается структурка THREAD_INFO. удаляется в _endthread.

void _RTLENTRY _EXPFUNC _endthread(void)
{
    THREAD_DATA *t;
    HANDLE h;

    if ((t = _thread_data()) != NULL)
    {
        _unsetexc(t->thread_excep);
        h = t->thread_handle;
        _thread_data_del(t);
        CloseHandle(h);
    }
    ExitThread(0);
}

А>>как быть? у меня 2 варианта
А>>1. Создавать в ServiceMain новый поток и возвращать управление
А>>2. завершать ServiceMain _endthread
SH>3. Я бы забил на диенициализацию. Смерть процесса всё очистит.

typedef struct _thread_data
{
    struct _thread_data *thread_link; /* next struct on free list */
    void    *thread_arglist;        /* argument list to pass to thread_func */
    HANDLE  thread_handle;          /* handle of thread object */
    int     thread_errno;           /* errno */
    int     thread_doserrno;        /* _doserrno */
    void    (_USERENTRY *thread_func)(void *); /* thread starting address */
    char    *thread_token;          /* pointer to next strtok() token */
    char    *thread_template;       /* pointer to temp filename template */
    int     thread_mbshift;         /* shift state for mbtowc() */
    int     thread_wcshift;         /* shift state for wctomb() */
    void    (_USERENTRY **thread_sig)();/* pointer to signal table */
    void    *thread_excep;          /* exception registration pointer */
    void    *thread_time;           /* data used by time functions */
    void    *thread_cvt;            /* array used by fcvt() and ecvt() */
    void    *thread_strbuf;         /* array used by strerror() */
    void    *thread_passbuf;        /* array used by getpass() */
    void    *thread_pathbuf;        /* array used by searchpath() */
    __seed_t   thread_seed;         /* random number seed */
    void    *thread_exceptvars;
#if defined(_MBCS)
    int     thread_lead_byte;       /* pending leadbyte data used by putch() */
#endif
    int     thread_ex_mode;         /* 1 means _beginthreadex was called */
    int     thread_xtra;            /* extra place holder. unused for now */
} THREAD_DATA;

структурка маленькая — ~80 байт. просто я не люблю такой подход.

SH>А инициализация произойдёт при первом обращении к функциям, которые в ней нуждаются. Во всяком случае, так написано у Рихтера и практика, вроде подтверждает. Исходники CRT на эту тему, правда, не смотрел.
исходники тоже

SH>Извини, я привык на ты. Предлагаю и тебе, хотя бы в общении со мной.
ок.

я тут подумал, _endthread тоже некорректно. По прототипу ServiceMain не подходит для создания потока, Значит ее кто-то вызывает и по возвращению из нее может что-то делать.
Почему MS не дала возможность создавать поток нам?

PS у меня тот же вопрос к ф-ии BeginThread в BCB. Она не совместима с _beginthread.
вобщем выход — не юзать RTL.

Здравствуйте, SergH, Вы писали:

SH>Логично. Хуже того, этот "кто-то" может быть написан на C и использовать RTL.

Имелось ввиду, что просто деинициализировать RTL, даже не завершая поток, тоже нехорошо. .

Здравствуйте, SergH, Вы писали:

SH>Здравствуйте, SergH, Вы писали:

SH>>Логично. Хуже того, этот "кто-то" может быть написан на C и использовать RTL.

SH>Имелось ввиду, что просто деинициализировать RTL, даже не завершая поток, тоже нехорошо. .
почему? мы деиницализируем свой RTL. он никак не связан с RTL системы.

у меня получалось деинициализировать RTL только если он влинкован в приложение (заюзал ф-ию _thread_data_del + _thread_data).
динамическая библиотека не экспортирует ф-ии для работы с THREAD_DATA

Здравствуйте, dimchick, Вы писали:

D>почему? мы деиницализируем свой RTL. он никак не связан с RTL системы.

Имхо, данные они хранят в TLS. Или не так? Если так, то очищаая ячейку TLS, мы деинициализируем RTL для текущего потока, независимо от того, в dll он или в статически скомпонован.

Но могу ошибаться, про TLS это я так бы сделал, как у них не знаю.

Здравствуйте, SergH, Вы писали:

SH>Здравствуйте, dimchick, Вы писали:

D>>почему? мы деиницализируем свой RTL. он никак не связан с RTL системы.

SH>Имхо, данные они хранят в TLS. Или не так? Если так, то очищаая ячейку TLS, мы деинициализируем RTL для текущего потока, независимо от того, в dll он или в статически скомпонован.

SH>Но могу ошибаться, про TLS это я так бы сделал, как у них не знаю
в tls хранится указатель на структуру
[ccode].
extern DWORD __thread _tlsindex; /* thread local storage index (tls.c) */

THREAD_DATA * _thread_data(void)
{
THREAD_DATA *p;

/* If no thread data has been allocated for this thread, allocate
* it and save a pointer to it in the thread local storage block.
*/
if ((p = (THREAD_DATA *)_tlsindex) == NULL)
{
p = _thread_data_new();
_tlsindex = (DWORD)p;
}
return p;
}
[/code]

Здравствуйте, dimchick, Вы писали:

DD>в tls хранится указатель на структуру

Ну я это и имел ввиду, понятно, что 80 байт туда пихать — плохой вариант.

как бы получить доступ к этой ячейке

Здравствуйте, SergH, Вы писали:

SH>Имхо, данные они хранят в TLS. Или не так? Если так, то очищаая ячейку TLS, мы деинициализируем RTL для текущего потока, независимо от того, в dll он или в статически скомпонован.

Сорри, понял свою ошибку. У разных RTL будут разные ячейки.

процедура удаления немного сложная в реализации

void _thread_data_del(THREAD_DATA *t)
{
    _lock(thread_lock,"locking thread data (del)");

    /* Place the block on the free list for re-use later */
    t->thread_link = free_list;
    free_list = t;

    _unlock(thread_lock,"unlocking thread data (del)");
}

нужно получить доступ к _lock_nt и free_list.

зы. чувствую что проще забить

Здравствуйте, Сергей Холодилов, Вы писали:

СХ>Статья:
СХ>Программирование служб: подробности

Автор(ы): Сергей Холодилов
Дата: 22.06.2003
В статье описаны некоторые детали программирования служб Windows NT/2000/XP. Большая часть содержащихся в статье утверждений описывает реакцию Windows на какие-то действия службы. Если вы написали первую службу и хотите двигаться дальше, эта статья вам поможет.

СХ>Авторы:
СХ> Сергей Холодилов

СХ>Аннотация:
СХ>В статье описаны некоторые детали программирования служб Windows NT/2000/XP. Большая часть содержащихся в статье утверждений описывает реакцию Windows на какие-то действия службы. Если вы написали первую службу и хотите двигаться дальше, эта статья вам поможет.

А каким образом заставить сервисв примере работать в SafeMode 2000/XP?

Здравствуйте, Сергей Холодилов, Вы писали:

СХ>Статья:
СХ>Программирование служб: подробности

Автор(ы): Сергей Холодилов
Дата: 22.06.2003
В статье описаны некоторые детали программирования служб Windows NT/2000/XP. Большая часть содержащихся в статье утверждений описывает реакцию Windows на какие-то действия службы. Если вы написали первую службу и хотите двигаться дальше, эта статья вам поможет.

СХ>Авторы:
СХ> Сергей Холодилов

СХ>Аннотация:
СХ>В статье описаны некоторые детали программирования служб Windows NT/2000/XP. Большая часть содержащихся в статье утверждений описывает реакцию Windows на какие-то действия службы. Если вы написали первую службу и хотите двигаться дальше, эта статья вам поможет.

Здравствуйте,
Вопрос: при удалении службы, удаляется и ключ реестра хранения MyServiceEventSource, а как же быть с dll которая занята процессом EvengLog?

Здравствуйте, Сергей Холодилов, Вы писали:

СХ>Статья:
СХ>Программирование служб: подробности

Автор(ы): Сергей Холодилов
Дата: 22.06.2003
В статье описаны некоторые детали программирования служб Windows NT/2000/XP. Большая часть содержащихся в статье утверждений описывает реакцию Windows на какие-то действия службы. Если вы написали первую службу и хотите двигаться дальше, эта статья вам поможет.

СХ>Авторы:
СХ> Сергей Холодилов

СХ>Аннотация:
СХ>В статье описаны некоторые детали программирования служб Windows NT/2000/XP. Большая часть содержащихся в статье утверждений описывает реакцию Windows на какие-то действия службы. Если вы написали первую службу и хотите двигаться дальше, эта статья вам поможет.

Отличная статья. Я Написал сервис на основе этой статьи (простенький тсп-сервер), только затруднение вызвала ф-ция ServiceMain, пропару в ней допустил, флажок один не указал. Не хотелось тупо передирать из статьи, х0телось понять как работает. Вобщем всё ясно с сервисами, во время действий ни одно животное не пострадало % ) Комп перегружал раз 30. Там фишка, что не удалишь сервис, пока комп не перегрузишь, если неправильно что-то сделал в службе.

А как насчет Window Server 2003?
Ни serv, ни serv_tiny не запустились Пишут ошибка 5 — access denied.
Правда, если я их запускаю не под Local System, а под конкретным именем, то запускаются. В чем может быть дело? Заранее спасибо за ответ.

N>Это еще не все особенности...
N>Во первых в Win2003 в SericeMain не передаются параметры и второе — не устанавливается текущим фолдер откуда было запущено приложение, а остается в System32 — откуда запускается ServiceManager.

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

2potap — используйте SFL для построения служб. Все нормально запускается.

Спасибо за ответы.

1) А что такое SFL? Где о нём почитать?
2) Так я не понял, приложенные к статье сервисы только у меня не запускаются или у всех на Win 2003 под Local System? Как их (или настройки винды) подправить, чтобы запускались?


Здравствуйте, Andrew S, Вы писали:

N>>Это еще не все особенности...
N>>Во первых в Win2003 в SericeMain не передаются параметры и второе — не устанавливается текущим фолдер откуда было запущено приложение, а остается в System32 — откуда запускается ServiceManager.

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

AS>2potap — используйте SFL для построения служб. Все нормально запускается.

Здравствуйте, potap, Вы писали:

P>А как насчет Window Server 2003?
P>Ни serv, ни serv_tiny не запустились Пишут ошибка 5 — access denied.
P>Правда, если я их запускаю не под Local System, а под конкретным именем, то запускаются. В чем может быть дело?

Сорри, под рукой нету 2003-й. Найду — посмотрю. Когда статья писалась такой системы ещё не существовало

Здравствуйте, Andrew S, Вы писали:

AS> Попробуйте устанавливать эти сервисы при помощи sc.exe, а не встроенными инсталляторами. Встроенные инсталляторы, вообще говоря, не совсем удачны.

Что подразумевается под "встроенными инсталляторами"? Почему неудачны?

AS>> Попробуйте устанавливать эти сервисы при помощи sc.exe, а не встроенными инсталляторами. Встроенные инсталляторы, вообще говоря, не совсем удачны.

SH>Что подразумевается под "встроенными инсталляторами"? Почему неудачны?

cmdline.
Почему "неудачны" — не отслеживают наличие у пользователя привилегии для запуска служб. Хотя,впрочем, они и пользователя задать не позволяют
В общем, слишком малофункциональны.

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

Я это починил вот так:

HANDLE g_ErrorLogMutex=0;
...
SECURITY_DESCRIPTOR sds={0};
SECURITY_ATTRIBUTES sat={0};
InitializeSecurityDescriptor(&sds, SECURITY_DESCRIPTOR_REVISION);
SetSecurityDescriptorDacl(&sds, TRUE, NULL, FALSE);
sat.nLength = sizeof(sat);
sat.lpSecurityDescriptor = &sds;
sat.bInheritHandle = FALSE;
g_ErrorLogMutex=CreateMutex(&sat,FALSE,"Global\\ErrorLogMutex");
if(!g_ErrorLogMutex)
    throw "Не удалось создать g_ErrorLogMutex";
...
if(g_ErrorLogMutex)
 WaitForSingleObject(g_ErrorLogMutex,INFINITE);
...
if(g_ErrorLogMutex)
 ReleaseMutex(g_ErrorLogMutex);

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

Обнаружил, в чем было у меня дело
Я ставил сервис на сетевой диск. А надо на локальный
В итоге поведение такое:
1) на сетевом диске сервис работает только под пользователем, под Local System не работает
2) на локальном — работает и под конкретным пользователем и под Local System





Здравствуйте, Odi$$ey, Вы писали:

OE>Здравствуйте, Odi$$ey, Вы писали:

OE>>попробовал serv_tiny (ShutdownCounter) на win2003 sp2 — установился, под Local System запускается

OE>SERV ("My cool Service") — тоже все OK

Здравствуйте, potap, Вы писали:

P>Обнаружил, в чем было у меня дело
P>Я ставил сервис на сетевой диск. А надо на локальный
P>В итоге поведение такое:
P>1) на сетевом диске сервис работает только под пользователем, под Local System не работает
P>2) на локальном — работает и под конкретным пользователем и под Local System

Фух! Выдохнул
Это нормально. Имхо, это в любой NT-ОС так будет. У него нет прав видеть собственный исполняемый файл — конечно это не может закончиться хорошо.

Здравствуйте, potap, Вы писали:

P>Я это починил вот так:

Так в чём причина? В SECURITY_ATTRIBUTES ? Или в префиксе Global\\ ?

Здравствуйте, Аноним, Вы писали:

А>Так в чём причина? В SECURITY_ATTRIBUTES ? Или в префиксе Global\\ ?

В префиксе. Иначе они бы _видели_, даже если бы не имели доступа.

Здравствуйте, kero, Вы писали:

K>На XP (pro-sp2) такой MessageBox принадлежит своему приложению, а не CSRSS.

K>Чтобы принадлежал CSRSS (с сопутствуюшими эффектами):
K>

K>.code

K>ThreadProc proc lparam:LPARAM
K>  invoke MessageBox,0,"message","caption",MB_SERVICE_NOTIFICATION
K>  ret
K>ThreadProc endp

K>start:
K>  invoke CreateThread,0,0,offset ThreadProc,0,0,0
K>  invoke CloseHandle,eax
K>  invoke Sleep,10
K>  invoke ExitProcess,0
K>end start
K>

K>.

Т.е. главный поток чем-то сильно отличается? Итересно! Спасибо, посмотрю, разберусь.

Здравствуйте, SergH, Вы писали:

>Т.е. главный поток чем-то сильно отличается? Итересно! Спасибо, посмотрю, разберусь.

Ай, виноват, померещилось!

Заигрался подстановками MB_SERVICE_NOTIFICATION, MB_DEFAULT_DESKTOP_ONLY и MB_TOPMOST (=MB_SERVICE_NOTIFICATION_NT3X)...

При запуске-то из потока — по любому принадлежит CSRSS,
но при "прямом" запуске —
при MB_TOPMOST (=MB_SERVICE_NOTIFICATION_NT3X) принадлежит приложению,
а при MB_SERVICE_NOTIFICATION или MB_DEFAULT_DESKTOP_ONLY — таки CSRSS.

(Из потока — чтоб приложение закрылось само, оставив после себя MB).

По всему, пашиным хозяевам позарез нужна война в Европе
(уверены — к ним не залетит, в предыдущих двух не залетало жеж)

Здравствуйте, kero, Вы писали:

K>Ай, виноват, померещилось!

Только я решил, что неприлично торможу, и пора уже посмотреть самому

K>Заигрался подстановками MB_SERVICE_NOTIFICATION, MB_DEFAULT_DESKTOP_ONLY и MB_TOPMOST (=MB_SERVICE_NOTIFICATION_NT3X)...

K>При запуске-то из потока — по любому принадлежит CSRSS,
K>но при "прямом" запуске -
K>при MB_TOPMOST (=MB_SERVICE_NOTIFICATION_NT3X) принадлежит приложению,
K>а при MB_SERVICE_NOTIFICATION или MB_DEFAULT_DESKTOP_ONLY — таки CSRSS.

K>(Из потока — чтоб приложение закрылось само, оставив после себя MB).

Это по крайней мере объяснимо, хотя и противоречит тому, что написано в документации о MB_TOPMOST.

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

В данном же случае получается что для реализации MB_TOPMOST использованы более сильные средства, чем необходимо. Это вполне нормально для Microsoft