Comment éviter "(null)" StackTrace dans DPH_BLOCK_INFORMATION?

Question

Je vais avoir un coup de pistolet sur une corruption de tas. J'ai activé la vérification standard tas avec

gflags /p /enable myprogram.exe 

ce qui réussit à confirmer la corruption:

=========================================================== 
VERIFIER STOP 00000008: pid 0x1040: corrupted suffix pattern 

    10C61000 : Heap handle 
    19BE0CF8 : Heap block 
    00000010 : Block size 
    00000000 : 
===========================================================

Quand je tourne sur la vérification des tas pleine page (gflags /p /enable myprogram.exe /full) en prévision que cela entraînera une erreur se produire au moment où la corruption est introduite, je ne reçois rien de plus.

J'ai commencé à espérer en lisant Advanced Windows Debugging: Memory Corruption Part II—Heaps, qui est un chapitre de . J'ai installé WinDbg, et téléchargé les symboles de débogage pour user32.dll, kernel32.dll, ntdll.dll selon http://support.microsoft.com/kb/311503. Maintenant, lorsque le programme se termine dans le débogueur je peux utiliser cette commande pour afficher les informations sur la page tas:

0:000> dt _DPH_BLOCK_INFORMATION 19BE0CF8-0x20 
ntdll!_DPH_BLOCK_INFORMATION 
    +0x000 StartStamp  : 0xabcdaaaa 
    +0x004 Heap    : 0x90c61000 
    +0x008 RequestedSize : 0x10 
    +0x00c ActualSize  : 0x38 
    +0x010 FreeQueue  : _LIST_ENTRY [ 0x0 - 0x0 ] 
    +0x010 TraceIndex  : 0 
    +0x018 StackTrace  : (null) 
    +0x01c EndStamp   : 0xdcbaaaaa

Je suis consterné par la trace de la pile (null). Maintenant, http://msdn.microsoft.com/en-us/library/ms220938%28VS.80%29.aspx dit:

Le champ StackTrace ne contiendra pas toujours une valeur non nulle pour diverses raisons. Tout d'abord, la détection de trace de pile est prise en charge uniquement sur les plates-formes x86 et, en second lieu, même sur les machines x86, les algorithmes de détection de trace de pile ne sont pas totalement fiables. Si le bloc est un bloc alloué, la trace de la pile est pour le moment d'allocation. Si le bloc a été libéré, la trace de la pile est pour le moment libre.

Mais je me demande si quelqu'un a des idées sur l'augmentation des chances de voir la trace de la pile à partir du moment d'allocation.

Merci d'avoir lu!

Answer 1

Ah ah! S'avère que je avais besoin pour permettre à plus d'options gflags:

gflags /i myprogram.exe +ust

qui a cet effet:

ust - Create user mode stack trace database

semble simple quand je vois la description des paramètres. Que je suis bête. Mais il me semble aussi nécessaire de définir la taille de la base de données de trace avant qu'elle ne prendra effet:

gflags /i myprogram.exe /tracedb 512

... ou quoi (en Mo).

Answer 2

Selon Microsoft, la fonction malloc dans le module C run-time (CRT) utilise l'omission de pointeur de trame (FPO) dans certaines versions de Windows. Vous ne pouvez pas voir les informations complètes sur la pile de la fonction malloc. (http://support.microsoft.com/kb/268343)

Si possible, essayez de lier la version de débogage CRT, par exemple. lien avec l'option/MDd, pour résoudre ce problème.