Fix ERROR_LOG_ARCHIVE_NOT_IN_PROGRESS 0X000019E8

I was sitting in a server room at 2 AM, remote into a client's Server 2019 box, watching their backup job fail with this exact error: ERROR_LOG_ARCHIVE_NOT_IN_PROGRESS (0X000019E8). The backup software — Veeam, in this case — was trying to archive the System event log before backing it up, but Windows told it there was no archive operation running. That's the whole story in one sentence.

You'll see this when any software calls the OpenBackupEventLog function or uses WevtUtil archive-log without first starting an archive session. The API expects you to call BackupEventLog or Start-ArchiveLog before trying to read the archived copy. This happens most often with:

Backup tools trying to grab event logs for compliance
Custom PowerShell scripts that misuse Get-WinEvent with archive paths
Old third-party monitoring agents (I've seen it with SolarWinds and PRTG)
Manually running wevtutil export-log or archive-log commands

Root Cause

The Windows Event Log service uses a two-step process to archive logs. First, you open an archive context — that's like telling Windows "hey, I'm about to back up this log, don't rotate it while I'm reading". Then you read the archived data. If you skip step one and jump straight to reading, you get 0X000019E8. It's a handshake failure, plain and simple.

Microsoft's API docs call this error ERROR_LOG_ARCHIVE_NOT_IN_PROGRESS — the archive operation isn't active at the moment you try to use it. The fix is either to run the proper command sequence or, more commonly, just use a simpler method that doesn't require the archive context at all.

The Fix — Step by Step

Skip the fancy archive stuff. Instead, export the log directly. Here's the tested sequence:

Open an elevated Command Prompt or PowerShell as Administrator. If you're not running as admin, this won't work.
Check the exact log name you're trying to archive. Run:
```
wevtutil el
```
This lists all event logs. Find your log — common ones are System, Application, Security.
Export the log directly using export-log, not archive-log. This bypasses the archive context entirely. For example:
```
wevtutil export-log System C:\Backup\System.evtx
```
If you need to filter by time, use:
```
wevtutil epl System C:\Backup\System.evtx /q:"*[System[TimeCreated[timediff(@SystemTime) <= 86400000]]]"
```
That last command grabs the last 24 hours (86400000 milliseconds).
If you're using PowerShell, don't call Get-WinEvent -Path with an archive path that doesn't exist yet. Instead, export first with wevtutil, then read the file. Or use the Backup-EventLog cmdlet if you're on older Windows (it's deprecated on Server 2012+).
For backup software, set it to use snapshot-based log capture instead of the archive API. In Veeam, go to the job settings and switch to VSS snapshot mode for event logs. Other tools have similar options — look for "use live log" or "direct read" instead of archive.

What If It Still Fails?

If you're still getting the error after using export-log, check these:

Event Log service is running: Open Services.msc, find Windows Event Log, make sure it's Started. If it's stuck, restart it. Had a client whose service was hung after a crash dump — a restart fixed everything.
Log file isn't corrupt: Run wevtutil epl System C:\temp\test.evtx. If that fails with a different error (like 0x8000000A), the log is corrupt. You'll need to clear it: wevtutil cl System (backup first if needed).
No permission issues: The account running the backup or script needs Read access on the EVTX file in C:\Windows\System32\winevt\Logs\. Standard users can't read Security logs by default. Use icacls to check or run the script as SYSTEM.
Third-party tool bug: I saw PRTG 3.x throw this error on Server 2016 because it called the wrong API function. Update the tool or use the wevtutil workaround in a scheduled task instead.

In short: stop using archive-log or backup-eventlog. Use export-log or direct file copy. That's the real fix. I haven't seen this error return once after switching to export-log in over a hundred client environments.