Note the application action, duration, affected users and time. Determine whether it occurs continuously, at startup, during backups or only under a particular workload. Record the server's assigned resources and any recent application or configuration change.

1. During the slowdown, open Task Manager and identify the processes consuming CPU or memory. Record process IDs so similarly named worker processes can be distinguished.
2. Open perfmon. Use Performance Monitor for a live view, or create a Data Collector Set for an intermittent issue.
3. Add counters appropriate to the symptom. Start with processor use, process CPU, available memory, committed memory and process private bytes. Include disk or network counters when the application waits on those resources.
4. Choose a sample interval and collection duration that can capture the problem without creating unbounded logs. Use a protected output directory with sufficient free space.
5. Start collection, reproduce the approved workload or wait for the normal occurrence, then stop collection after the relevant period.
6. Compare the timeline with application requests, scheduled tasks and Event Viewer entries. For IIS, map the busy worker process to the actual application pool.

Sustained CPU pressure should be traced to the responsible process and workload. Memory growth needs a time series: compare process private bytes, system commit and available memory instead of treating cached memory as automatically wasted.

Low CPU during a slow request can indicate waiting on storage, a database or an external service. On a virtual server, ask the provider to review host-level constraints when guest evidence does not explain the observed delay.

Choose a change tied to the evidence, then repeat the same workload and compare results. Record any effect on correctness, error rate and other applications. Preserve the baseline before changing several settings at once.

In PowerShell on the affected server, list the ten processes with the largest current working sets. The output is a point-in-time diagnostic. It does not stop services or establish whether the reported memory use is a leak.

Get-Process | Sort-Object WorkingSet64 -Descending |
  Select-Object -First 10 Id, ProcessName,
    @{Name="WorkingSetMB";Expression={[math]::Round($_.WorkingSet64 / 1MB, 1)}},
    CPU

Read the result: WorkingSetMB reports memory currently resident for the process. CPU here is accumulated processor time, not its current percentage of CPU use. A long-running process can have a large CPU total while being idle now, so compare with Task Manager or Performance Monitor over the incident window.

Match a process to its application pool, database or customer workload before taking action. Preserve the timestamp and repeat a bounded sample during normal operation. Killing the largest process can interrupt unrelated customers and erase evidence without correcting the workload problem.

• Diagnosing IIS HTTP 503 Service Unavailable
• Running a scheduled PowerShell task with least privilege
• Investigating a Windows service failure with Event Viewer
• Responding to unexpected SQL Server transaction-log growth

• Microsoft: troubleshoot with Performance Monitor
• Microsoft: performance, event and service data

• Microsoft: Get-Process properties and examples