Troubleshooting

Symptoms you are likely to hit when converting DNS debug logs, what causes them, and how to fix them.

For AI agents: a documentation index is available at /llms.txt; a markdown version of this page is available at /docs/08-troubleshooting/index.md.

“The file is not a valid DNS debug log file”

The header check rejected the input. Usually the path is simply wrong — a .log file in the same folder that is not the DNS debug log, or a file that only contains a rotated header.

Work through this:

  1. Open the file. A DNS debug log starts with a header line such as Message logging started at … and continues with timestamped query entries.

  2. Confirm that DNS debug logging is actually enabled and writing to the path you expect:

    Get-DnsServerDiagnostics | Select-Object Enable, LogFilePath, MaxMBFileSize

  3. If the file genuinely is a DNS log but the header is unusual — hand-edited, pre-filtered, a custom export — bypass the check:

    Convert-DNSDebugLogFile -InputFile "C:\Logs\odd.log" -SkipHeaderValidation

Keep the validation enabled everywhere else. Note that -SkipHeaderValidation cannot be combined with -RemoveSourceFile, so an unverified file can never be deleted by the conversion.

Output file is empty or has far fewer rows than expected

Check, in this order:

  • Does the log contain query entries at all? A freshly rotated log can hold nothing but a header if no queries occurred yet.
  • Is a -ContextFilter in play? -ContextFilter Packet removes Event and Note entries by design. If you filtered to Event or Note, most columns will also be empty — those entry types only carry DateTime, ThreadId, Context and Information.
  • Was the source log active? A file DNS Server is still writing to can change during conversion; the newest entries may be missing and the last record may be truncated. Convert a rotated, closed log when you need complete output.
  • Is the file corrupt or truncated? Check the end of the log for a half-written line.

Dates are wrong, shifted, or day and month are swapped

The log was written by a server with a different Windows locale than the session doing the conversion. 20.01.2026 and 01/20/2026 describe the same moment, but only if both sides agree on the format.

# log came from a German server
Convert-DNSDebugLogFile -InputFile "C:\Logs\dns-berlin.log" -InputCulture 'de-DE'

Set -InputCulture explicitly in scheduled jobs rather than relying on the culture of the account that happens to run them. If the output should be machine-readable, add -OutputCulture 'sv-SE'. Details in Parameters and Options.

Everything ends up in one column after import

Delimiter mismatch. The module writes ; by default; your consumer expected , (or vice versa).

Either re-run the conversion with the delimiter the consumer wants:

Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -Delimiter ","

…or tell the importer which delimiter the file uses — in Excel via Data → From Text/CSV, in PowerShell via Import-Csv -Delimiter ';'.

“Access denied”

  • The DNS log directory typically requires administrative rights. Start PowerShell elevated, or run the scheduled task with an account that has access.
  • Check write access to the output directory as well, not just read access to the log.
  • For SMB/UNC paths: a task running as SYSTEM authenticates on the network as the computer account. Grant share and NTFS rights to that computer account (or to the Domain Controllers group), or use a dedicated service account.
  • If -RemoveSourceFile fails at the end of an otherwise successful run, the account can read the log but not delete it.

Processing is very slow

  1. Disk first — conversion is I/O-bound. A busy volume or a slow network path dominates the runtime.
  2. Use -NoDetailsParsing if you do not need the packet-detail JSON; on detail-heavy logs this saves 30–50 %.
  3. Use -ContextFilter Packet to write less.
  4. Break huge logs up with DNS Server log rollover instead of converting one enormous file.
  5. Consider an antivirus exclusion for the log directory.

More in Performance.

Compressed output is larger than expected

Logs with very diverse content — many unique domains, many distinct clients — compress less than repetitive ones. That is normal. ZIP still typically achieves a substantial reduction; if it does not, check whether the Details column is inflating the file and whether you need it at all.

Statistics do not match what I expected

  • Confirm you used -OutputType Both or -OutputType Statistic. With -OutputType CSV, no statistics files are written at all.
  • Count is a total, not a distinct count. One client asking for the same name 500 times contributes 500. This is the most frequent source of “that number cannot be right”.
  • Statistics are grouped per day. A log spanning two days produces rows for both.
  • If ComputerName is empty in the statistics files, -ComputerName was not set during conversion.

The scheduled task works interactively but not as a task

Almost always one of three things:

  • Module not found. SYSTEM with -NoProfile only sees machine-wide module paths. Install the module machine-wide or add an explicit Import-Module DNSServer.DebugLogParser to the task action.
  • Wrong culture. The task account’s locale differs from yours. Set -InputCulture and -OutputCulture explicitly.
  • Execution policy or unsigned script. Match the task’s -ExecutionPolicy to your signing policy, and unblock files copied from elsewhere.

Run the exact task command line manually in the same context (for example with PsExec as SYSTEM) to reproduce it.

Reporting an issue

If none of this helps:

  1. Update to the latest module version and retry.

  2. Search the GitHub issues for the same symptom.

  3. Collect the diagnostics:

    $PSVersionTable
Get-Module DNSServer.DebugLogParser -ListAvailable | Select-Object Name, Version, Path
Get-Culture

    plus the exact command you ran, the full error message including the stack trace, and — if you can share it — a small anonymised excerpt of the log that reproduces the problem.

  4. Open a new issue with that information.