Lorsqu'une application se bloque sur Windows et qu'un débogueur tel que Visual Studio est installé, la boîte de dialogue modale suivante apparaît:
[Titre: Microsoft Windows]
X a cessé de fonctionner
Un problème a empêché le programme de fonctionner correctement. Windows fermera le programme et vous avertira si une solution est disponible.
[Débogage] [Fermer l'application]
Existe-t-il un moyen de désactiver cette boîte de dialogue? Autrement dit, le programme vient-il de planter et de graver en silence?
Mon scénario est que je voudrais exécuter plusieurs tests automatisés, dont certains se bloqueront en raison de bogues dans l'application en cours de test. Je ne veux pas que ces boîtes de dialogue bloquent l'exécution de l'automatisation.
En cherchant, je pense avoir trouvé la solution pour la désactiver sur Windows XP, qui nuque cette clé de Registre:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
Cependant, cela ne fonctionnait pas sur Windows Vista.
Pour forcer le rapport d'erreurs Windows (WER) à effectuer un vidage sur incident et à fermer l'application, au lieu de vous inviter à déboguer le programme, vous pouvez définir ces entrées de registre:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting]
"ForceQueue"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\Consent]
"DefaultConsent"=dword:00000001
Une fois cela défini, lorsque vos applications se bloquent, vous devriez voir les fichiers * .hdmp et * .mdmp dans:
%ALLUSERSPROFILE%\Microsoft\Windows\WER\
Vois ici:
http://msdn.Microsoft.com/en-us/library/bb513638.aspx
regedit
DWORD HKLM ou HKCU\Software\Microsoft\Windows\Windows Error Reporting\DontShowUI = "1"
fera rapporter WER en silence. Ensuite, vous pouvez définir
DWORD HKLM ou HKCU\Software\Microsoft\Windows\Windows Error Reporting\Disabled = "1"
pour l'empêcher de parler à MS.
Je ne sais pas si cela se réfère exactement au même dialogue, mais voici une approche alternative de Raymond Chen :
DWORD dwMode = SetErrorMode(SEM_NOGPFAULTERRORBOX);
SetErrorMode(dwMode | SEM_NOGPFAULTERRORBOX);
J'ai dû désactiver cela pour le travail d'automatisation des versions sur Windows 64 bits pour Firefox et j'ai fait ce qui suit:
C'est similaire à ce qui a été accompli pour les rapports d'expérience client dans: http://www.blogsdna.com/2137/fix-windows-installer-Explorer-update-has-stopped-working-in-windows-7. htm
Dans mon contexte, je souhaite uniquement supprimer la fenêtre contextuelle pour mes tests unitaires et non pour l'ensemble du système. J'ai constaté qu'une combinaison de fonctions est nécessaire pour supprimer ces erreurs, telles que la capture d'exceptions non gérées, la suppression des vérifications d'exécution (telles que la validité du pointeur de pile) et les indicateurs de mode d'erreur. Voici ce que j'ai utilisé avec un certain succès:
#include <windows.h>
#include <rtcapi.h>
int exception_handler(LPEXCEPTION_POINTERS p)
{
printf("Exception detected during the unit tests!\n");
exit(1);
}
int runtime_check_handler(int errorType, const char *filename, int linenumber, const char *moduleName, const char *format, ...)
{
printf("Error type %d at %s line %d in %s", errorType, filename, linenumber, moduleName);
exit(1);
}
int main()
{
DWORD dwMode = SetErrorMode(SEM_NOGPFAULTERRORBOX);
SetErrorMode(dwMode | SEM_NOGPFAULTERRORBOX);
SetUnhandledExceptionFilter((LPTOP_LEVEL_EXCEPTION_FILTER)&exception_handler);
_RTC_SetErrorFunc(&runtime_check_handler);
// Run your tests here
return 0;
}
Dans l'application WPF
[DllImport("kernel32.dll", SetLastError = true)]
static extern int SetErrorMode(int wMode);
[DllImport("kernel32.dll")]
static extern FilterDelegate SetUnhandledExceptionFilter(FilterDelegate lpTopLevelExceptionFilter);
public delegate bool FilterDelegate(Exception ex);
public static void DisableChashReport()
{
FilterDelegate fd = delegate(Exception ex)
{
return true;
};
SetUnhandledExceptionFilter(fd);
SetErrorMode(SetErrorMode(0) | 0x0002 );
}
Ce n'est pas une réponse directe à la question car il s'agit d'une solution de contournement et la question est de savoir comment désactiver cette fonctionnalité, mais dans mon cas, je suis un utilisateur sur un serveur avec des autorisations limitées et je ne peux pas désactiver la fonctionnalité à l'aide de l'un des les autres réponses. Donc, j'avais besoin d'une solution de contournement. Cela fonctionnera probablement pour au moins quelques autres qui se retrouvent sur cette question.
J'ai utilisé autohotkey portable et créé une macro qui vérifie une fois par minute si la boîte contextuelle existe, et si c'est le cas, clique sur le bouton pour fermer le programme. Dans mon cas, cela suffit et laisse la fonctionnalité activée pour les autres utilisateurs. Cela nécessite que je démarre le script lorsque j'exécute le programme à risque, mais cela fonctionne pour mes besoins.
Le script est le suivant:
sleep_duration = 60000 ; how often to check, in milliseconds.
; 60000 is a full minute
Loop
{
IfWinExist, ahk_class #32770 ; use autohotkey's window spy to confirm that
; ahk_class #32770 is it for you. This seemed to be consistent
; across all errors like this on Windows Server 2008
{
ControlClick, Button2, ahk_class #32770 ; sends the click.
; Button2 is the control name and then the following
; is that window name again
}
Sleep, sleep_duration ; wait for the time set above
}
modifier: Un indicateur rapide. Lorsque d'autres choses sont en place, cela semble essayer d'activer les contrôles dans la fenêtre de premier plan - il est censé l'envoyer au programme en arrière-plan. Si je trouve un correctif, je modifierai cette réponse pour la refléter, mais pour l'instant, soyez prudent lorsque vous l'utilisez et essayez d'effectuer d'autres travaux sur une machine en même temps.
Vous devez implémenter un filtre d'exception non géré qui quitte simplement votre application, puis définissez cette fonction de filtre avec SetUnhandledExceptionFilter () .
Si vous utilisez le CRT sécurisé, vous devez également fournir votre propre gestionnaire de paramètres non valide et le définir avec _ set_invalid_parameter_handler ().
Cet article de blog contient également des informations: http://blog.kalmbachnet.de/?postid=75
Pendant le test, vous pouvez exécuter un `` débogueur '' comme ADPlus attaché qui peut être configuré de nombreuses façons utiles pour collecter des données (minidumps) sur les erreurs et éviter les problèmes de dialogue modal que vous énoncez ci-dessus.
Si vous souhaitez obtenir des informations utiles lorsque votre application se bloque en production, vous pouvez configurer Rapport d'erreurs Microsoft pour obtenir quelque chose de similaire aux données ADPlus.
Après avoir essayé tout le reste sur Internet pour se débarrasser du débogueur juste à temps, j'ai trouvé un moyen simple qui fonctionnait et j'espère aider quelqu'un d'autre.
Accédez au Panneau de configuration Accédez aux outils d'administration Accédez aux services Recherchez dans la liste pour Machine Debug Manager Faites un clic droit dessus et cliquez sur Propriétés Sous l'onglet Général, recherchez Type de démarrage Cliquez sur Désactiver. Cliquez sur Appliquer et OK.
Je n'ai pas vu le message du débogueur depuis et mon ordinateur fonctionne parfaitement.
Au lieu de modifier les valeurs dans le registre, vous pouvez désactiver complètement le rapport d'erreurs sur Windows Server 2008 R2, Windows Server 2012 et Windows 8 avec: serverWerOptin /disable
https://technet.Microsoft.com/en-us/library/hh875648 (v = ws.11) .aspx