.NET开发Worker Service作为Windows服务启动报1067错误原因咨询

Error 1067的本质是服务进程启动后未在规定时间内向Windows服务控制管理器（SCM）完成状态注册、直接异常退出，针对开发机运行正常、目标机启动失败的场景，按排查优先级排序，常见诱因如下：

• 运行时依赖缺失或版本不匹配
  如果你采用框架依赖模式（FDD）发布程序，目标机器必须安装与编译时主版本完全一致的.NET运行时：比如编译用.NET 6，目标机装.NET 8无法兼容；如果发布的是x64版本程序，仅安装x86版本的运行时也会启动崩溃。
  快速验证方式：直接在目标机的命令行中进入服务exe所在目录，手动执行exe文件，如果是运行时缺失，命令行会直接抛出dotnet host或对应runtime找不到的明确报错，比服务管理器的通用错误提示更直接。
• 工作目录与权限配置错误
  Windows服务默认启动工作目录为C:\Windows\System32，并非服务exe所在的文件夹。如果你的代码中使用相对路径读取appsettings.json、加载本地依赖dll、写入日志文件，服务启动时会到System32路径下查找对应资源，找不到就会触发未处理异常直接退出。
  另外sc.exe创建服务时默认使用Local Service账户运行，该账户权限极低，如果没有给它开放程序安装目录的读权限、以及程序需要访问的磁盘/注册表/网络资源权限，启动时会因为权限不足触发崩溃。
• 发布配置错误
  一是代码层面未正确配置Windows服务支持：Program.cs中没有调用AddWindowsService()扩展方法，程序启动后按普通控制台逻辑执行完直接退出，没有向SCM注册服务状态，触发超时报错。
  二是发布时目标平台配置错误：比如开发机为x64架构，发布时误选ARM/ARM64平台，目标机x64系统无法运行对应exe。
  三是发布文件不全：独立部署时漏传依赖的原生dll、配置文件，导致程序启动加载依赖失败。
• 启动阶段的环境依赖不满足
  代码中如果在启动阶段就硬编码连接开发机独有的资源（比如本地Redis、SQL Server实例、特定路径的证书/文件），目标机不存在对应资源时，若没有做异常捕获，会直接抛出未处理异常导致进程退出。
  另外目标机上的appsettings.json如果存在JSON格式错误、必填配置项缺失，程序启动时配置绑定失败也会直接崩溃。

精准定位错误的最快方式是查看Windows事件查看器：依次打开「事件查看器-Windows日志-应用程序」，来源为.NET Runtime或你的服务名的日志会记录完整的异常堆栈、错误信息，可直接定位根因。如果配置了stdout日志，也可以直接查看服务启动阶段的控制台输出。

内容的提问来源于stack exchange，提问作者Karl Mõttus