BSOD Windows 10 : où trouver et comment générer les fichiers de vidage mémoire (Minidump, MEMORY.DMP)

Après un écran bleu (BSOD) sous Windows 10, vous ne trouvez aucun fichier .dmp ? Voici un guide complet pour comprendre comment ces dumps sont créés, où ils se trouvent, comment les activer correctement et comment les analyser pour identifier la cause des plantages.

Sommaire

Localisation et création des fichiers de vidage mémoire (dumps) après un BSOD sous Windows 10

Vue d’ensemble de la question

Un utilisateur constate des BSOD répétés mais ne trouve aucun fichier minidump ni MEMORY.DMP. Cela signifie généralement que la collecte n’a pas atteint 100 % ou que la configuration/les prérequis empêchent l’écriture du dump. Les sections ci‑dessous expliquent précisément quoi vérifier.

Réponse & solution

Condition préalable à la création du dump

Sur l’écran bleu, le pourcentage de collecte doit atteindre 100 %. Si le PC redémarre avant 100 %, aucun fichier ne sera écrit.
Ne forçez pas le redémarrage (bouton RESET/Power long) tant que la collecte n’est pas terminée ; cela interrompt l’écriture du dump.
Le disque système doit être accessible en écriture au moment du crash (pas de panne disque, corruption du système de fichiers, chiffrement bloquant, etc.).

Emplacement par défaut

Petits dumps (minidumps) : C:\Windows\Minidump\*.dmp
Dump mémoire complet/automatique : C:\Windows\MEMORY.DMP

Remarques utiles :

Le dossier Minidump est créé lors du premier crash si la configuration est correcte. S’il n’existe pas, vous pouvez le créer manuellement, mais cela ne suffit pas : la configuration doit aussi permettre sa génération.
La variable %SystemRoot% pointe en général vers C:\Windows.

Vérifier/activer la génération de dumps (interface graphique)

Ouvrez Exécuter (Win + R) → tapez sysdm.cpl → Entrée.
Onglet Paramètres avancés → bloc Démarrage et récupération → Paramètres.
Dans Écriture des informations de débogage, choisissez Petit vidage de mémoire (256 Ko).
Vérifiez que le répertoire indiqué est %SystemRoot%\Minidump.
Cochez Écrire un événement dans le journal système. Laisser Redémarrer automatiquement désactivé le temps du diagnostic pour que l’écran bleu reste affiché.
Cliquez sur OK puis redémarrez si demandé.

Vérifier/activer par commande (PowerShell)

Pour les environnements gérés ou pour auditer rapidement la configuration :

# Lister la configuration Crash Control
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' |
  Select-Object CrashDumpEnabled, MinidumpDir, DumpFile, Overwrite, AlwaysKeepMemoryDump, DedicatedDumpFile, LogEvent, AutoReboot

# Définir le minidump à 256 Ko et le dossier Minidump

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' `  -Name 'CrashDumpEnabled' -Type DWord -Value 3
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl'`
-Name 'MinidumpDir' -Type ExpandString -Value '%SystemRoot%\Minidump'

# Désactiver le redémarrage auto pendant le diagnostic

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' `
-Name 'AutoReboot' -Type DWord -Value 0

Correspondance des options Windows ↔ registre

Option « Écriture des informations de débogage »	Valeur `CrashDumpEnabled`	Fichier/chemin par défaut	Usage recommandé
Aucune	`0`	—	Jamais pour du diagnostic
Petit vidage de mémoire (256 Ko)	`3`	`%SystemRoot%\Minidump\*.dmp`	Idéal pour une analyse rapide et l’historique des crashs
Image mémoire du noyau	`2`	`%SystemRoot%\MEMORY.DMP`	Bon compromis pour les crashs récalcitrants
Image mémoire complète	`1`	`%SystemRoot%\MEMORY.DMP`	Nécessite un pagefile ≥ RAM ; utile pour des cas très complexes
Dump automatique	`7`	`%SystemRoot%\MEMORY.DMP`	Laisse Windows dimensionner le pagefile

