先看你提供的IIS日志，里面的sc-status 500、sc-substatus 21、sc-win32-status 13是关键线索——这个错误组合通常意味着IIS无法正确启动ASP.NET Core的托管进程，下面是一步步的排查和解决方法：

1. 确认ASP.NET Core V2模块的注册状态 #

ASP.NET Core 3.0默认使用AspNetCoreModuleV2，而2.2版本用的是旧版模块，哪怕你装了3.0.1托管包，也可能存在模块未正确注册的情况，尤其是在IIS 7.5这类旧版本上：

• 打开管理员权限的命令提示符，运行以下命令手动注册模块：

  "%ProgramFiles%\dotnet\dotnet.exe" aspnetcore-module-v2 register
  

• 执行完后重启IIS，再尝试访问网站。

2. 检查Web.config的Handler配置 #

升级后如果Web.config是从2.2版本直接沿用的，很可能存在模块配置不兼容的问题：

• 打开项目的Web.config，找到<handlers>节点，确保配置是针对V2模块的：

  <handlers>
    <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
  </handlers>
  

• 同时建议开启应用日志排查细节，修改<aspNetCore>节点：

  <aspNetCore processPath="dotnet" arguments=".\YourApp.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" hostingModel="InProcess" />
  

  把stdoutLogEnabled设为true，记得提前在服务器上创建logs目录（要给应用池身份写入权限），之后访问网站就能在这个目录里看到应用启动失败的具体原因。

3. 调整应用池的.NET CLR版本 #

ASP.NET Core是自托管框架，不需要依赖IIS的.NET CLR，所以必须修改应用池设置：

• 打开IIS管理器，找到你的应用池，右键选择「高级设置」
• 在「.NET CLR版本」下拉框中选择无托管代码
• 保存设置后重启应用池和网站

4. 检查应用目录的权限 #

IIS应用池的身份（默认是IIS AppPool\你的应用池名称）需要对应用目录有足够权限：

• 右键应用程序所在文件夹，选择「属性」→「安全」选项卡
• 添加IIS AppPool\你的应用池名称用户，赋予「读取&执行」「列出文件夹内容」「读取」权限，如果需要写入日志，还要加上「写入」权限
• 应用权限后重启网站

5. 切换托管模式兼容旧IIS #

ASP.NET Core 3.0默认的InProcess托管模式在IIS 7.5/8.5上可能存在兼容性问题，可以尝试切换到OutOfProcess模式：

• 修改Web.config的<aspNetCore>节点：

  <aspNetCore processPath="dotnet" arguments=".\YourApp.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" hostingModel="OutOfProcess" />
  

• 把hostingModel改为OutOfProcess，重启网站后测试

我之前处理过不少类似的升级问题，大多是V2模块未注册、Web.config配置残留旧版设置，或者旧IIS对InProcess模式不兼容导致的。开启stdout日志是排查这类问题最有效的方式，能直接看到应用启动失败的具体报错（比如缺少依赖、配置文件错误等）。

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