Windows Administration Tools

Task Manager provides a high-level, real-time overview of system resource utilisation — processes, CPU, memory, disk, network, and GPU. Resource Monitor (resmon.exe) goes deeper: it shows per-process CPU usage with individual thread details, per-process disk I/O with file paths being read/written, per-process network activity with endpoint addresses, and per-process memory with Working Set breakdown. For IIS troubleshooting: Task Manager identifies which w3wp.exe is the problem; Resource Monitor tells you exactly which files it is reading/writing and which network connections it has open.

The five Windows Logs are: Application — events logged by applications and services (IIS, SQL, custom apps). Security — audit events including logon/logout, object access, privilege use, and account management. Setup — events related to OS and component installation. System — events from Windows OS components — kernel, drivers, services start/stop. Forwarded Events — events collected from remote machines using Windows Event Forwarding (WEF). Applications and Services Logs (under the root) are application-specific channel logs — for example Microsoft/Windows/Security-SPP or Microsoft-Windows-IIS-W3SVC.

Multiple options: dir C:\ shows free space at the bottom for the C drive. fsutil volume diskfree C: shows bytes available, bytes free, and total bytes. PowerShell: Get-PSDrive C | Select-Object Used, Free. WMIC: wmic logicaldisk get name,freespace,size lists all drives with sizes in bytes. For a more readable report: Get-PSDrive -PSProvider FileSystem | Select-Object Name, @{N='Free(GB)';E={[math]::Round($_.Free/1GB,2)}}. Disk space checks should be part of every IIS incident investigation because full disks silently break logging and cause obscure 500 errors.

Performance counters are named metrics exposed by the Windows operating system and applications that measure specific aspects of system or application behaviour over time. They are organised into: Object (the component, e.g., Processor, Memory, Web Service), Counter (the specific metric, e.g., % Processor Time), and Instance (the specific item, e.g., core 0, a specific website). Applications register custom counter sets in the registry. IIS registers the "Web Service" object with counters for requests, bytes, errors, etc. Performance Monitor, PowerShell Get-Counter, and monitoring tools like SCOM, Datadog, and Prometheus Windows Exporter all use these counters.

Disk Management (diskmgmt.msc) is the GUI tool for managing disk partitions and volumes. With it you can: initialise new disks (MBR or GPT partition table), create, delete, extend, and shrink partitions and volumes, change drive letters and volume labels, convert basic disks to dynamic disks, bring disks online or offline, and view disk status (online/offline/missing). For IIS environments, Disk Management is used when adding storage for log volumes, extending the C drive after a VM disk expansion, or verifying that a new SAN LUN has been correctly assigned a drive letter before configuring IIS log paths.

Open perfmon → Data Collector Sets → User Defined → right-click → New → Data Collector Set. Name it (e.g., "IIS Baseline"), choose "Create manually". Add performance counters (Counter data): Processor\% Processor Time, Memory\Available MBytes, PhysicalDisk\Disk Bytes/sec, Web Service(_Total)\Requests/sec, Process(w3wp)\Private Bytes, ASP.NET\Request Execution Time. Set sample interval (e.g., 15 seconds). Configure the output directory (e.g., D:\PerfLogs\IIS). Set a schedule (e.g., run during business hours). Start the DCS before a peak load period, stop it after, and view the report in Performance Monitor's Report section. This baseline establishes normal ranges for future anomaly detection.

Windows Event Forwarding (WEF) allows events from multiple source computers to be collected centrally on a collector computer. Source computers push events using the WinRM protocol (or use subscription pull). For IIS: in a farm of 10 web servers, you'd configure all servers to forward IIS-W3SVC, WAS, and Application Error events to a central log collector. This means you can search all server event logs from one console, detect patterns across the farm (e.g., the same crash happening on all nodes after a bad deployment), and raise alerts in SIEM tools like Microsoft Sentinel or Splunk. Configure with GPO Computer Configuration → Windows Settings → Security Settings → Windows Remote Management.

Reliability Monitor (MoRa — Maintenance Reliability History) computes a stability index (1-10) based on hardware failures, OS failures, application crashes, and software installs over the past 30 days. It displays these as a timeline chart. For IIS incidents, it is invaluable for: correlating a patch install on Tuesday with IIS crashes starting Tuesday night (Windows Update often restarts IIS-dependent services), identifying if a .NET framework upgrade preceded 500 errors, and quickly showing management a visual timeline that proves the incident started after a change. Access via: Control Panel → Security and Maintenance → View reliability history, or directly via perfmon /rel.