Bonnes pratiques supplémentaires (à ne pas négliger)

Pagefile : garder un fichier d’échange sur le disque système (C:). Sa désactivation empêche la plupart des dumps. Pour un dump complet, la taille du pagefile doit être au moins égale à la RAM physique installée + ~1 Mo. En « automatique », Windows ajuste pour garantir l’écriture.
Espace disque : prévoir plusieurs Go libres (10–25 % du disque système à titre indicatif) pour éviter que le nettoyage automatique ne supprime MEMORY.DMP.
Mettre à jour les pilotes critiques : GPU, chipset, stockage, réseau et BIOS/UEFI. Les jeux comme Fortnite combinés à des pilotes graphiques obsolètes déclenchent souvent des BSOD (ex. VIDEO_TDR_FAILURE).
Attendre le 100 % : ne coupez jamais l’alimentation tant que l’écran bleu n’affiche pas 100 % de collecte.
Service « Windows Error Reporting » : il doit être actif (manuel/déclenché ou automatique). S’il est désactivé, certains rapports peuvent ne pas être référencés et MEMORY.DMP peut être nettoyé trop tôt.
Conserver le dump : définissez AlwaysKeepMemoryDump=1 pour éviter sa suppression par l’Assistant de maintenance.

Checklist express

Collecte BSOD arrive à 100 % ✅
CrashDumpEnabled ≠ 0 ✅
Pagefile actif sur C: (taille suffisante) ✅
Espace disque libre suffisant ✅
%SystemRoot%\Minidump existe/accessible ✅
Service Windows Error Reporting non désactivé ✅
Redémarrage automatique désactivé pendant l’enquête ✅

Analyse des dumps

Outils Microsoft

Installez WinDbg (version Microsoft Store) ou via le kit Windows 10 ADK. Procédure de base :

Lancez WinDbg → File > Open dump file → ouvrez .dmp (minidump ou MEMORY.DMP).
Exécutez les commandes suivantes pour préparer les symboles et obtenir un rapport approfondi :

.symfix
.reload
!analyze -v

Pour investiguer un pilote suspect :

lmvm &lt;nom_pilote&gt;    ; informations sur un module (ex. nvlddmkm, atikmdag)
kv                    ; pile d’appels avec paramètres
!thread               ; thread courant
!irpfind              ; IRP en vol (utile pour crashs I/O)

Corrélez ensuite avec l’Observateur d’événements (journaux Système) et le Moniteur de fiabilité (perfmon /rel) pour vérifier s’il y a eu installation de pilotes/mises à jour juste avant le crash (événement BugCheck ID 1001).

Interpréter rapidement un minidump

Stop code : par ex. IRQL_NOT_LESS_OR_EQUAL, PAGE_FAULT_IN_NONPAGED_AREA, VIDEO_TDR_FAILURE.
Module fautif : le paramètre « Probably caused by » dans !analyze -v indique souvent un pilote tiers.
Contexte : notez l’application ouverte (jeu, rendu vidéo, VM…), l’heure, et tout périphérique branché.

Alternative si aucun dump n’apparaît malgré tout

