Power
Whether PowerShell script block, module and transcription logging are on.
Use it to tell whether PowerShell activity was being logged, and spot logging switched off.
- SOFTWARE
- Defence Evasion
What It Is
This key holds the Group Policy settings that decide how Windows PowerShell records its own activity on the machine. Script block logging records each piece of code PowerShell runs, called a script block, in the Microsoft-Windows-PowerShell/Operational log. Module logging records the commands that chosen modules run, and transcription saves the input and output of each session as a text file. The machine's settings sit here in the SOFTWARE hive, and they take precedence over the same settings made for a single user.
What It Proves
EnableScriptBlockLogging, EnableModuleLogging and EnableTranscription at 1 feed the event logs investigators rely on (events 4104 and 4103). A 0 or deleted value stops that source from the change onward.
What It Does Not Prove
The values show logging configuration, not the commands. A gap in event 4104 in the Microsoft-Windows-PowerShell/Operational log that lines up with the key change is the corroborating evidence.
Where It Lives
PowerShell Logging Policy lives in the SOFTWARE hive, which holds settings for the whole machine. Offline Hive shows the path inside the hive file, as Registry Explorer opens it, and Live System shows the same key as regedit shows it on a running machine. The line under the path is where the hive file sits on disk.
SOFTWARE\C:\What It Looks Like
These are three values from this key on ws-042, the fictional machine the wiki follows, decoded into plain English. Each row shows the value as Windows stores it, its name, type and data, then what it tells you.
| Registry Value | What It Tells You |
|---|---|
| Script block logging was turned off, so PowerShell stops writing event 4104 to the Microsoft-Windows-PowerShell/Operational log. Activity after the key write is not captured, so use other sources for that window. |
| The policy was last changed at 14 Oct 2026 21:54 UTC, four minutes before PowerShell ran at 21:58. Expect a gap in event 4104 in the Microsoft-Windows-PowerShell/Operational log from that moment. |
| Transcription is off, so no per-session transcript is written. Check whether existing transcripts cover the period before re-enabling it. |
How to Read It
Read the ScriptBlockLogging, ModuleLogging and Transcription subkeys under Policies\Microsoft\Windows\PowerShell. 1 is on. Also check the HKCU copy, which a user can set without admin rights. To put it right, re-enable the policies and compare event 4104 coverage in the Microsoft-Windows-PowerShell/Operational log before and after the change.
- When Windows Writes It
- When Group Policy or a user with rights to the key writes a value.
- Which Windows Versions
- Windows PowerShell 5.1 on Windows 10 and Server 2016 to 11, and PowerShell 7
- Tools That Parse It
- Registry Explorer, RECmd, RegRipper
Hunt It
Defender is not known to record these policy keys reliably, and user-level copies can be missed, so confirm writes appear before relying on it. A 0 shows logging stopped from then, not what ran.
// PowerShell logging turned offDeviceRegistryEvents| where Timestamp > ago(Confirm It With
One artefact can mislead on its own. These other records show the same activity, or pin down when it happened, so use them to back up what PowerShell Logging Policy shows.
- Event Log SettingsShows whether the PowerShell channel itself was off, the other reason 4104 events stop.
- Script Block Logged, PowerShell Event 4104Not in the RegistryShows the gap, as script block events stop when the value changes.
- Module Logged, PowerShell Event 4103Not in the RegistryShows module logging stop at the same moment, a second check on the change.
Sources
The facts on this page come from these public pages, which say more on each point.