TMemIniFile.Create зависает при вызове в ServiceStart

В службе, запущенной под системной учетной записью, приведенный ниже код зависает в TMemIniFile.Create без ошибок. Если мы заменим его на TIniFile, все будет работать нормально.
Это Win32-приложение Delphi Tokyo 10.2.3, работающее под управлением Windows Server 2012R2. Нет одновременного доступа к файлу INI.
Это первый раз (первый client) мы это видим, на многих машинах он работает нормально.

Я понятия не имею, что искать дальше. Есть идеи?
Теперь это "работает", потому что мы перешли на TIniFile, но я хотел бы найти причину. Из других сообщений я прочитал здесь, TINIfile кажется более привередливым, чем TMemINIfile, моя ситуация наоборот.
Нет специальных символов в файле INI и создается с помощью редактора ASCII.

// This is set in the ServiceCreate:
FIniFileNaam := ChangeFileExt(ParamStr(0),'.INI'); 

// This is called from the ServiceStart:

procedure TTimetellServiceBase.LeesINI;
var lIniFile : TMemIniFile;
begin
   LogMessage(FIniFileNaam, EVENTLOG_INFORMATION_TYPE, cCatInfo, cReadINI);  // Logs to event log, we see this
   FStartDir := ExtractFilePath(ParamStr(0));

   if assigned(FLaunchThreadLijst) then FreeAndNil(FLaunchThreadLijst);
   FLaunchThreadLijst := TStringList.Create;
   try
      if FileExists(FIniFileNaam) then
      begin
         // Lees waarden uit INI file
         lIniFile := TMemIniFile.Create(FIniFileNaam);  // This is the call that hangs. The service is unresponsive now.
         try
            FLaunchThreadLijst.CommaText := lIniFile.ReadString(INISECTIE_SERVICETASKS,'RunIniFiles','');
            FMaxTaskDuration := lIniFile.ReadInteger(INISECTIE_SERVICETASKS,'MaxTaskDuration',FMaxTaskDuration);
         finally
            FreeAndNil(lIniFile);
         end;
      end;

   finally
      if (FLaunchThreadLijst.Count = 0) and FileExists(FStartDir + FExeName) then
         FLaunchThreadLijst.Add(SDEFAULTTHREADNAME);
      LogMessage(Format('FLaunchThreadLijst.CommaText: %s (%d items)',[FLaunchThreadLijst.CommaText,FLaunchThreadLijst.Count]), EVENTLOG_INFORMATION_TYPE, cCatInfo, cLaunchList);
   end;
end;

FWIW, содержимое файла INI:

[TASKMANAGER]
RunIniFiles=TTTasks.ini
MaxTaskDuration=2
RestartIniFiles=
KillIniFiles=

person Jan Doggen    schedule 17.04.2018    source источник
comment
Какой у Вас вопрос? Похоже, вы хотите использовать здесь кодировку UTF8.   -  person Ilyes    schedule 17.04.2018
comment
@ Сами Нет, я не использую кодировку. И мне было интересно, звучит ли это знакомо или в моем коде есть подозрительные части.   -  person Jan Doggen    schedule 17.04.2018
comment
Ааа, вам лучше опубликовать этот вопрос на CodeReview   -  person Ilyes    schedule 17.04.2018
comment
@ Ян, что произойдет, если вы создадите MVCE с неверным кодом?   -  person whosrdaddy    schedule 17.04.2018
comment
@Sami: Code Review — это проверка кода, который работает должным образом. Вопрос, содержащий фразу код ниже зависает, скорее всего, будет закрыт как не по теме.   -  person Martin R    schedule 17.04.2018
comment
@MartinR Вот что я вижу здесь, если я не ошибаюсь.   -  person Ilyes    schedule 17.04.2018
comment
@whosrdaddy Я бы сделал, если бы это случалось чаще, но это на сервере клиентов, где один из наших консультантов удаленно устанавливает программное обеспечение, поэтому мы не можем слишком много экспериментировать с ним. Мы смешали приведенный выше код с дополнительными вызовами LogMessage(), чтобы увидеть в журнале событий, где что-то пошло не так. Но мне неудобно делать больше на этом рабочем сервере. Я бы хотел, чтобы это было на одной из наших машин, и я понимаю, почему этот очень открытый вопрос получает отрицательные голоса. И все же я боюсь основной проблемы, которую мы, возможно, упустили из виду.   -  person Jan Doggen    schedule 17.04.2018
comment
Если бы у вас был madExcept в процессе, вы могли бы использовать madTraceProcess для получения всех стеков вызовов потоков, когда процесс завис. Да, вы можете решить это, угадывая, но, безусловно, лучший подход — отладка с использованием доказательств.   -  person David Heffernan    schedule 17.04.2018
comment
Ян, видя, что у вас есть обходной путь, и вы хотите выяснить, в чем проблема, одним из возможных шагов является воссоздание среды клиента на локальной виртуальной машине, попытка воспроизвести проблему, а затем (удаленная) отладка вашего приложения.   -  person whosrdaddy    schedule 17.04.2018