Skip to content
BytePath
BytePath v0.0.35

Windows Fundamentals and Event Logs

Before you start

Who is this for?

For learners who want to understand Windows administration and troubleshoot common host issues.

Prerequisites

  • Basic computer use

What you'll be able to do

  • Describe Windows components, accounts, services, and permissions
  • Inspect networking
  • Query Event Viewer and event channels

Practical outcome

Collect a concise timeline from relevant system and application events.

Windows administrationAvailable

Understand host identities, services, files, permissions, networking, and the event logs used to investigate issues.

Difficulty
Beginner
Time
70 min
Practice
Investigate a system or application issue using event records
Assessment
Knowledge check

Windows combines a kernel and drivers with user-mode services and applications. User accounts and security tokens determine what a process can access. The Service Control Manager coordinates Windows services, while the Event Log service stores events from Windows components and applications. Product editions, policy, and Windows versions can change which tools and logs are available.

1. Users, groups, and elevation

Section titled “1. Users, groups, and elevation”

A local account belongs to one computer; a work or school account may be managed by an organisation. Groups make it easier to assign permissions to sets of users. Membership in local Administrators grants broad rights, so use a standard account for routine work and elevate only for a task that requires it.

User Account Control (UAC) prompts when an action requests elevation. A prompt is a boundary to review, not a reason to approve every request. whoami /all displays the current identity and security groups; in PowerShell, Get-LocalUser and Get-LocalGroup inspect local accounts and groups where those cmdlets are available.

2. Processes, services, and startup

Section titled “2. Processes, services, and startup”

A process is a running program with its own process ID and security context. A service runs under the Service Control Manager and may start automatically, on demand, or through a trigger. One service can host several service components in a shared process, so ending a process can affect more than one function.

Terminal window
Get-Process | Sort-Object CPU -Descending | Select-Object -First 10 Name, Id, CPU
Get-Service | Where-Object Status -eq 'Running' | Select-Object Name, DisplayName
Get-Service -Name Spooler

Inspect service dependencies and its configured account before stopping or changing a service. Avoid terminating a process simply because its name is unfamiliar; first identify its path, publisher, parent process, and role.

3. Filesystems and permissions

Section titled “3. Filesystems and permissions”

Windows commonly uses NTFS, which stores files and access-control lists (ACLs). A file or folder can grant or deny permissions to users and groups. Effective access depends on the ACL, group membership, inheritance, and the path through parent directories. A visible file is not necessarily readable by the current account.

Terminal window
Get-Item .\report.txt | Select-Object FullName, Length, LastWriteTime
Get-Acl .\report.txt | Format-List Owner, Access
icacls .\report.txt

Do not replace a detailed ACL with broad access such as Everyone:Full Control as a troubleshooting shortcut. Check the intended identity and required operation, then make the narrowest approved change.

4. Networking checks

Section titled “4. Networking checks”
Terminal window
ipconfig /all
Get-NetIPConfiguration
Resolve-DnsName example.com
Test-NetConnection example.com -Port 443
tracert example.com

Resolve-DnsName checks name resolution, while Test-NetConnection -Port tests a TCP connection to one port. Neither proves that the full application workflow succeeds. A failed ping may reflect filtering. Compare address, route, DNS, and the application’s required endpoint before changing firewall settings.

5. Event logs and Event Viewer

Section titled “5. Event logs and Event Viewer”

The classic Application, System, and Security logs answer different questions. Application events come from software; System events come from Windows components and drivers; Security events depend on audit policy and record security activity when configured. Other useful channels include Windows PowerShell, Task Scheduler, Windows Defender, and service-specific Operational logs. Log names and retention are policy- and version-dependent. Microsoft documents the Windows Event Log architecture and key concepts.

Open Event Viewer (eventvwr.msc) and inspect a narrow time range. An event’s timestamp, provider/source, log, event ID, level, and message provide context. Event IDs should be interpreted with their provider and version; the same number is not globally meaningful on its own.

PowerShell can filter before returning results:

Terminal window
$since = (Get-Date).AddHours(-2)
Get-WinEvent -FilterHashtable @{ LogName = 'System'; StartTime = $since; Level = 2 } -MaxEvents 50 |
  Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message

Level 2 means Error for the standard event levels. Access to some logs, especially Security, may require elevation or a specific group. Get-WinEvent is documented in Microsoft Learn.

6. A practical troubleshooting sequence

Section titled “6. A practical troubleshooting sequence”

For a report such as “the print service stopped”:

  1. Record the user, computer, exact time, and what action failed.
  2. Check Get-Service Spooler and note the current state.
  3. Review recent System and PrintService Operational events around that time.
  4. Check whether a recent update, dependency, or configuration change coincides with the failure.
  5. Use a test document and a non-critical queue to verify recovery after an approved change.
  6. Capture the before/after service state and relevant event messages.

For account or network issues, inspect only the relevant Security, DNS Client, WLAN, or application channels that exist and are enabled on that device. Avoid exporting a whole log when a time- and provider-filtered sample is enough; logs can contain personal or sensitive data.

7. Common mistakes

Section titled “7. Common mistakes”
  • Treating every process as a service or terminating a shared service host.
  • Assuming a user is an administrator because an app was launched from an administrator’s machine.
  • Changing ACLs broadly instead of identifying the required account and access.
  • Searching every event by ID without checking provider and timestamp.
  • Treating one failed ping as proof that a service is down.
  • Clearing logs during troubleshooting; preserve relevant evidence and follow local retention policy.

Practical exercise

Section titled “Practical exercise”

On a Windows device you administer, record Get-NetIPConfiguration and the status of one built-in service. Filter recent Application or System errors with Get-WinEvent. Write down the time window, provider, event ID, and one follow-up test. Do not change a service or clear a log for the exercise.

Related: Active Directory and Entra ID Fundamentals explains domain identity and its DNS dependencies.