Fix ERROR_EVT_INVALID_OPERATION_OVER_ENABLED_DIRECT_CHANNEL

What's Actually Happening Here

You're trying to modify an Event Tracing for Windows (ETW) channel that's set to direct mode — meaning it writes events straight to consumers without buffering. The Windows Event Log API won't let you change properties like the logging path, security descriptor, or retention settings while that channel is active. The error code 0x00003AAE (decimal 15022) confirms this.

This typically pops up when you're writing a script to configure a custom event channel, or when Group Policy or a monitoring tool tries to adjust a built-in channel like Microsoft-Windows-Kernel-Process/Analytic. If you're automating infrastructure setup, you'll hit this every time until you disable the channel first.

Fix 1: Disable via wevtutil (30 seconds)

This is the quickest path. Open an admin Command Prompt or PowerShell (as Administrator).

wevtutil set-log <channel-name> /enabled:false

Replace <channel-name> with the exact channel name from the error. For example:

wevtutil set-log "MyApp/DirectChannel" /enabled:false

Once it's disabled, you can reconfigure it — change the path, max size, log mode, whatever you need. Then re-enable it:

wevtutil set-log "MyApp/DirectChannel" /enabled:true

Why this works: The wevtutil command talks to the Event Log service directly and toggles the channel's enabled state. When disabled, the API stops treating it as an active direct channel, so the modification constraint lifts. You don't need to restart anything.

Real-world trigger: You're deploying a custom ETW provider via PowerShell and your script calls New-EventLog or wevtutil set-log on a channel that was created with /enabled:true — boom, error 0x00003AAE.

Fix 2: Disable via PowerShell (5 minutes)

If you prefer PowerShell, use the Get-WinEvent and Set-WinEvent cmdlets. This approach is more flexible when you're scripting across multiple machines.

# Get the channel object
$channel = Get-WinEvent -ListLog "MyApp/DirectChannel"
# Disable it
$channel.IsEnabled = $false
$channel.SaveChanges()
# Modify your settings (example: change max size)
$channel.MaximumSizeInBytes = 1GB
$channel.SaveChanges()
# Re-enable
$channel.IsEnabled = $true
$channel.SaveChanges()

If you get access denied, verify you're running PowerShell as Administrator. The SaveChanges() method commits the change to the registry and triggers the Event Log service to refresh the channel configuration.

Why this works: SaveChanges() wraps the same underlying API calls as wevtutil, but gives you more granular control. The key step is the same — toggle IsEnabled to $false before touching other properties.

Fix 3: Registry Edit — Advanced (15+ minutes)

Only go here if wevtutil and PowerShell both fail. This would happen if the Event Log service is corrupted, or you're dealing with a system-managed channel that the tools refuse to touch (e.g., built-in Analytic channels).

Warning: Messing with the registry can hose your event system. Take a backup first.

Open Regedit and navigate to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\<channel-name>

Or for custom channels:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\<channel-name>

Look for the Enabled DWORD (might be called Enabled, IsEnabled, or Flags). Set it to 0.

If you can't find the key, use wevtutil gl <channel-name> to dump the channel metadata — the output will show the OwningPublisher and channel type. Then locate the publisher's provider GUID under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers. That GUID key will have a Channel subkey containing the channel's Enabled value.

After changing the value, restart the Windows Event Log service:

sc stop EventLog && sc start EventLog

Or just reboot — sometimes the service won't pick up registry changes without a restart.

Why this works: The direct channel's enabled state is stored in the registry. The Event Log service reads these keys at startup or when SaveChanges() is called. Forcing the Enabled bit to 0 manually bypasses the API restriction entirely. But the risk is real — you could set a wrong value and the channel won't load, breaking any application that depends on it.

Prevention: Always Disable Before Modifying

Once you've fixed it, make this a habit. When you create or configure a custom direct channel via code or scripts, always follow this pattern:

1. Disable the channel.
2. Apply your changes.
3. Re-enable it.

Here's a reusable PowerShell snippet:

function Set-DirectChannelConfig {
    param([string]$ChannelName, [hashtable]$Properties)
    $ch = Get-WinEvent -ListLog $ChannelName
    $ch.IsEnabled = $false
    $ch.SaveChanges()
    foreach ($key in $Properties.Keys) {
        $ch.$key = $Properties[$key]
    }
    $ch.SaveChanges()
    $ch.IsEnabled = $true
    $ch.SaveChanges()
}

This avoids the error every time. It's not clever — it's just respecting how the API works.

Still Stuck?

Double-check you're actually dealing with a direct channel. Run wevtutil gl <channel-name> and look at the logType field. If it says Operational, Admin, or Debug, you're not on a direct channel — the error might be a red herring. In that case, the issue is likely a permissions problem (check Event Log group policy) or a corrupted channel file (delete and recreate). But if logType says Analytic or Direct, you're in the right place.