J'ai récemment commencé à voir cette ligne dans ma fenêtre de sortie Visual Studio 2005 lors du lancement de mon application:
FTH: (7156): *** Un shim de tas tolérant aux pannes a été appliqué au processus en cours. Cela est généralement dû à des accidents précédents. ***
J'ai essayé de désactiver le tas à tolérance de pannes en suivant les instructions ci-dessous:
http://msdn.Microsoft.com/en-us/library/dd744764(VS.85).aspx
J'utilise Windows 7 édition 64 bits. J'ai donc modifié les registres 32 bits et 64 bits et exécuté la commande "Rundll32.exe fthsvc.dll, FthSysprepSpecialize" à l'aide des commandes 32 bits et Versions 64 bits de Rundll32.exe.
Cependant, après le redémarrage, le tas à tolérance de pannes persiste lorsque je tente de déboguer mon application!
C'est un réel problème car il masque le bogue que je tente de reproduire et tue également les performances.
Quelqu'un a-t-il d'autres suggestions pour désactiver le tas à tolérance de pannes?
Définissez cette valeur de registre sur 0
: HKEY_LOCAL_MACHINE\Software\Microsoft\FTH\Enabled
Vous pouvez ajouter le nom de votre exécutable à ExclusionList.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\FTH\ExclusionList
Travaille pour moi.
Vous pouvez modifier le manifeste de l'application à exclure votre programme de PCA
voir aussi: Comment réinitialiser Program Compatibility Assistant pour les tests
"Rundll32.exe fthsvc.dll, FthSysprepSpecialize" cherche uniquement à effacer la liste des applications actuellement marquées. si votre application cause toujours des anomalies, la FTH doit quand même intervenir et prendre la relève.
comme déjà mentionné:
Définissez cette valeur de registre sur 0: HKEY_LOCAL_MACHINE\Software\Microsoft\FTH\Enabled
cela devrait désactiver FTH pour tout le système.
J'avais un problème similaire lors de l'exécution d'un test d'unité avec (Microsoft :: VisualStudio :: CppUnitTestFramework) . De manière ou d'autre, j'avais violé une allocation de segment de mémoire et la prochaine fois que j'ai essayé de déboguer, j'ai reçu le message suivant: "Un module d'interface tolérant aux pannes appliqué à processus en cours. Cela est généralement dû à des crashs précédents. "et l’environnement de débogage a gelé.
Pour que cela fonctionne à nouveau, je devais supprimer le cas de test, recompiler et l'ajouter à nouveau et recompiler, puis je pouvais définir un point d'arrêt et entrer dans le test.
Aussi couru dans cela. Renommer/supprimer AcXtrnal.dll dans Windows\AppPatch semble fonctionner pour moi. J'aime la façon dont cette action recommandée par Microsoft (ce que j'ai fait en premier) ne fait rien.
Je devais également renommer le fichier car les entrées de registre associées à cette clé étaient vides. Je m'attends à ce qu'ils peuplent si vous avez une application qui se comporte mal. Mais dans mon cas, je déboguais ma propre application dans Visual Studio. Donc, dans ce cas, c’était mon processus qui chargeait d’une manière ou d’une autre le FTH, que le service FTH fonctionne ou non. Et en fait, aucune des applications répertoriées auparavant comme ayant un comportement défectueux n’était répertoriée.
Mais je devais suivre ces instructions:
http://billroper.livejournal.com/960825.html
parce que cela ne me permettait pas de renommer le fichier tant que je n’étais pas devenu propriétaire et que j’avais le contrôle total.
vous pouvez effacer la liste des applications suivies par FTH sans arrêter ce service en procédant comme suit:
vous trouverez le fichier nommé opérationnel par un clic droit et choisissez clear log, Ensuite, vous pourrez exécuter votre programme à nouveau et le message d'avertissement disparaîtra.