Investigative Event Log Discovery Strategy

When you need to find events in Windows but do not yet know the exact log, event ID, or provider, follow a repeatable discovery process. The goal is to move from "I want to know when something happened" to "I can reliably query for it."

The Core Mindset

Do not start with a script. Start with questions:

1. What happened? (e.g., Windows booted, shut down, crashed)
2. Who or what component would record it? (operating system, kernel, power subsystem, a user action)
3. What log would that component write to? (System, Application, Security, Setup, Forwarded Events)
4. What does the event look like? (event ID, provider name, message text)
5. How do I narrow the query efficiently?

Step-by-Step Discovery Process

Step 1: Define what you are looking for

State the investigative question plainly. For example:

I want to find evidence of when Windows boots and when it shuts down.

This becomes your filter criteria as you search. If you cannot phrase it simply, you are not ready to query logs.

Step 2: Identify the most likely log

Boot and shutdown are system-level activities. The most likely place is the System log. But you should confirm this rather than assume.

List the available logs (see PowerShell EventLog CmdLets) to see what you are working with:

Get-WinEvent -ListLog *

Narrow it to logs that sound relevant:

Get-WinEvent -ListLog *System*,*Application*,*Security*,*Setup*

At this stage, ask yourself: Which log would a kernel or operating system service write to? The answer is usually System.

Step 3: Sample the log

Do not query everything at once. Pull a small sample and inspect the shape of the data with Select-Object:

Get-WinEvent -LogName System -MaxEvents 20 |
Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message

You are looking for:
- Common event IDs
- Provider names that appear during boot or shutdown
- Messages that mention boot, shutdown, start, stop, or kernel

This step gives you the vocabulary of the log.

Step 4: Search for candidate events by keyword

When you do not know the exact event ID, search by message text to discover candidates. This is slower but effective for discovery.

Get-WinEvent -LogName System |
Where-Object { $_.Message -match 'shutdown|boot|started|stopped' } |
Select-Object TimeCreated, Id, ProviderName, Message

As you review results, patterns emerge. You will see the same event IDs and providers repeating. Those are your candidates.

Step 5: Validate the candidates

For each candidate event, look at the full event details to confirm it really means what you think it means.

Get-WinEvent -LogName System | Where-Object { $_.Id -eq 6005 } | Select-Object -First 1 | Format-List *

Common boot and shutdown candidates:

Step 6: Build a targeted filter

Once you know the event IDs, stop using Where-Object on the entire log. Use an XPath filter so the query runs efficiently, especially over large logs or remote systems.

$xpath = '*[System[(EventID=6005) or (EventID=6006) or (EventID=6008) or (EventID=41) or (EventID=1074) or (EventID=109)]]'
Get-WinEvent -LogName System -FilterXPath $xpath

This is the transition from discovery to production-ready script.

Step 7: Document your findings

Before you reuse the script, document what each event ID means and why you included it. Investigation is not just about finding data; it is about being able to explain why that data matters.

Common Pitfalls

• Guessing the log: Always confirm the log. Applications can write to the System log too.
• Using Where-Object on huge logs: It works for discovery but is inefficient for repeated queries.
• Ignoring event message context: An event ID alone does not always tell the full story. Read the message.
• Forgetting time ranges: Real investigations need temporal boundaries. Use -StartTime and -EndTime once you have a filter.

Why This Matters

The book emphasizes that before writing a script, you must define the challenge. Event log investigation is the same. You cannot collect what you cannot find, and you cannot find what you cannot describe. This strategy turns vague questions into precise, repeatable queries, and validated filters become building blocks for PowerShell as an Acquisition Engine.