记一次IIS站点出错的解决过程

记一次IIS站点出错的解决过程

• 以前一直都是人家用着系统出问题了反馈过来这边改，没想到这回就发生在自己使用的过程中

问题经过

• 我正在执行一个操作，保存了没有返回提示，打开浏览器控制台查看网络，请求返回状态码是503，刷新整个页面，屏幕大大的Service Unavailable HTTP Error 503. The service is unavailable.。
• 由于没有经验，我瞬间懵逼，不知道怎么恢复正常，日志只有一个错误
  

处理

• 由于客户那边正在使用，得赶紧恢复使用才行。系统也跑了一段时间，最近使用的人多了才出现这个问题，所以系统本身的问题应该不大，恢复之后再看看什么问题吧，于是复制了一份部署文件新建了站点
• 可是好景不长啊，一个小时左右又崩了。根据日志来看，访问文件被拒绝应该是访问权限不够，于是给了读写权限。搜索一下IIS 503常见原因，多是因为应用池为了短暂保护站点而关闭了。于是乎看了下应用程序池，果然是关闭状态。恢复站点只需要重启应用程序池。
• 于是继续查找出问题的原因，日志看不出来什么问题，那么看看系统日志。
  
• 错误那个事件就提示即将关闭应用程序池了，在它之前记录的事件应该就是原因了。

应用程序池“XXXXXX”提供服务的进程在与“Windows Process Activation Service”通信时出现严重错误。该进程 ID 为"XXX"。数据字段包含错误号。

解决

• 简单粗暴的直接给这个配置文件所有人均可访问权限即可
• 另外附上两篇相关博文，提供解决思路第一篇（包含调试方法方法，推荐），第二篇

总结

• 有时候没有经验限制了思路，大部分情况下在没有任何经验的情况下出现问题，通常都会一脸懵逼不知所措。可能对大佬们来说很简单，轻车熟路。最快的解决办法是请教身边的大佬，他们稍微指点我们就能有解决思路。
• 另一种是看到什么错误信息就搜索什么，因为我们做的不是最前沿的技术开发，肯定不是第一个遇到这种问题，只要搜索能力好都能找到解决办法的
• 最后一种就是调试啦，无风不起浪，任何事情总有起因、经过，让我们站在设计者的角度来看，如果出问题了，要怎么设计处理，在哪里记录日志，保存内存快照以便调试。如果凭经验不能解决，那么调试就是最好的解决方法，任何问题都能被发现并解决，我们只需掌握强大的调试技巧。