Investigating Low Disk Space on Windows Server

Purpose

Explain the alert

Identify which volume is constrained, how quickly it changed, and which workload or storage consumer best matches the evidence.

Boundary

Measure before changing

No files, logs, snapshots, databases, checkpoints, retention settings, services, or volumes are changed by this guide.

Example

Synthetic server only

LAB-SRV-01 and its example values are documentation-safe placeholders, not production-derived evidence.

Method

Role, trend, consumer

Interpret capacity together with server role, backup state, recent changes, service impact, and the rate of growth.

1 · Investigation question

What is this investigation designed to answer?

Determine whether one volume is genuinely constrained, whether consumption was sudden or gradual, what category of data is growing, and which accountable owner should evaluate the safest remediation.

Which volume?

Match the alert to the exact drive letter, mount point, volume label, capacity, and current free space.

What changed?

Compare prior measurements and recent patching, software, backup, logging, workload, and application changes.

What owns the data?

Connect the likely consumer to the server role and the team responsible for its application, retention, backup, and recovery requirements.

What remains unknown?

File size alone does not establish whether data is active, recoverable, duplicated, safe to move, or safe to delete.

2 · Alert context

Low disk alerts require both percentage and absolute context.

Ten percent free on a 100 GB volume and ten percent free on a 10 TB volume describe very different operating buffers. Record both values, the workload's growth rate, and the space required for updates, logs, databases, checkpoints, backups, and recovery operations.

Do not invent one universal threshold

Alert thresholds should reflect the server role, expected growth, service requirements, storage architecture, and recovery plan. A percentage alone does not prove an outage, and a large absolute value does not prove the remaining buffer is adequate.

3 · Boundaries and safety

Collect evidence before files are removed.

Use an account authorized to read the relevant volume and application paths. Some volume, event-log, VSS, and servicing details require an elevated session. Record access-denied results instead of treating unreadable paths as empty.

Large does not mean unnecessary. Old does not automatically mean safe to delete. Server role and backup state must be known before remediation.

A successful cleanup does not explain why growth occurred. Freeing space without correcting recurring growth only delays the next alert.

4 · Initial evidence

Build a minimum record before testing.

System

Role and platform

Record the server role, operating-system version, whether it is virtual or physical, and whether storage expansion is technically available.

Capacity

Volume and measurements

Record the affected volume, total capacity, available space, percentage free, alert timestamp, and previous free-space measurements.

Recent work

Changes near the alert

Record recent patching, software installation, application deployment, backup changes, logging changes, exports, imports, and maintenance activity.

Safety

Backup and impact

Confirm whether backups are current and verified, and whether users, services, databases, replication, updates, or recovery operations are affected now.

5 · Affected volume

Confirm that the alert and the measured object are the same volume.

Drive letters, mount points, cluster storage, virtual disks, pass-through storage, and mapped file-system drives can produce different views. Start with the alert's identifier, then compare volume labels, drive letters, paths, and capacity before investigating directories.

Get-Volume |
    Select-Object DriveLetter, FileSystemLabel, FileSystem, HealthStatus,
        SizeRemaining, Size

Get-Volume is provided by the Windows Storage module and returns volume objects. It is useful for local volume identity, health status, and remaining capacity; not every volume has a drive letter.

6 · Current capacity

Measure the same condition through the appropriate interface.

PowerShell file-system drives

Get-PSDrive -PSProvider FileSystem |
    Select-Object Name, Root,
        @{Name='UsedGB'; Expression={[math]::Round($_.Used / 1GB, 2)}},
        @{Name='FreeGB'; Expression={[math]::Round($_.Free / 1GB, 2)}}

This reports drives exposed by the PowerShell FileSystem provider, including mapped and session drives. It is convenient, but it is not a substitute for identifying the underlying local volume.

Local fixed logical disks

