Most unexplained ASP.NET blips on Windows shared hosting are not your code and not the network. They are app pool recycles firing at the wrong time, with the wrong thresholds, on the wrong bitness. A recycle is a clean process restart; if it lands during a deploy, a long request, or a SQL connection spike, users see 503s and you get a ticket at 3 AM.
IIS 10.0 on Windows Server 2025 still uses the same application pool model you have used for years. The defaults are safe for a demo site and harsh for a production ASP.NET Core or Framework app that holds in-memory cache, SignalR connections, or pooled SQL connections. The fix is boring configuration, not a rewrite.
#What a recycle actually does
When the worker process (w3wp.exe) recycles, IIS starts a new process, warms the new one, then drains the old one. In-flight requests can finish if you leave overlapped recycle enabled, but anything stored only in process memory is gone: static caches, singleton services that are not externalized, open WebSocket sessions, and the first-chance cost of JIT and assembly load hits again. On shared hosting you do not own the machine-level defaults, but you usually control the pool assigned to your site—or you can ask support to align settings with the values below.
#Recycling settings that reduce surprise
Prefer a predictable schedule over pure memory or request-count triggers. Fixed-interval or specific-time recycles let you pick a low-traffic window. Memory-based recycles are a backstop for leaks, not a daily schedule. Disable recycling on configuration change during a controlled Web Deploy window if you are batching transforms; otherwise every web.config touch restarts the pool.
# Example: set a nightly recycle at 03:15 and raise private memory cap
Import-Module WebAdministration
$pool = 'DefaultAppPool' # or your site pool name
Set-ItemProperty IIS:\AppPools\$pool -Name recycling.periodicRestart.schedule -Value @{value='03:15:00'}
Set-ItemProperty IIS:\AppPools\$pool -Name recycling.periodicRestart.privateMemory -Value 1048576 # KB ≈ 1 GB
Set-ItemProperty IIS:\AppPools\$pool -Name recycling.periodicRestart.time -Value '00:00:00' # disable interval
Set-ItemProperty IIS:\AppPools\$pool -Name processModel.idleTimeout -Value '00:00:00' # stay warmOn shared plans you may not run those cmdlets yourself. Translate the intent when you open a ticket: scheduled recycle once nightly off-peak, idle timeout disabled or extended so the pool does not cold-start after every quiet hour, and a private memory cap high enough for your working set plus headroom. Overlapped recycle should stay on unless you have a hard dependency on single-instance behavior.
#Quick checklist
- One scheduled recycle in a known low-traffic window beats random memory trips.
- Idle timeout of zero (or several hours) avoids cold starts on low-traffic APIs.
- Keep overlapped recycle enabled so requests drain instead of hard-failing.
- Treat memory limits as leak protection, not as your primary recycle clock.
#32-bit, 64-bit, and Full Trust
Enable 32-bit applications only when you still load a 32-bit native DLL. Otherwise run 64-bit: larger address space, fewer surprise OOMs under load, and better alignment with current .NET 10 and ASP.NET Core builds. Classic ASP.NET on .NET Framework often needs Full Trust on shared Windows hosts for reflection, temp file writes, or certain libraries; partial trust is effectively a legacy constraint. If a library fails only in production with SecurityException or FileIOPermission errors, confirm the pool is Full Trust before rewriting the library.
ASP.NET Core apps run as out-of-process or in-process under ANCM. In-process ties the app lifetime tightly to the pool—recycle settings matter even more. Out-of-process gives you a separate dotnet process; you still want the pool stable so the reverse proxy side does not flap. Either way, match the pool’s bitness to the published runtime (x64 unless you have a real x86 dependency).
#Web.config, connection strings, and transforms
Keep secrets out of the repo. Use Web.config transforms or environment-specific publish profiles so staging and production connection strings never ship in the same package. On Windows hosting, SQL Server connection strings should favor connection pooling defaults, set a sane Connect Timeout, and avoid holding transactions open across user think time. If you still use multiple Web.config transforms at deploy time, remember each successful transform that touches the live file can recycle the pool—batch changes.
<!-- Web.Release.config fragment -->
<connectionStrings>
<add name="AppDb"
connectionString="Server=tcp:sql.example.internal,1433;Database=AppProd;User ID=app_user;Password=***;Encrypt=True;TrustServerCertificate=False;Connection Timeout=15;Max Pool Size=100;"
xdt:Transform="SetAttributes" xdt:Locator="Match(name)" />
</connectionStrings>
<system.webServer>
<aspNetCore stdoutLogEnabled="false" hostingModel="inprocess" />
</system.webServer>#Logging without filling the volume
stdout logs for ASP.NET Core are useful for a failed cold start and dangerous if left enabled at Information level on a busy site. Turn them on to diagnose, then off. Prefer structured logging to a capped file sink or an external target, with retention measured in days, not forever. Failed request tracing in IIS is excellent for 500s and long requests—enable it for short windows, capture the status codes you care about, then disable so trace XML does not eat disk. On shared hosting, disk quotas are real; a runaway log is indistinguishable from a full site from the outside.
Practical takeaway: pick one nightly recycle window, run 64-bit unless you must not, keep Full Trust for Framework apps that need it, disable idle death for APIs that should stay warm, and treat every live web.config edit as a potential restart. Measure working set after a warm-up under real traffic, set memory caps above that line, and keep stdout and FREB off except when you are actively debugging. Those five habits eliminate most “the site just went down for a minute” reports on Windows shared and Windows Server IIS hosts.
Comments
No comments yet