Run netstat -ano | findstr :80 to list all connections/listeners with process IDs. The PID in the last column corresponds to Task Manager's Details view. But for IIS: port 80 is bound by HTTP.sys in kernel mode, not directly by w3wp.exe. The PID shown will be "4" (System process) because HTTP.sys is part of the system process in kernel space. To identify which IIS sites/bindings are using port 80, run netsh http show urlacl and netsh http show servicestate. IIS Manager → Sites → right pane Bindings column also shows this. Resource Monitor → Network → Listening Ports tab provides a combined view.

Each event log has a configured maximum size and an overwrite policy. Default sizes are often too small for production (Application log defaults to 20 MB). Policies: Overwrite events as needed (circular buffer — oldest deleted first when full), Archive log when full, do not overwrite events (new events discarded when full). For IIS post-incident forensics, if the logs rolled over and purged the evidence, you cannot reconstruct the timeline. Best practice: increase Application and System logs to at least 512 MB on IIS servers. Enable Log Archive (Save and Archive) so old full logs are preserved as .evtx files. Configure via Event Viewer → right-click log → Properties, or via GPO Computer Configuration → Administrative Templates → Windows Components → Event Log Service.

1. Open Task Manager → Performance: note CPU %, available RAM, disk I/O. 2. Switch to Details, sort by CPU: identify which w3wp.exe PIDs are high. 3. Run appcmd list wp to map PIDs to app pools → identify which site. 4. Open Event Viewer → Application log, filter for errors in the last 30 minutes: look for IIS-W3SVC, WAS, and Application Error sources. 5. Check IIS logs: dir /od C:\inetpub\logs\LogFiles\W3SVC1\ — note the latest log file timestamp and tail it: type u_ex230915.log | findstr " 500 " to check for 500 errors. Total time: 5 minutes. You now know: which pool, which type of error, and whether it is resource-driven or application-driven.

Open Event Viewer → Windows Logs → Security. Filter for Event ID 4624 (Successful Logon) with Logon Type 10 (RemoteInteractive = RDP) between the time window in question. Each 4624 entry shows the account name, domain, logon type, source network address (client IP), and timestamp. If the Security log has rolled over, check if log archiving was enabled (archived .evtx files in the configured archive path, typically C:\Windows\System32\winevt\Logs). If log monitoring is centralised (SIEM), check there. If IPSec or firewall logs are available, the source IP of the RDP session gives additional corroboration. Document Event ID, timestamp, account name, source IP, and session ID for the security report.

IIS performance counters are registered when IIS is installed but can become corrupt or missing after failed updates, IIS repair, or .NET reinstallation. Two causes: (1) IIS Web Service counter provider not registered. Fix: from an elevated command prompt run lodctr /R to reset all counters to base state, then re-register IIS: %windir%\system32\inetsrv\setupconsole.exe or repair IIS via Server Manager. (2) .NET performance counter DLL corrupt. Fix: aspnet_regiis -r or lodctr /R followed by lodctr aspnet_perf.ini. After fixing, run winmgmt /resyncperf to synchronise WMI with the counter store. Restart Server Manager to refresh available counters.

Faulting module clr.dll indicates a crash inside the .NET Common Language Runtime inside the IIS worker process. This is a managed/unmanaged boundary issue — typically a corrupted .NET write, a stack overflow, or an access violation in .NET code. Next steps: (1) Check the mini dump if one was created in %LOCALAPPDATA%\CrashDumps or the path configured in the Registry under WER (Windows Error Reporting). (2) Enable ADPlus crash dumping or configure WER to create full user dumps: create a registry key HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\w3wp.exe with DumpType=2 (full dump). (3) Reproduce the crash and collect the dump. (4) Analyse with WinDbg + SOS: .loadby sos clr, then !analyze -v and !clrstack to get the managed call stack at crash time. Escalate to development team with the managed call stack.

Prioritised cleanup in order: 1. IIS logs: C:\inetpub\logs\LogFiles\ — often 10s of GB of W3C log files. Archive logs older than 30 days to another volume first, then delete. 2. Windows temp files: C:\Windows\Temp — can accumulate large temporary installer files. 3. Windows CBS (Component-Based Servicing) store cleanup: Dism /Online /Cleanup-Image /StartComponentCleanup — reclaims GB from superseded Windows Update components. 4. Windows Update download cache: C:\Windows\SoftwareDistribution\Download — safe to clear when no update is in progress. 5. IIS Failed Request Trace logs: C:\inetpub\logs\FailedReqLogFiles\ — if FREB logging was left on by accident. 6. Application temp/log directories under the site root. Set up disk free monitoring (alert at <15%) to prevent recurrence.