Get-CimInstance -ClassName Win32_LogicalDisk -Filter "DriveType=3" |
    Select-Object DeviceID, VolumeName,
        @{Name='SizeGB'; Expression={[math]::Round($_.Size / 1GB, 2)}},
        @{Name='FreeGB'; Expression={[math]::Round($_.FreeSpace / 1GB, 2)}},
        @{Name='PercentFree'; Expression={
            [math]::Round(($_.FreeSpace / $_.Size) * 100, 2)
        }}

Win32_LogicalDisk exposes logical-disk size and free-space properties. The DriveType=3 filter limits this example to local fixed disks.

Native volume query

fsutil volume diskfree C:

This native command reports free-space values in bytes for the selected volume. Microsoft documents fsutil as an administrative tool; use it from an elevated Command Prompt or PowerShell session. It does not calculate a friendly percentage.

7 · Growth pattern

Determine whether consumption was sudden or gradual.

Compare monitoring history at consistent intervals. Align the first material change with patching, installs, deployments, backup jobs, application activity, log rotation, database maintenance, imports, exports, checkpoints, or user activity.

Sudden drop

Look for one bounded event: a dump, failed backup staging run, new virtual disk or checkpoint, database growth, installation, export, or runaway log.

Gradual decline

Look for retention drift, normal workload growth, missing log rotation, accumulating profiles, backup history, or a volume sized below the workload's trend.

Alert without matching use

Confirm the monitored object, collection time, agent health, mount point, quota, and whether the alert is delayed or still open after recovery.

8 · Common consumers

Investigate categories; do not treat them as automatic deletion targets.

Windows

Component store, Windows Update data, temporary directories, event logs, crash dumps, installer caches, Recycle Bin, and user profiles.

Applications

IIS logs, application logs, exports, caches, monitoring and RMM agent data, and antivirus or EDR quarantine.

Data platforms

SQL Server data files, transaction logs, backup files, and application-owned databases whose file size does not reveal internal free space.

Virtualization and protection

Hyper-V virtual disks and checkpoints, backup-agent caches and staging data, repositories, and Volume Shadow Copy storage.

File services

File-server shares, redirected folders, profile containers, quotas, departmental data, and client-accessible previous versions.

Start bounded

Get-ChildItem -LiteralPath 'C:\' -Directory -Force -ErrorAction SilentlyContinue |
    Select-Object FullName, LastWriteTime, Attributes

This one-level inventory identifies known top-level locations without sizing every file. Choose a role-relevant root next. Confirm that the selected root is not an unexpected junction, reparse point, or mount point before recursion.

Measure one approved location

