IIS访问站点时ApplicationPool停止故障排查求助

我之前也碰到过一模一样的IIS应用池崩溃问题，结合你提供的信息，核心问题应该是ApplicationPoolIdentity对应的虚拟用户配置文件创建失败，导致应用池启动后直接触发崩溃，进而被WAS服务自动禁用（就是你看到的事件ID 5002）。下面是我亲测有效的排查和解决步骤：

先明确问题根源 #

DefaultAppPool能用是因为它用的NetworkService是系统内置账户，自带现成的用户配置文件；而每个应用池独立的ApplicationPoolIdentity是虚拟账户，当Load User Profile设为true时，IIS会自动在C:\Users下创建同名目录作为它的配置文件目录。但你之前手动删除过这类目录，导致注册表残留了无效的配置项，或者权限出现紊乱，使得IIS创建/访问这个目录时失败，直接搞崩了应用池进程。

具体解决步骤 #

1. 彻底清理残留的虚拟账户配置 #

• 打开注册表编辑器（按下Win+R，输入regedit回车），定位到：

  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
  

• 查找所有以S-1-5-82-开头的项（这是IIS应用池虚拟账户的SID前缀），找到对应MyNewSite应用池的项：查看该项的ProfileImagePath值，路径应该是C:\Users\MyNewSite，右键删除这个注册表项。
• 回到C:\Users目录，检查是否还有残留的MyNewSite文件夹（哪怕是空的），如果有，右键→属性→安全→高级→更改所有者，把所有者改成你的管理员账户，然后彻底删除这个文件夹。

2. 验证并重置应用池的Load User Profile配置 #

• 打开IIS管理器，找到MyNewSite应用池，右键→高级设置。
• 先把Load User Profile改成False，点击确定后启动应用池，如果能正常运行，就坐实了问题出在配置文件创建环节。
• 如果你需要开启Load User Profile（比如应用依赖用户配置环境），再改回True，但先完成下面的权限配置。

3. 给虚拟账户授予必要的系统权限 #

• 打开本地组策略编辑器（Win+R输入gpedit.msc回车），定位到：
  计算机配置→Windows设置→安全设置→本地策略→用户权限分配
• 找到创建全局对象权限，双击打开，点击添加用户或组，输入IIS AppPool\MyNewSite，点击检查名称确认后添加。
• 找到替换进程级令牌权限，同样添加IIS AppPool\MyNewSite账户。
• 打开服务管理器（Win+R输入services.msc回车），找到Windows Process Activation Service，右键重启（注意这会暂时中断所有IIS站点的服务）。

4. 手动预创建配置文件目录（可选，用于极端情况） #

如果上面的步骤还是不行，可以手动干预：

• 在C:\Users下创建MyNewSite文件夹。
• 右键该文件夹→属性→安全→编辑→添加，输入IIS AppPool\MyNewSite，授予它完全控制权限，点击确定。
• 回到IIS管理器，启动MyNewSite应用池，IIS会自动填充配置文件的必要内容。

5. 查看更详细的崩溃日志 #

除了WAS的5002事件，一定要去事件查看器→Windows日志→应用程序里找来源为Application Error的事件，里面会记录w3wp.exe（应用池进程）的崩溃详情，比如具体是哪个文件访问失败、权限不足的具体原因，这能帮你精准定位剩余问题。

临时方案的替代说明 #

你用NetworkService作为临时方案是可行的，但长期来看，用独立的ApplicationPoolIdentity安全性更高，所以建议按照上面的步骤彻底解决问题。

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