File System, Processes, and Services

NTFS (New Technology File System) is Windows' enterprise file system supporting file-level security (ACLs), file compression, encryption (EFS), disk quotas, symbolic links, sparse files, and volume sizes up to 16 exabytes. FAT32 is an older, simpler file system with no security (no per-file permissions), a maximum file size of 4 GB, and a maximum partition size of 32 GB when formatted from Windows. IIS must be hosted on NTFS volumes — FAT32 cannot enforce the access control required for secure web hosting.

A process is an instance of a running program. It holds: a virtual address space (private memory region isolated from other processes), a security token (determines what the process is allowed to do), open handles (references to kernel objects like files and registry keys), one or more threads (the actual units of CPU execution), and environment variables. The process is the unit of isolation — when a process crashes, only its resources are released; other processes continue unaffected.

A process is a container with its own memory space and security context. A thread is an execution path within a process that shares the process's memory. A process has at least one thread (the initial/main thread) and can have many more. Threads within the same process can communicate directly through shared memory, while communication between processes requires inter-process communication (IPC) mechanisms like pipes, sockets, or memory-mapped files. IIS worker processes (w3wp.exe) are multi-threaded — each incoming request is handled on a thread from the IIS thread pool.

A Windows Service is a long-running background process managed by the Service Control Manager. Unlike regular applications, services: run without a logged-in user (in Session 0); start automatically at boot; can be configured to restart themselves on failure; cannot display UI to users (Session 0 isolation); and are controlled via sc.exe, net.exe, services.msc, or PowerShell. W3SVC and WAS are both Windows Services — they start when the server boots and run until or unless stopped, regardless of who is or isn't logged in.

IIS_IUSRS is a built-in local Windows group that IIS uses to group all application pool identities. In older versions of IIS (before 7.5), you had to manually add the NETWORK SERVICE account to this group. In IIS 7.5 and later, all application pool virtual accounts are automatically added as members at runtime — meaning you can grant IIS_IUSRS permission on a folder and all app pools will have that permission without individually listing each pool identity.

NTFS permissions are inherited from parent folders by default. A child folder receives all Allow and Deny entries from its parent unless inheritance is explicitly broken. You break inheritance when: a subdirectory needs stricter permissions (e.g., an admin-only config folder within a publicly readable web root); or a folder needs broader permissions than its parent. To break inheritance, open Advanced Security Settings → Disable Inheritance → choose to Copy or Remove inherited entries. After breaking, the folder's ACL is explicit and changes to the parent ACL will no longer propagate to it. In IIS, the App_Data folder commonly has inheritance broken to restrict anonymous web access while the IIS identity retains write access for session storage.

