你在另一篇文章中喜欢的文章实际上做得很好。
立即回收

• Web.config更改
• 计算机配置更改
• 全局.asax更改
• Bin目录更改
• 应用程序代码更改（_C）

延迟回收
在其他位置进行多次更改时可能会出现这种情况，通常，我只在更改.aspx或.cs/.vb文件时注意到这种情况。添加临时文本、csv或其他文件对我来说没有问题。
注意：这些都是应用程序网域回收，而不是集区的实际回收。通常，应用程序POOL只会根据IIS中的设定（要求数目、内存限制、闲置时间或排程重新启动）进行回收。

两种不同的效果：

• AppPool进程是潜在多个AppDomain的宿主。通常，这可以通过一些影响来回收。这些影响可能是时间（每 n 小时）、缺少请求、内存使用等;所有配置都在IIS配置管理器中进行。
• AppDomain是应用程序根的托管示例，可以更频繁地循环，而不会影响AppPool中的其他AppDomain。Tess's post on AppDomain recycling非常有洞察力。

您正在写入受监视以进行重新编译的文件夹。这将在某个时候触发AppDomain重新创建。
事件日志将帮助您确定启动回收的原因。

您可能希望打开完整的AppPool回收事件日志：

cscript adsutil.vbs Set w3svc/AppPools/DefaultAppPool/LogEventOnRecycle 255

您可能还想看看Scott古特里的博客文章：http://weblogs.asp.net/scottgu/archive/2005/12/14/433194.aspx，它显示了如何在Global.ASAX中编写代码来记录Application.End事件的实际原因。
这对我们诊断几个古怪的问题非常有用-其中一个特别是将日志文件写入wwwroot目录的应用程序-太多的文件更改导致回收...

这可以根据喜好每天发生，或者在超过进程的最大虚拟内存时发生。

您可以操作此设置，以根据应用程序池运行的分钟数或处理的请求数回收应用程序池。
它还将回收web.config的更改和其他已经发布在这里的内容。
IIS重置和停止/启动服务也可以达到此目的。

w3wp.exe发生错误。这会导致在Global.asax中呼叫Application_Start。
为了找出原因，我打开了事件查看器。
在Windows日志下，我转到了应用程序。
我看到一个应用程序错误：

Faulting application name: w3wp.exe, version: 10.0.16299.15, time stamp: 0x0aeb5595
Faulting module name: KERNELBASE.dll, version: 10.0.16299.334, time stamp: 0x6369e29f
Exception code: 0xe0434352
Fault offset: 0x0000000000014008
Faulting process id: 0x2900
Faulting application start time: 0x01d43b16f726cbb9
Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll
Report Id: 998cf55d-2cd9-4b8d-9884-2110e3fd1411
Faulting package full name: 
Faulting package-relative application ID: