When a Windows Server becomes slow, unreachable or unreliable, the fastest fix is rarely the first command you find online. A good investigation protects evidence, confirms the scope, changes one thing at a time and leaves a clear route back.
This practical runbook covers the Windows Server faults we see most often: poor performance, network and DNS failures, low disk space, Active Directory problems, Remote Desktop issues, failed updates and unstable applications. It applies broadly to supported Windows Server versions, but always check the documentation for your exact release and workload.
Before you change anything: capture the evidence
Start by recording what failed, when it began and who is affected. Ask whether the fault is constant or intermittent, whether anything changed beforehand, and whether the server is physical, virtual or cloud-hosted. Check monitoring alerts, recent deployments, backup status and the System and Application logs in Event Viewer.
- Record the server name, role, operating-system build and current time.
- Confirm the impact: one user, one application, one site or the entire organisation.
- Capture screenshots, event IDs, error text and relevant timestamps.
- Check for recent patches, configuration changes, expired certificates and storage changes.
- Confirm that a usable backup or snapshot exists before a risky repair.
Important: Do not reboot, clear logs or delete caches simply to “see if it helps”. Those actions can remove useful evidence, extend an outage or turn a recoverable fault into a larger one. Use a controlled maintenance window and a rollback plan.
1. Slow server performance
Typical signs: applications respond slowly, logons take longer, CPU remains high, memory is exhausted, disk latency rises or a virtual machine becomes unresponsive.
Diagnose the bottleneck
- Open Task Manager and Resource Monitor to identify which process is consuming CPU, memory, disk or network capacity.
- Use Performance Monitor to capture behaviour over time. A brief spike is different from sustained contention.
- Compare the fault period with scheduled backups, antivirus scans, updates, indexing, batch jobs and user demand.
- For virtual machines, check the host as well as the guest. CPU ready time, storage latency, memory pressure or an overcommitted host may be the real cause.
- Review Event Viewer for application crashes, disk warnings, driver faults and resource-exhaustion events.
Microsoft recommends collecting performance data while the fault occurs rather than relying only on a later snapshot. Its Performance Monitor troubleshooting guide explains how to use Data Collector Sets for this.
Useful PowerShell snapshot:
Get-Process |
Sort-Object CPU -Descending |
Select-Object -First 10 Name, Id, CPU, WorkingSet
Get-Counter '\Processor(_Total)\% Processor Time',
'\Memory\Available MBytes',
'\PhysicalDisk(_Total)\Avg. Disk sec/Transfer'
Fix the cause rather than merely stopping the busiest process. Capacity problems may need right-sizing, while leaks, faulty drivers or application defects need a different response.
2. Network and DNS failures
Typical signs: the server cannot reach a dependency, clients cannot connect, name resolution fails, connections drop or only some subnets are affected.
- Check the network adapter, IP address, subnet, default gateway and DNS servers with
Get-NetIPConfiguration. - Test by name and by IP. If an IP connection works but the hostname does not, investigate DNS rather than the application.
- Use
Resolve-DnsNameto inspect DNS answers andTest-NetConnectionto test a specific TCP port. - Check Windows Firewall, upstream firewalls, routing, VPNs, load balancers and network security groups.
- Look for duplicate IP addresses, stale DNS records, incorrect VLANs and expired certificates.
Get-NetIPConfiguration
Resolve-DnsName app.example.com
Test-NetConnection app.example.com -Port 443
Test-NetConnection 10.0.0.10 -TraceRoute
A successful ping does not prove that an application works, and a failed ping does not prove that the host is down. ICMP may be blocked, so test the actual service port.
3. Low disk space and storage faults
Typical signs: low-space alerts, failed updates, stopped services, database errors, very slow disk response or an unexpectedly expanding system drive.
- Identify the affected volume and confirm whether the problem is capacity, latency or an underlying storage fault.
- Find growth by folder and correlate it with logs, databases, backups, crash dumps and temporary files.
- Check Volume Shadow Copy storage, Windows component-store growth and application retention settings.
- Never delete database, update or application files unless the vendor’s procedure says it is safe.
- Extend the volume or move data only after checking backups, dependencies and the storage platform.
Get-Volume |
Select-Object DriveLetter, FileSystemLabel,
@{Name='FreeGB';Expression={[math]::Round($_.SizeRemaining/1GB,1)}},
@{Name='SizeGB';Expression={[math]::Round($_.Size/1GB,1)}}
Get-PhysicalDisk | Select-Object FriendlyName, HealthStatus, OperationalStatus
If free space is falling quickly, treat that as an active incident. Clearing a few files may restore service temporarily, but you still need to identify what is growing and why.
4. Active Directory authentication and replication
Typical signs: users cannot sign in, Group Policy does not apply, account changes are inconsistent, domain controllers report replication errors or systems show trust failures.
Active Directory depends heavily on healthy DNS and accurate time. Confirm both before making directory changes. Domain members should normally use the organisation’s internal AD DNS servers, not a public resolver.
dcdiag /v
dcdiag /test:dns /v
repadmin /replsummary
repadmin /showrepl
w32tm /query /status
gpresult /h C:\Temp\gpresult.html
DCDiag checks domain-controller health, while Repadmin reports replication state. Read the results and resolve the underlying DNS, connectivity, time or replication fault. Do not restart Active Directory Domain Services or force replication blindly on a production controller.
5. Remote Desktop connection problems
Typical signs: RDP times out, credentials are rejected, a session disconnects repeatedly or the server has reached its session or licensing limit.
- Confirm the server is reachable and test TCP 3389 from an authorised network:
Test-NetConnection server-name -Port 3389. - Check that Remote Desktop is enabled, the service is running and the user has the correct rights.
- Review Applications and Services Logs > Microsoft > Windows > TerminalServices.
- Check Network Level Authentication, certificates, Remote Desktop Gateway, Group Policy and licensing where applicable.
- Use console or out-of-band access for recovery if the network path is unavailable.
Do not expose RDP directly to the public internet. Use a secure VPN, Remote Desktop Gateway or another controlled access service with multifactor authentication and monitoring.
6. Windows Update failures
Typical signs: updates repeatedly fail, installation stalls, the server enters a rollback loop or servicing errors such as 0x800f081f appear.
- Confirm free space, time synchronisation, proxy access and the health of WSUS or the configured update source.
- Review update history and the WindowsUpdateClient operational log in Event Viewer.
- Generate a readable update log with
Get-WindowsUpdateLog. Modern Windows Server releases store update traces as ETL files rather than a continuously readable text log. - Check the component store with DISM, then verify protected system files with SFC.
- Test updates in a maintenance window with a verified backup and recovery plan.
Get-WindowsUpdateLog -LogPath C:\Temp\WindowsUpdate.log
DISM.exe /Online /Cleanup-Image /ScanHealth
DISM.exe /Online /Cleanup-Image /RestoreHealth
sfc /scannow
See Microsoft’s reference for Get-WindowsUpdateLog. Avoid deleting the SoftwareDistribution folder as a first step: it resets update history and may hide the evidence you need.
7. Application and service crashes
Typical signs: a service stops, an application closes unexpectedly, users see dependency errors or the same fault returns after every restart.
- Match the failure time to Application and System event logs.
- Check service dependencies, service accounts, certificates, ports and recent configuration changes.
- Confirm the application and its .NET, Java, database or runtime dependencies are supported on the installed Windows Server version.
- Use Reliability Monitor, vendor logs and crash dumps where available.
- Test the proposed fix in a non-production environment or maintenance window and document the result.
Repeatedly restarting a service may restore availability, but it is not a root-cause fix. Capture the evidence before the restart and monitor afterwards.
A simple escalation checklist
Escalate early when the server is business-critical, security compromise is suspected, backups are uncertain, Active Directory changes are involved or the next step could cause data loss. Provide the engineer with:
- A plain-English impact statement and the time the incident began.
- Server role, version, location and whether it is physical or virtual.
- Error messages, event IDs, logs and screenshots with timestamps.
- Recent changes and every troubleshooting step already attempted.
- Backup status, recovery objectives and the approved maintenance window.
Prevent the same incident happening twice
The best troubleshooting work finishes with prevention. Establish performance baselines, monitor capacity and service health, apply patches through a tested change process, verify backups with restore tests, document dependencies and review every significant incident.
If maintaining Windows Server is consuming too much internal time, Astley Digital can take responsibility for monitoring, patching, backup, security and day-to-day management. Explore our managed server services, or speak to an expert about a specific problem.
Ready for a clearer technology plan?
Tell us what is slowing your organisation down. We will help you identify the practical next step.