$Path = 'C:\inetpub\logs\LogFiles'
$Files = Get-ChildItem -LiteralPath $Path -File -Recurse -Force `
    -ErrorAction SilentlyContinue

[pscustomobject]@{
    Path       = $Path
    FileCount  = $Files.Count
    SizeGB     = [math]::Round(($Files | Measure-Object Length -Sum).Sum / 1GB, 2)
    OldestFile = ($Files | Sort-Object LastWriteTime | Select-Object -First 1).LastWriteTime
    NewestFile = ($Files | Sort-Object LastWriteTime -Descending | Select-Object -First 1).LastWriteTime
}

Recursive scans can be expensive

This example is read-only but can still produce substantial I/O on a large or busy path. Limit the root, use an appropriate window, monitor impact, avoid following reparse-point or junction targets, and record access-denied paths. Do not start with an unrestricted recursive scan of the entire system drive.

9 · Component store

Use the servicing analysis instead of trusting Explorer size.

WinSxS uses hard links, so an Explorer or generic recursive total can overstate its independent disk consumption. Microsoft provides a servicing analysis that reports the component store's actual size and whether cleanup is recommended.

DISM /Online /Cleanup-Image /AnalyzeComponentStore

Run the command from an elevated session. It creates a report; it does not perform cleanup. A recommendation in the report is evidence for a separately authorized maintenance decision, not permission to delete WinSxS content or run cleanup immediately.

10 · Log growth

Separate configured capacity, current file size, and event volume.

Review Windows logs and application-owned logs independently. A large circular event log can be correctly configured; a rapidly growing application log can indicate a repeated failure even when its retention is working as designed.

Get-WinEvent -ListLog * -ErrorAction SilentlyContinue |
    Where-Object FileSize |
    Sort-Object FileSize -Descending |
    Select-Object -First 20 LogName, RecordCount, FileSize,
        MaximumSizeInBytes, LogMode, LogFilePath

Get-WinEvent -ListLog returns event-log configuration objects, including current file size, maximum size, mode, and path when available. Reading some logs can require elevation. Record the largest logs and correlate their timestamps and providers; do not clear them as an investigative shortcut.

11 · Shadow copies and backups

Review protection dependencies before treating shadow storage as waste.

VSS is used by Windows features and many backup products. Shadow storage can be legitimate, can reside on another volume, and can affect previous versions, backup, restore, and application-consistent operations.

vssadmin list shadowstorage
vssadmin list shadows

These commands list shadow-storage associations and existing shadow copies. Run them from an elevated session. Record the source volume, storage volume, used and maximum allocation, providers, timestamps, and backup ownership. Do not resize storage or delete shadow copies without understanding restore requirements and application dependencies.

12 · Server roles

The same directory can have very different importance on another server.

Domain controllers

Escalate storage pressure involving the OS volume, NTDS database or logs, SYSVOL, DFS Replication, DNS, or backup state. Never treat directory-service paths as general file cleanup.

DNS and DHCP

Separate service databases, audit logs, debug logs, backups, and exported configuration from ordinary temporary data. Confirm service ownership before any retention decision.

SQL Server

Database, transaction-log, tempdb, and backup growth require database context. A full transaction log can restrict updates, and shrinking a file does not resolve why log reuse is blocked.

Exchange Server

Mailbox databases, transaction logs, transport queues, search data, and backup truncation are application-critical. Escalate through the Exchange and backup owners.

Hyper-V hosts

VHDX and AVHDX files belong to virtual-disk chains. Checkpoints can grow and merge operations require working space; never delete virtual-disk files directly.

File servers

Shares, quotas, previous versions, redirected folders, profile containers, deduplication, and business retention determine whether apparent growth is expected.

RDS Session Hosts

User profiles, profile containers, temporary data, application caches, spool files, and session density can distribute ownership across user, platform, and application teams.

Backup repositories

Capacity, retention, immutability, synthetic fulls, staging, deduplication, and catalog dependencies belong to the backup design. Do not remove restore data to silence an alert.

IIS and application servers

Correlate site logs, failed-request traces, dumps, deployment packages, application logs, caches, and data paths with application ownership and retention.

13 · Evidence correlation

Separate observations from conclusions.

Observation	What it may indicate	What it does not prove	Safest next investigation step
Free space dropped suddenly.	A bounded event such as a dump, backup stage, checkpoint, database growth, install, export, or runaway log.	Which file is unnecessary or that deletion is safe.	Align the first drop with change, job, application, and modification-time evidence.
Free space declined gradually.	Normal workload growth, retention drift, accumulating logs, profiles, backups, or undersized storage.	That the monitoring threshold is wrong.	Calculate the trend and compare it with documented retention and capacity forecasts.
Event logs are unusually large.	Configured maximums, high event volume, or a repeated provider condition.	That the logs are disposable or caused the original issue.	Record size, maximum, mode, path, providers, and event timing before involving the service owner.
Component-store analysis recommends cleanup.	Windows servicing reports reclaimable component-store content.	That manual deletion is safe or cleanup explains recurring growth.	Preserve the report and route a separate servicing-maintenance decision.
SQL transaction logs are large.	Normal allocation, active work, recovery model, missing log backups, replication, availability, or blocked reuse.	That the file can be deleted, truncated, or shrunk safely.	Escalate to the database owner with volume, database, backup, and SQL log-reuse evidence.
Hyper-V checkpoints exist.	Planned change protection, backup activity, or an incomplete checkpoint lifecycle.	That AVHDX files are orphaned or can be removed directly.	Match checkpoints to VMs, backup jobs, timestamps, disk chains, and available merge space.
Shadow storage consumes substantial space.	Previous versions, backup, restore, or application-consistent snapshot activity.	That shadow copies are stale or unnecessary.	Identify the protected and storage volumes, providers, backup owner, restore need, and configured allocation.
Temporary directories contain old files.	An application, installer, update, or job did not remove intermediate data.	That age alone makes the files safe to delete.	Identify file ownership, open handles, creation source, backup need, and supported cleanup path.
Backup staging data remains.	An active job, failed cleanup, retry, restore point, or repository workflow.	That the backup is complete or the staging data is expendable.	Correlate the path with job history, catalog state, retention, and the backup vendor or owner.
One user profile is unusually large.	Application caches, profile containers, downloads, offline data, or user-owned content.	That the profile is abandoned or unneeded.	Confirm ownership, session state, profile technology, policy, and business retention.
Disk use appears normal but the alert persists.	A stale alert, wrong monitored object, agent problem, mount point, quota, or collection delay.	That monitoring can be ignored.	Match the monitor's volume identifier and timestamp to fresh local measurements and agent health.
The affected volume is not the system drive.	An application, database, VM, backup, share, or mounted workload volume is constrained.	That operating-system health and service availability are unaffected.	Map the volume to its paths, services, workload owner, backup, and expansion options.

14 · Escalation

Stop when service risk, data ownership, or change authority exceeds investigation.

Preserve measurements, timestamps, paths, owners, recent changes, and backup evidence, then escalate through the accountable platform, application, database, virtualization, security, or backup path when any of these conditions appears:

Immediate service risk

A system volume is critically constrained, services are failing, updates or logging cannot complete, or users are actively affected.

Protected workloads

Database or transaction-log growth, Hyper-V checkpoint or virtual-disk concerns, domain-controller storage, or Exchange Server storage is involved.

Recovery risk

Backups are missing or unverified, a backup repository is constrained, or shadow-copy ownership and restore dependencies are unclear.

Security or integrity

Files are rapidly growing, unexpectedly encrypted, unknown, or associated with possible ransomware, compromise, filesystem errors, or corruption.

Ownership unknown

The application, data, retention policy, backup job, monitoring source, or responsible team cannot be identified.

Change required

Any next step requires deletion, cleanup, resize, migration, retention change, application change, service interruption, or reboot.

15 · Intentionally excluded

This guide does not provide cleanup or remediation procedures.

Excluded actions include manually deleting WinSxS or Windows Installer content; deleting Windows Update data, databases, transaction logs, Hyper-V checkpoints, virtual disks, shadow copies, backup catalogs, restore data, or active logs; clearing event logs; shrinking shadow storage; removing updates; changing retention; disabling services or security software; moving application data; resizing or extending volumes; running component-store cleanup; modifying the registry; or rebooting the server.

Those actions require separate authorization, verified backups, change control, application ownership, rollback planning, and an environment-specific remediation plan.

16 · Related resources

Continue through the appropriate KrippyTech path.

Learning method

MSP University

Use the understand, investigate, resolve, and verify sequence while keeping this guide in the investigation phase.

Review the learning path

Topic hub

Windows & Hybrid

Place storage evidence alongside Windows Server, Active Directory, DNS, services, event logs, and hybrid dependencies.

Open the Windows & Hybrid hub

Related investigation

DNS, Active Directory, and domain health

Use the domain-health guide when a low-space condition overlaps domain-controller services, replication, time, DNS, or directory evidence.

Open the domain-health guide

Focused tool

Test-KTDNS v1.0.0

Use the published read-only DNS tool only when the investigation also requires a bounded name-resolution check.

Open the Test-KTDNS tutorial

Microsoft sources