Windows PowerShell · Event 600
PowerShell Event 600: A PowerShell provider started
PowerShell loaded one of its data providers — the components that let it treat the registry, certificates, or a remote endpoint as if they were drives. Most are unremarkable. One of them, WSMan, is how you discover that PowerShell remoting was used.
Also written as PowerShell 600Provider LifeCycleProvider WSMan Is StartedEvent ID 600 powershell provider
- How oftenFires constantly
- Vendor calls itInformation
- LogWindows PowerShell
- SourcePowerShell
The fields that decide it
Everything else in the log line is context.
- ProviderName
- Which provider started. This is the only field worth reading.
-
WSManPowerShell remoting was used from or to this machine. On a workstation with no remote administration, this is the finding. -
RegistryRegistry access through PowerShell. Extremely common and rarely interesting on its own. -
CertificateThe certificate store was browsed. Notable on a machine where nobody manages certificates. -
FileSystemOrdinary file access. Loads in essentially every session. -
Environment, Function, Variable, AliasCore providers that load with every session. Pure noise. - NewProviderState
- Always 'Started' for this event. The matching stop is recorded as Event 601.
- HostApplication
- The command line of the process that loaded the provider, giving you context the provider name alone does not.
- RunspaceId
- Joins this to the Event 400 that opened the session, so you can see which session reached for which provider.
Common questions
What does 'Provider WSMan Is Started' mean?
PowerShell loaded the Windows Remote Management provider, which is the transport behind PowerShell remoting — Enter-PSSession, Invoke-Command and anything using WinRM. It means remoting was involved in that session. On a server administered remotely by design this is routine; on an ordinary workstation it is worth explaining, because it usually means someone ran commands against or from that machine over the network.
Why does Event 600 appear so many times?
Because PowerShell loads a handful of core providers at the start of every session — FileSystem, Registry, Variable, Function, Alias, Environment — and each one gets its own event. On a machine that starts PowerShell frequently this dominates the classic log. Filter to the provider names that matter rather than trying to reduce the volume.
Is Event 600 useful if I already have script block logging?
Less so, but not useless. Script block logging tells you the code; Event 600 tells you which subsystems the engine actually engaged, and it keeps working on hosts where script block logging was never enabled. The WSMan entry in particular is a cheap, always-on remoting indicator that costs nothing to alert on.
What is the difference between Event 600 and Event 601?
600 records a provider starting and 601 records it stopping. They pair the same way 400 and 403 do for the engine itself. In practice 600 is the one people alert on, because the moment a provider is loaded is the interesting one.
Read next
- Usually comes before PowerShell Event 400: A PowerShell session started The engine start for the session that loaded this provider.
- Usually comes after PowerShell Event 403: A PowerShell session ended The engine stop for the same session.
- The equivalent of PowerShell Event 4103: Module logging recorded a command Module logging, which shows the commands rather than the subsystems they pulled in.
- Read alongside Event 4624: An account was successfully logged on A network logon on the target machine, which is what PowerShell remoting produces at the far end.
Mentioned by
Vendor documentation
Last reviewed 6 September 2026