A Job Object is a kernel container that groups processes and enforces shared resource limits. IIS's Windows Process Activation Service (WAS) creates a Job Object for each application pool and assigns the pool's worker process (w3wp.exe) to it. The Job Object enforces CPU rate limits, memory limits (configured on the app pool's "Maximum Private Memory" setting), and process lifetime. This is why IIS can automatically recycle a worker process when it exceeds a memory threshold — WAS monitors the Job Object's counters and triggers a recycle when a limit is hit.

LOCAL SYSTEM: highest privilege, can do almost anything on the local machine including accessing network resources as the computer account. Avoid for IIS pools — too much privilege. NETWORK SERVICE: lower privilege, can access network resources using computer account credentials. Used for older IIS worker processes. LOCAL SERVICE: lower privilege still, cannot use network with computer credentials. Only for services needing minimal local access. Virtual Accounts (IIS AppPool\Name): IIS-specific, no password management required, lowest privilege, cannot be used for domain resource access. gMSA (Group Managed Service Account): domain-integrated, automatic password rotation, can access network resources, best choice for production IIS pools needing database or file share access.

IUSR is the built-in anonymous authentication account for IIS. When a browser makes a request without sending credentials and the site uses Anonymous Authentication, IIS processes the file access request using the IUSR account token. IUSR replaced the old IUSR_MachineName account from IIS 6. It is a built-in low-privilege account — it should have Read & Execute on static web content but never Write on any path. If anonymous authentication is disabled (e.g., Windows Authentication only), IUSR is not used at all — requests are processed as the authenticated user's token via impersonation.

NTFS SACL (System ACL) enables auditing. Right-click the file → Properties → Security → Advanced → Auditing tab → Add an audit entry. Choose which accounts to audit and which operations (Success/Failure for Read, Write, Delete, etc.). Enable Object Access auditing in Local Security Policy (or Group Policy) under Security Settings → Advanced Audit Policy → Object Access. Once enabled, accesses to that file are logged to the Security event log as event ID 4663. For web.config or applicationHost.config, auditing Write and Delete attempts is a good security practice to detect unauthorised configuration changes.

Virtual accounts (IIS AppPool\Name) are distinct per pool. IIS AppPool\MyApp and IIS AppPool\NewSite are two separate security principals. Granting access to one does not grant it to the other. Three solutions: (1) Grant the IIS_IUSRS group Write access to C:\uploads — this automatically covers all virtual account pools. (2) Grant each pool identity explicitly: icacls C:\uploads /grant "IIS AppPool\NewSite:(OI)(CI)M". (3) Configure both pools to run as the same gMSA and grant the gMSA write access — the cleanest approach for shared-resource scenarios in production.

Take a memory dump first without killing the process: procdump -ma <PID> C:\dumps\dump.dmp. This captures the full memory snapshot. While doing this, check: Task Manager's "Working Set" vs "Private Bytes" — working set can be large due to file cache; private bytes is the real application memory. Review app pool recycling settings — does it have a Maximum Private Memory limit set? If not, configure one as an emergency guard. Analyse the dump file with WinDbg + SOS extension or send to the app team to identify which managed heap objects are accumulating (likely a memory leak in the application code). Plan a rolling recycle during low-traffic period to restore memory without session loss if ARR (Application Request Routing) or session state is configured for persistence.

Open services.msc → right-click the service → Properties → Recovery tab. Set: First failure = Restart the Service, Second failure = Restart the Service, Subsequent failures = Restart the Service. Set "Reset fail count after" to 1 day. Set "Restart service after" to 1 minute. Click Apply. Alternatively via command line: sc failure <ServiceName> reset= 86400 actions= restart/60000/restart/60000/restart/60000. Additionally, check the Event Viewer Application and System logs to find WHY the service is stopping — auto-restart is a mitigation, not a fix. Check for access denied errors, missing dependencies, or corrupt configuration as the root cause.

Apply least-privilege: Site root (e.g., C:\inetpub\wwwroot\MyApp): Read & Execute for AppPool identity — allows IIS to read HTML, JS, CSS, DLLs, and web.config. Bin folder (C:\inetpub\wwwroot\MyApp\bin): Read & Execute — DLLs must be readable but not modifiable by the web process. App_Data (session state, SQLite DBs): Read, Write, Modify — only if the application actually writes here. Log folder (if app writes its own logs): Write, Modify. Temp/upload folder: Modify (not FullControl). System paths (C:\Windows\Temp, C:\Windows\Microsoft.NET\Framework): typically requires no explicit grants in modern .NET — avoid adding unnecessary permissions here. Never grant FullControl to AppPool identities on web directories.

Check the service dependency chain first: WAS must be running before W3SVC can start. Run sc query was. If WAS is stopped, check why: sc query http — if HTTP.sys failed to load, WAS cannot start. Check Event Viewer System log for errors from: W3SVC, WAS, HttpEvent, or tcpip. Common causes: HTTP.sys failed because another process bound to port 80 (run netstat -ano | findstr :80 to find the conflicting process), or Windows Firewall base filtering engine stopped which blocks HTTP.sys initialisation. Fix the dependency, then start services in order: http driver → WAS → W3SVC, or simply run iisreset /start which handles the correct order.