系统账户下Delphi服务中TMemIniFile.Create挂起问题排查求助

安全阿岳

2026-5-25

排查TMemIniFile在Windows服务中挂起的思路

我来分享几个针对这个问题的排查方向，毕竟TMemIniFile和TIniFile的底层实现差异不小，尤其是在系统账户运行的服务这种受限环境下，很容易触发普通用户环境遇不到的问题：

先排查路径与权限问题
TMemIniFile.Create如果只传入文件名而不指定完整路径，默认会去当前工作目录找文件。但Windows服务以系统账户运行时，当前目录是C:\Windows\System32，而非你的程序安装目录。如果INI文件不在这个路径下，TMemIniFile在尝试读取文件时可能因为找不到文件或者权限问题陷入阻塞（比如系统账户对程序目录没有读权限）。建议先显式指定INI文件的完整路径测试，比如：
```
TMemIniFile.Create(ExtractFilePath(ParamStr(0)) + 'YourConfig.ini');
```
同时检查系统账户对程序安装目录的读写权限——哪怕TMemIniFile是内存操作，创建时也需要读取原始文件到内存中。
检查是否因UI交互导致挂起
Windows服务默认没有桌面交互权限，如果TMemIniFile在遇到错误（比如文件不存在、权限不足）时尝试弹出错误对话框（虽然你说没报错，但某些底层实现可能会静默触发），系统账户因为没有桌面会话，对话框会一直等待用户输入，导致服务挂起。而TIniFile的错误处理逻辑更直接，会返回错误而不弹UI。你可以临时给服务勾选“允许服务与桌面交互”（生产环境不推荐）来验证这个猜想，或者确保服务中所有代码都不涉及UI交互。
排查线程同步与Delphi版本bug
TMemIniFile内部用TCriticalSection来保护内存中的INI数据，虽然你说没有并发访问，但服务启动时的系统环境可能影响临界区的初始化。另外Delphi 10.2.3的TMemIniFile有没有已知的服务环境下的同步bug？可以查一下Embarcadero的知识库，或者尝试给Delphi安装最新的补丁包。也可以手动在创建TMemIniFile前初始化临界区相关逻辑，看是否能绕过问题。
处理文件系统重定向问题
你的程序是32位的，在Windows Server 2012R2中，32位程序访问C:\Windows\System32会被重定向到C:\Windows\SysWOW64。如果你的INI文件路径涉及到这个目录，TMemIniFile在处理路径时可能陷入无限等待。可以尝试用Wow64DisableWow64FsRedirection和Wow64RevertWow64FsRedirection包裹TMemIniFile的创建代码，关闭重定向后再操作：
```
var
  OldValue: PByte;
begin
  Wow64DisableWow64FsRedirection(OldValue);
  try
    FMemIni := TMemIniFile.Create('YourConfig.ini');
  finally
    Wow64RevertWow64FsRedirection(OldValue);
  end;
end;
```
用调试工具抓调用栈
既然服务挂起没有报错，最直接的方式就是用调试工具附加到服务进程，看挂起时的线程调用栈。比如用WinDbg或者Delphi自带的调试器（需要配置服务允许调试），当服务卡住时，查看线程停在TMemIniFile的哪个函数里——是读取文件的ReadFile调用？还是临界区的EnterCriticalSection？这能直接定位到问题根源。另外也可以用JclDebug这类组件开启异常日志，记录所有未捕获的异常和调用栈，哪怕没有弹出错误，也可能有隐藏的日志信息。
检查内存环境差异
系统账户的堆环境和普通用户不同，TMemIniFile需要把整个INI文件加载到内存中，如果内存分配出现异常（比如堆碎片化、权限限制），也可能导致内部挂起。可以在创建TMemIniFile前手动分配一块内存测试，看系统账户下内存分配是否正常，或者尝试切换到FastMM4等第三方内存管理器，替换Delphi默认的内存管理器来排查。

内容的提问来源于stack exchange，提问作者Jan Doggen