Désactiver temporairement le redémarrage automatique pour lire le code d’arrêt complet et laisser la collecte atteindre 100 % : sysdm.cpl → Démarrage et récupération → décocher Redémarrer automatiquement.
Dans sysdm.cpl, tester Image mémoire du noyau ou Image mémoire complète si les minidumps ne suffisent pas. Assurez-vous que la taille du pagefile est suffisante (pour un dump complet : ≥ RAM).
Stratégies de groupe : ouvrez gpedit.msc → Configuration ordinateur → Modèles d’administration → Système → Débogage → vérifiez que « Désactiver l’écriture du fichier de vidage » est sur Non configuré (ou Désactivé).
Registre avancé (CrashControl) :
- DumpFile (par défaut %SystemRoot%\MEMORY.DMP)
- DedicatedDumpFile (permet de définir un fichier de dump sur un autre volume rapide)
- Overwrite (1 pour autoriser l’écrasement)
- AlwaysKeepMemoryDump (1 pour empêcher les suppressions automatiques)
Pagefile : vérifiez Paramètres système avancés → Performances → Paramètres → Avancé → Mémoire virtuelle. Laisser « géré par le système » sur C: pendant l’investigation.
Filtre de stockage/pilotes tiers : certains antivirus/cryptages/solutions de stockage ajoutent des filtres noyau pouvant perturber l’écriture. Mettez à jour ou testez sans ces filtres si possible.
Vérifier l’intégrité du disque : chkdsk /f au redémarrage si des erreurs de système de fichiers sont suspectées.
Tester la mémoire : mdsched.exe (Diagnostique de mémoire Windows) ou un test étendu hors‑ligne.
Emplacements alternatifs : pour certains incidents sans BSOD mais avec gel/retour bureau, consultez C:\Windows\LiveKernelReports\ (dumps « live » du noyau) en complément des minidumps.

Procédure de test : forcer un BSOD contrôlé pour valider la configuration (optionnel, avancé)

Attention : cette opération force un crash volontaire pour vérifier que les dumps sont bien écrits. À effectuer uniquement si vous avez sauvegardé votre travail et compris les risques.

Éditez le registre (exécuté en tant qu’administrateur) : Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters] "CrashOnCtrlScroll"=dword:00000001 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters] "CrashOnCtrlScroll"=dword:00000001
Redémarrez.
Appuyez sur Ctrl + Scroll Lock deux fois : Windows déclenche un bugcheck et écrit le dump selon votre configuration.

Vérifiez ensuite la présence d’un fichier dans %SystemRoot%\Minidump ou %SystemRoot%\MEMORY.DMP.

Automatiser la vérification de l’environnement (script prêt à l’emploi)

Ce script PowerShell vérifie les points bloquants les plus fréquents et produit un résumé lisible :

$report = [ordered]@{}

# Crash Control

$cc = Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl'
$report['CrashDumpEnabled'] = $cc.CrashDumpEnabled
$report['MinidumpDir']      = $cc.MinidumpDir
$report['DumpFile']         = $cc.DumpFile
$report['AutoReboot']       = $cc.AutoReboot
$report['AlwaysKeepMemoryDump'] = $cc.AlwaysKeepMemoryDump

# Pagefile(s)

$pf = Get-CimInstance Win32_PageFileUsage | Select-Object Name, AllocatedBaseSize, CurrentUsage, PeakUsage
$pf | ForEach-Object {
$report["Pagefile_$($_.Name)*AllocatedMB"] = $*.AllocatedBaseSize
}

# Espace disque C:

$drive = Get-PSDrive -Name C
$report['C_Free_GB'] = [math]::Round($drive.Free/1GB,2)
$report['C_Used_GB'] = [math]::Round($drive.Used/1GB,2)
$report['C_Total_GB'] = [math]::Round($drive.Used/1GB + $drive.Free/1GB,2)

# Dossiers dump

$report['Minidump_Exists'] = Test-Path "$env:SystemRoot\Minidump"
$report['MemoryDMP_Exists'] = Test-Path "$env:SystemRoot\MEMORY.DMP"

# Service WER

$wer = Get-Service WerSvc -ErrorAction SilentlyContinue
if ($wer) { $report['WerSvc_Status'] = $wer.Status }

# Sortie

$report.GetEnumerator() | Sort-Object Name | Format-Table -AutoSize

Exemples concrets de causes et correctifs

