✅ Use for these issues:
- Why? Issue is isolated to site-level configuration or bindings
- Why? SSL certificates and bindings are configured at the website level
- Why? Website restart reloads the web.config without affecting the worker process
- Why? Authentication settings are typically in web.config or site-specific IIS settings
- Why? URL rewrite rules are website-level configuration
- Why? Proves the worker process is healthy - problem is at the website level
⚠️ Impact: Minimal downtime (1-2 seconds), only affects the specific website
✅ Use for these issues:
- Why? The worker process is stuck/deadlocked - website restart won't unstick it
- Why? Memory is consumed at the worker process level - only killing the process frees it
- Why? If multiple sites are affected, the problem is at the worker process level
- Why? The worker process has exhausted its memory allocation - needs process restart to free memory
- Why? Process instability usually indicates worker process problems that website restart can't fix
- Why? New assemblies/DLLs need the worker process to restart to load them properly
- Why? Connection pooling happens at the worker process level
- Why? Usually indicates memory leaks, resource exhaustion, or thread pool issues in the worker process
⚠️ Impact: Brief downtime (5-10 seconds), affects ALL websites in that pool
Ask yourself:
In IIS Manager, look for:
Single website issue + Others working fine
→ Try WEBSITE RESTART first
Application hanging/crashing + Memory issues
→ Go straight to APP POOL RESTART
Configuration change just made
→ WEBSITE RESTART
Code deployment just happened
→ APP POOL RESTART
Don't automatically restart for 500 errors! First check:
- Why app pool restart? The worker process (w3wp.exe) has exhausted its memory allocation. A website restart doesn't kill the process, so the memory stays consumed. Only terminating the worker process frees up that memory.
- Note: This is a temporary fix - if there's a memory leak, it'll happen again
Rule: Fix the root cause, don't just restart and hope it goes away!
| Customer Report | Action | Why This Action |
|----------------|--------|-----------------|
| "Website won't load" | Website restart | Why website? Could be binding/config issue specific to that site. Why not app pool? Other sites might be working fine - don't disrupt them unnecessarily |
| "Getting 500 errors" | Check logs first - Don't restart automatically | Why check first? 500 errors are usually code/config problems that restarting won't fix. You need to know what's actually broken |
| "Application completely frozen/hanging" | App pool restart | Why app pool? The worker process is stuck/deadlocked. Why not website? Website restart won't unstick a frozen process - you need to kill and restart the process |
| "Very slow performance" | App pool restart | Why app pool? Usually caused by memory leaks, too many objects in memory, or resource exhaustion in the worker process. Why not website? Website restart doesn't free up process memory |
| "SSL certificate error" | Website restart | Why website? SSL bindings are website-level configuration. Why not app pool? The worker process isn't the problem - it's the site's certificate binding |
| "Login not working" | Website restart first, then app pool if needed | Why website first? Could be authentication config in web.config. Why escalate to app pool? If it's session state corruption or authentication module issues in memory |
| "Database connection error" | App pool restart | Why app pool? Connection pooling happens at the process level. Why not website? Database connections are managed by the worker process, not individual sites |
1. Open IIS Manager
2. Find the website in left panel
3. Right-click → Stop
4. Wait 2 seconds
5. Right-click → Start
1. Open IIS Manager
2. Click Application Pools in left panel
3. Find the correct app pool
4. Right-click → Recycle
5. Wait for confirmation
- Why? If only one site is affected, the issue is likely at the site configuration level, not the worker process
- Why? Website restart affects only that site (1-2 seconds), app pool restart affects all sites in the pool (5-10 seconds)
- Why? Proves the worker process is healthy - problem is isolated to one site's configuration
- Why? Memory problems exist at the worker process level - website restart won't free memory
- Why? The worker process is deadlocked/frozen - need to kill the process entirely
- Why? Indicates worker process instability - multiple symptoms point to process-level problems
- Why? New code assemblies need the process to restart to load properly - website restart won't reload assemblies
Always document:
Example:
2025-08-04 14:30 - Restarted "CustomerPortal" app pool due to high memory usage (2.1GB). Issue resolved, site responding normally.