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

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

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

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

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

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

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

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

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\\ ?

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

Здравствуйте, 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

.

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

Здравствуйте, 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