Symptôme	Probable cause	Action concrète
BSOD pendant un jeu (ex. Fortnite), code `VIDEO_TDR_FAILURE`	Pilote GPU instable/obsolète	DDU en mode sans échec, réinstallation du pilote WHQL récent, désactiver overclock GPU/VRAM
BSOD `MEMORY_MANAGEMENT` aléatoire	Barrette RAM défectueuse ou timings trop agressifs (XMP)	Test mémoire étendu, retour aux timings JEDEC, remplacer la barrette fautive
Aucun `.dmp` malgré 100 % de collecte	Pagefile désactivé sur C: ou taille insuffisante	Réactiver la mémoire virtuelle sur C:, laisser « géré par le système », redémarrer
`MEMORY.DMP` introuvable après redémarrage	Nettoyage automatique (maintenance) ou stratégie entreprise	Définir `AlwaysKeepMemoryDump=1`, vérifier tâches de nettoyage et stratégies
Minidumps absents mais événements BugCheck 1001 présents	Option « Aucune » ou mauvaise cible dans Écriture des informations de débogage	Régler sur Petit vidage de mémoire (256 Ko), valider `%SystemRoot%\Minidump`
Crashs lors de copies lourdes ou sauvegardes	Pilote de stockage/filtre antivirus	Mettre à jour pilote de stockage, tester sans filtre temps réel, exclure le dossier Minidump

FAQ rapide

Faut‑il conserver les vieux dumps ? Gardez au moins les 3 à 5 derniers minidumps ; supprimez‑les ensuite si l’espace vient à manquer. Un seul MEMORY.DMP récent suffit le plus souvent.

Puis‑je déplacer le dossier des minidumps ? Oui, via le champ Répertoire du petit vidage de mémoire (ou MinidumpDir) — privilégiez un disque local rapide. Évitez un lecteur réseau.

BitLocker empêche‑t‑il l’écriture d’un dump ? Non en général, mais certains contextes d’entreprise ajoutent des filtres spécifiques. Assurez‑vous que la stratégie n’interdit pas explicitement les crash dumps.

Dois‑je envoyer le dump complet à un support ? Préférez un minidump en premier. N’envoyez un MEMORY.DMP que si demandé (il peut contenir des données sensibles en mémoire).

Récapitulatif opérationnel

Configurer Petit vidage de mémoire (256 Ko) vers %SystemRoot%\Minidump.
Garder un pagefile actif et suffisant sur C: (système géré recommandé).
Désactiver le redémarrage automatique pendant l’enquête.
Mettre à jour GPU/chipset/BIOS et retirer tout overclock.
Attendre la collecte à 100 %.
Analyser avec WinDbg (!analyze -v) et corréler via l’Observateur d’événements/le Moniteur de fiabilité.
Si aucun dump : vérifier stratégies, registre (CrashControl), service WER et espace disque.

Annexe : commandes utiles

Verification express via WMIC (encore présent sur de nombreuses installations)

wmic RecoverOS get AutoReboot,DebugInfoType,OverwriteExistingDebugFile,WriteDebugInfo

Afficher la quantité de RAM et le dimensionnement du pagefile

Get-CimInstance Win32_ComputerSystem | Select-Object @{n='RAM_GB';e={[math]::Round($_.TotalPhysicalMemory/1GB,2)}}
Get-CimInstance Win32_PageFileUsage | Select-Object Name, AllocatedBaseSize, PeakUsage

Lister les derniers événements BugCheck (ID 1001)

Get-WinEvent -FilterHashtable @{LogName='System'; ID=1001} -MaxEvents 10 |
  Select-Object TimeCreated, Id, ProviderName, Message

Conclusion

En réunissant configuration correcte (sysdm.cpl ou registre), prérequis (pagefile actif, espace disque) et discipline (attendre le 100 % de collecte), Windows 10 enregistre bien les minidumps et/ou MEMORY.DMP. Ces fichiers, associés à WinDbg et aux journaux système, permettent d’identifier précisément la cause des écrans bleus et d’appliquer le correctif le plus pertinent.