注入splwow64时GdiplusStartup返回GenericError，其他进程正常

1. 检查GDI+初始化参数的正确性 #

• 确认GdiplusStartupInput结构体的GdiplusVersion必须设为1（GDI+ 1.0是系统默认版本，splwow64环境大概率不支持更高版本）。
• 检查GdiplusStartupOutput指针的传递逻辑：若不需要钩子函数可传入NULL，但要确保结构体内存分配符合32位环境的对齐要求。

2. 验证splwow64.exe的运行权限与上下文 #

• splwow64以LocalSystem权限运行在服务上下文，注入的DLL可能没有足够权限访问GDI+依赖的系统资源（如字体缓存、图形设备接口）。可在初始化前调用OpenProcessToken检查当前令牌的核心权限，比如SE_INCREASE_QUOTA_NAME。
• splwow64没有交互式桌面，尝试在初始化GDI+前调用SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_UNAWARE)，规避DPI感知相关的初始化冲突。

3. 排查DLL依赖与加载问题 #

• 确认splwow64中加载的是32位版本的gdiplus.dll，而非错误加载64位模块。用Process Explorer查看splwow64的模块列表，核对gdiplus.dll的路径和位数。
• 检查DLL加载顺序：确保GDI+初始化前，所有依赖模块已加载完成。splwow64的沙箱环境可能导致第三方依赖延迟加载，进而干扰GDI+初始化。

4. 捕获更底层的错误信息 #

• 不要只依赖GdiplusStartup的返回值，调用前设置SetErrorMode(SEM_FAILCRITICALERRORS)，再用GetLastError()获取Win32错误码——GenericError背后往往是具体的系统错误（如文件缺失、内存不足）。
• 启用GDI+调试日志：在GdiplusStartupInput中设置DebugEventCallback，通过自定义回调捕获内部错误细节，定位初始化失败的具体环节。

5. 排查环境干扰与线程状态 #

• 临时禁用杀毒软件、第三方打印监控工具等可能注入splwow64的DLL，排除外部模块的干扰。
• 用x86版WinDbg附加到splwow64.exe，在GdiplusStartup函数上下断点，单步跟踪初始化流程，检查线程是否处于异常状态（如挂起、同步冲突）。

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