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.

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

« 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 :

    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 :

    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.

# 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.

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 :

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.

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 le même symptôme.

  3. Rassemblez les diagnostics :

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