Запуск от имени другого пользователя (программное отключение защиты)

[Mentor]

Добрый день.

На работе столкнулись с проблемой, что программа не может получить пакеты данных с командами по COM соединению в случае, если запущена как от другого пользователя с выставленным параметром "Защитить компьютер от несанкционированных действий этой программы". При этом сама программа вызывается из другого приложения. В XP всё нормально работает, если утилиту обмена данными по COM запустить отдельно (без приложения, которое её должно открыть). Вопрос, можно ли как-то из программы через WinApi функции снять этот флаг защиты? По идее за него отвечает какая-то запись в реестре,но какая?

[Stilet]

Неа. Не в реестре. Достигается это запуском с правами админа. Можешь создать ярлык на программу, в ней выставить галочку запуска с правами админа для всех и будет работать.

[Mentor]

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

[Stilet]

А-а-а, так ты всетки не под семеркой работаешь?
Антивирус стоит?

[Mentor]

Изначально утилита компилируется в XP, там же тестится. Потом проверяем на работоспособность в семёрке.
Выяснилось, что передача прекращается из-за обращения утилиты к файлу на диске. В этот самый момент Windows видимо блочит команду открытия файла.
Удивительно, что другие приложения так себя не ведут.
Антивирус не активен.

[waleri]

А файл, часом, не лежит в Program Files или в какой другой системной папке?

Начните с того, что отключите UAC

[Mentor]

Нет, файл не лежит в системной папке ОС. UAC отключен.

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

Вот что приводит к исключению.

FS := TFileStream.Create(FileName, fmOpenReadWrite); /// FS у нас типа TFileStream.

Почему именно данная утилита попала в немилость, да ещё и на разных системах не ясно.

Что ещё может блокировать эта "защита компьютера от несанкционированных действий этой программы"?

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

private
 shelinfo:TShellExecuteInfoA;
....
....

var
stinf:StartupInfo;
  lpcreationtime,lpKernelTime,lpExitTime,lpUsertime:_filetime;
  hhiinst:HINST;
  hendEx:THandle;

  SI: TStartupInfo;   PI: TProcessInformation;   Exe: String;
  OSver: string;
  ProcID: Cardinal;
begin
  result := -1;
  resultString := '';
  ServerSocket.Active := true;
  GetStartupInfo(stinf);
  try
    with stinf do begin
      wShowWindow := SW_SHOWNORMAL;
      dwFlags := STARTF_USESHOWWINDOW;
    end;
    shelinfo.fMask:=SEE_MASK_NOCLOSEPROCESS;// or SEE_MASK_FLAG_DDEWAIT or SEE_MASK_WAITFORINPUTIDLE;
    shelinfo.Wnd:=0;
    shelinfo.lpVerb:=nil;
    shelinfo.lpFile:=PAnsiChar(execFilepath) ;
    shelinfo.lpParameters:=PAnsiChar(parameters) ;
    shelinfo.lpDirectory:=nil ;
    shelinfo.nShow:=SW_SHOWNORMAL ;
    shelinfo.hInstApp:=hhiinst ;
    shelinfo.hProcess:=hendEx ;
    shelinfo.cbSize:=sizeof(shelinfo);
    ShellExecuteEx(@shelinfo);

В общем обошли проблему. Перед открытием файла сделали приравнивание пути к свойству OpenDialog.FileName:=FileName (на этом использование диалога началось и закончилось), а потом
FS := TFileStream.Create(FileName, fmOpenReadWrite);
Бред полный, но так работает.

Спасибо всем, кто пытался помочь.

[Serge_Bliznykov]

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


скажите, у Вас имя файла FileName
в строке FS := TFileStream.Create(FileName, fmOpenReadWrite);
содержало ПОЛНЫЙ путь?
если нет - то, скорее всего, именно в этом и заключён корень проблемы!