# Troubleshooting

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

---

LLMS index: [llms.txt](/llms.txt)

---

## "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:

   ```powershell
   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:

   ```powershell
   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.

```powershell
# 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](../03-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:

```powershell
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](../04-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](https://github.com/AndiBellstedt/DNSServer.DebugLogParser/issues) for the same symptom.
3. Collect the diagnostics:

   ```powershell
   $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.