Paramètre GFlags pour intercepter la corruption de tas (autre que le tas de page)?

Sur un site de production, notre application (*) plante à plusieurs resockets, mais de manière non reproductible. L’parsing des kernel32!HeapFree montre clairement qu’il s’agit d’une corruption de tas: Les plantage sont à des emplacements différents, mais ils accèdent toujours aux violations à l’intérieur de kernel32!HeapFree / ntdll!RtlpLowFragHeapFree . Win Dbg !analyze -v Analysis !analyze -v signale également une corruption de tas.

Ce que nous avons essayé jusqu’à présent, c’est d’exécuter l’application avec l’option GFlags Page Heap . Le problème est que la surcharge de mémoire de Page Heap est telle que l’application ne fonctionnera plus (en atteignant la limite de mémoire virtuelle pour le processus 32 bits).

Donc, nous ne pouvons pas utiliser le tas de page . Quels autres drapeaux seraient utiles à append pour que nous

  • avoir un accident sur le site de corruption
  • ou au moins peut obtenir plus d’informations sur un vidage sur HeapFree qui sera éventuellement généré lorsque nous HeapFree dans HeapFree ?

Nous essayons actuellement les drapeaux:

  • Activer le marquage de tas
  • Activer la vérification de la queue du tas

dans l’espoir que le prochain crash dump contiendra plus d’informations sur ce qui a mal tourné.

J’ai considéré ces drapeaux, mais les ai laissés pour l’instant:

  • Activer la vérification des parameters du tas … Je m’attendrais à une certaine surcharge lorsque le système vérifie chaque fois qu’une fonction de tas est appelée
  • Activer la vérification gratuite du tas … ne sait pas si cela m’achèterait quelque chose
  • Activer la validation du tas sur appel … ici même les docs mettent en garde contre les frais généraux élevés

Un problème que j’ai (aussi) est que je ne suis pas certain de la manière dont ces drapeaux peuvent aider en cas de corruption de mémoire. Le tas de page va évidemment générer une violation d’access quand quelque chose écrit dans les pages de garde, mais comment fonctionnent les autres indicateurs?

Dois-je exécuter l’application avec Application Verifier pour ces autres indicateurs pour vous aider? Ou une exception sera-t-elle levée lorsque le code de vérification détecte quelque chose?

Quelle combinaison de ces indicateurs est la plus appropriée pour que l’application puisse toujours fonctionner avec des performances correctes et une consommation de mémoire en production?


(*): Il s’agit d’une application de bureau Windows 32 bits en automatisation indussortingelle. Fonctionnant sur Win7 64bit dans ce cas (ce qui convient parfaitement à de nombreux autres sites).

  1. À mon humble avis, le moyen le plus simple de contrôler toute cette vérification consiste à utiliser ApplicationVerifier. Vous avez une interface utilisateur parfaite et vous pouvez jouer avec tous les drapeaux.
  2. La vérification de tas gratuit est un bon indicateur sans trop de frais généraux. Donc, si un bloc de tas est mal modifié et que le bloc est libéré, vous obtenez une interruption dans le débogueur. Si la corruption se produit près de l’allocation et de la libération du bloc, cela pourrait aider.
  3. AFAIK “Heap parameter chechking” est juste une “validation de tas sur appel” légère. Je n’ai jamais eu de succès avec cela.
  4. La vérification et le marquage de la queue du tas sont faciles et rapides. Fonctionne parfois pour moi.

Vous savez que vous pouvez contrôler cela par application même avec gflags.

gflags.exe / i Testapp.exe e0

Mais: la meilleure façon de trouver de tels problèmes est d’utiliser complètement le Debug-CRT … si cela est possible pour vous. Donc, s’il y a une chance d’utiliser votre version de débogage dans l’environnement de production, faites-le. Dans le Debug-CRT, vous pouvez encore utiliser beaucoup de drapeaux ….

“Activer le tas de page” à partir de l’interface graphique de gflags permet une vérification complète du segment de mémoire, ce qui peut causer le problème que vous décrivez. La ligne de commande gflags vous donne plus de contrôle et vous permet d’activer la vérification de segment de page standard qui utilise moins de mémoire mais est moins puissante. La ligne de commande vous offre également la possibilité d’utiliser un mélange de standard et complet en utilisant les options / size, / dlls et / address.

Voici les options répertoriées dans le fichier d’aide debugger.chm:

 *To enable and configure page heap verification: gflags /p /enable ImageFile [ /full [/backwards] | /random Probability | /size SizeStart SizeEnd | /address AddressStart AddressEnd | /dlls DLL [DLL...] ] [/debug ["DebuggerCommand"] | /kdebug] [/unaligned] [/notraces] [/fault Rate [TimeOut]] [/leaks] [/protect] [/no_sync] [/no_lock_checks]*