# Dépannage

> Symptômes que vous êtes susceptible de rencontrer lors de la conversion des journaux de débogage DNS, leurs causes et comment les résoudre.

---

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

---

## « Le fichier n'est pas un fichier de journal de débogage DNS valide »

La vérification de l'en-tête a rejeté l'entrée. En général, le chemin est simplement incorrect — un fichier `.log` dans le même dossier qui n'est pas un journal de débogage DNS, ou un fichier qui ne contient qu'un en-tête tourné.

Procédez ainsi :

1. Ouvrez le fichier. Un journal de débogage DNS commence par une ligne d'en-tête telle que `Message logging started at …` et continue avec des entrées de requêtes horodatées.
2. Confirmez que la journalisation de débogage DNS est bien activée et écrit dans le chemin attendu :

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

3. Si le fichier est vraiment un journal DNS mais que l'en-tête est inhabituel — modifié manuellement, pré-filtré, une exportation personnalisée — contournez la vérification :

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

Gardez la validation activée partout ailleurs. Notez que `-SkipHeaderValidation` ne peut pas être combiné avec `-RemoveSourceFile`, donc un fichier non vérifié ne peut jamais être supprimé par la conversion.

## Le fichier de sortie est vide ou contient beaucoup moins de lignes que prévu

Vérifiez, dans cet ordre :

- **Le journal contient-il des entrées de requêtes ?** Un journal fraîchement tourné peut ne contenir qu’un en-tête si aucune requête n’a encore eu lieu.
- **Un `-ContextFilter` est-il utilisé ?** `-ContextFilter Packet` supprime par conception les entrées `Event` et `Note`. Si vous avez filtré sur `Event` ou `Note`, la plupart des colonnes seront aussi vides — ces types d’entrées ne contiennent que `DateTime`, `ThreadId`, `Context` et `Information`.
- **Le journal source était-il actif ?** Un fichier sur lequel le serveur DNS écrit encore peut changer pendant la conversion ; les entrées les plus récentes peuvent manquer et le dernier enregistrement peut être tronqué. Convertissez un journal tourné et fermé lorsque vous avez besoin d’une sortie complète.
- **Le fichier est-il corrompu ou tronqué ?** Vérifiez la fin du journal pour une ligne partiellement écrite.

## Les dates sont incorrectes, décalées ou le jour et le mois sont inversés

Le journal a été écrit par un serveur avec une locale Windows différente de celle de la session effectuant la conversion. `20.01.2026` et `01/20/2026` décrivent le même moment, mais seulement si les deux parties s’accordent sur le format.

```powershell
# le journal vient d’un serveur allemand
Convert-DNSDebugLogFile -InputFile "C:\Logs\dns-berlin.log" -InputCulture 'de-DE'
```

Définissez explicitement `-InputCulture` dans les tâches planifiées plutôt que de compter sur la culture du compte qui les exécute. Si la sortie doit être lisible par une machine, ajoutez `-OutputCulture 'sv-SE'`. Plus de détails dans [Paramètres et options](../03-parameters-and-options/).

## Tout se retrouve dans une seule colonne après l’import

Mauvais délimiteur. Le module écrit `;` par défaut ; votre consommateur attendait `,` (ou inversement).

Relancez la conversion avec le délimiteur attendu par le consommateur :

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

…ou indiquez au programme d’importation quel délimiteur utilise le fichier — dans Excel via **Données → À partir du texte/CSV**, dans PowerShell via `Import-Csv -Delimiter ';'`.

## « Accès refusé »

- Le répertoire des journaux DNS nécessite généralement des droits administratifs. Lancez PowerShell en mode administrateur, ou exécutez la tâche planifiée avec un compte ayant les droits.
- Vérifiez aussi les droits d’écriture sur le répertoire de sortie, pas seulement les droits de lecture sur le journal.
- Pour les chemins SMB/UNC : une tâche exécutée en tant que `SYSTEM` s’authentifie sur le réseau en tant que **compte ordinateur**. Accordez les droits de partage et NTFS à ce compte ordinateur (ou au groupe `Domain Controllers`), ou utilisez un compte de service dédié.
- Si `-RemoveSourceFile` échoue à la fin d’une exécution par ailleurs réussie, le compte peut lire le journal mais pas le supprimer.

## Le traitement est très lent

1. Commencez par le disque — la conversion est limitée par les E/S. Un volume occupé ou un chemin réseau lent domine le temps d’exécution.
2. Utilisez `-NoDetailsParsing` si vous n’avez pas besoin du JSON détaillant les paquets ; sur des journaux très détaillés, cela économise 30 à 50 %.
3. Utilisez `-ContextFilter Packet` pour écrire moins.
4. Divisez les journaux énormes avec la rotation des journaux du serveur DNS au lieu de convertir un seul fichier gigantesque.
5. Envisagez une exclusion antivirus pour le répertoire des journaux.

Plus d’infos dans [Performance](../04-performance/).

## La sortie compressée est plus volumineuse que prévu

Les journaux avec un contenu très diversifié — de nombreux domaines uniques, de nombreux clients distincts — se compressent moins bien que les journaux répétitifs. C’est normal. ZIP réalise généralement une réduction substantielle ; si ce n’est pas le cas, vérifiez si la colonne `Details` gonfle le fichier et si vous en avez vraiment besoin.

## Les statistiques ne correspondent pas à ce que j’attendais

- Confirmez que vous avez utilisé `-OutputType Both` ou `-OutputType Statistic`. Avec `-OutputType CSV`, aucun fichier de statistiques n’est généré.
- `Count` est un total, pas un compte distinct. Un client demandant le même nom 500 fois contribue pour 500. C’est la cause la plus fréquente du « ce nombre ne peut pas être correct ».
- Les statistiques sont regroupées par jour. Un journal couvrant deux jours produit des lignes pour les deux.
- Si `ComputerName` est vide dans les fichiers de statistiques, `-ComputerName` n’a pas été défini lors de la conversion.

## La tâche planifiée fonctionne en mode interactif mais pas en tâche

Presque toujours l’une des trois causes :

- **Module introuvable.** `SYSTEM` avec `-NoProfile` ne voit que les chemins de modules machine-wide. Installez le module machine-wide ou ajoutez un `Import-Module DNSServer.DebugLogParser` explicite dans l’action de la tâche.
- **Mauvaise culture.** La locale du compte de la tâche diffère de la vôtre. Définissez explicitement `-InputCulture` et `-OutputCulture`.
- **Politique d’exécution ou script non signé.** Adaptez le `-ExecutionPolicy` de la tâche à votre politique de signature, et débloquez les fichiers copiés depuis ailleurs.

Exécutez manuellement la ligne de commande exacte de la tâche dans le même contexte (par exemple avec PsExec en tant que `SYSTEM`) pour reproduire le problème.

## Signaler un problème

Si rien de tout cela ne vous aide :

1. Mettez à jour vers la dernière version du module et réessayez.
2. Cherchez dans les [issues GitHub](https://github.com/AndiBellstedt/DNSServer.DebugLogParser/issues) le même symptôme.
3. Rassemblez les diagnostics :

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

   ainsi que la commande exacte que vous avez lancée, le message d’erreur complet incluant la pile d’appels, et — si vous pouvez le partager — un petit extrait anonymisé du journal reproduisant le problème.
4. Ouvrez une nouvelle issue avec ces informations.