Qu'est-ce que LogHelp_TerminateOnAssert?

Question

Il y a une question similaire d'il y a une décennie, mais il n'y avait pas de bonne réponse - j'espère que les choses ont changé depuis lors.

J'ai une application Winforms assez multithread basée sur .NET 4.72. Je le regarde avec la vue Process Explorer Threads et il a beaucoup d' clr.dll!LogHelp_TerminateOnAssert+0x6835appels de type. J'ai configuré le chemin des symboles, mais cela n'a rien clarifié pour moi.

J'ai pris une décharge de l'application et l'ai exécutée via DebugDiag et WinDbg et je n'ai rien vu de suspect qui se démarque.

Donc mes questions:

• Dois-je m'inquiéter du grand nombre d'appels LogHelp_TerminateOnAssert?
• L'application perd-elle de la mémoire?
• Y a-t-il un nombre excessif d'exceptions qui ne filtrent pas lorsque j'exécute l'application dans Visual Studio?

La seule entrée de mon code ici est !get_FrameReceivedet la pile de ce thread est la suivante:

La pile pour le thread avec le plus de cycles est comme ceci:

Answer 1

Grands décalages

clr.dll!LogHelp_TerminateOnAssert+0x6835

signifie que l'exécution réelle dans cette méthode est à 0x6835 = 26661 octets de son début. Il est peu probable qu'une méthode soit aussi grande. (Comme le souligne @blabb, c'est une méthode à 1 octet).

Habituellement, vous voyez cela lorsque vous n'avez pas configuré correctement les symboles (comme dans la question d'origine liée), mais que vous avez résolu le problème.

Il est fort probable que Microsoft n'ait publié que les symboles publics clr.dllet non privés. Dans ce cas, vous ne verrez que la dernière méthode publique connue.

Adresse de départ

Veuillez noter que la colonne est nommée "Adresse de départ". Process Explorer affichera la première entrée de la pile.

C'est donc là que tout commence. Vous semblez préoccupé par le fait que c'est là que tout s'arrête.

Remarque: certaines méthodes internes connues comme RtlUserThreadStartet BaseThreadInitThunkseront ignorées lors de l'affichage de l'adresse de départ. Sinon, ils se ressembleraient probablement tous.

Ce que le thread fait vraiment est en haut de la liste, c'est ZwRemoveIoCompletion-à- dire qu'il semble faire des opérations d'E / S.

Vos questions

Dois-je m'inquiéter du grand nombre d'appels LogHelp_TerminateOnAssert?

Non, ce ne sont que le point de départ de quelque chose de bien. On GetQueuedCompletionStatus()dirait qu'il y a des E / S en cours et que .NET utilise les ports d'achèvement d'E / S (IOCP) pour vous.

L'application perd-elle de la mémoire?

Vous ne le dites pas en regardant les piles d'appels. Vous dites cela en regardant la mémoire au fil du temps.

Si vous avez trop d'E / S réseau et que le réseau ne peut pas suivre le rythme, .NET peut avoir de plus en plus d'éléments dans la file d'attente, ce qui peut ressembler à une fuite de mémoire.

Y a-t-il un nombre excessif d'exceptions qui ne filtrent pas lorsque j'exécute l'application dans Visual Studio?

Vous ne diriez pas non plus cela à partir de la pile d'appels. Vous attacheriez un débogueur (par exemple WinDbg) et vérifieriez les exceptions (comme sxe clr), si vous ne faites pas confiance à Visual Studio.

Answer 2

lors de la publication, toutes ces assertions sont compilées dans un simple ret quelque chose de similaire à

ifdef ( debug ) { function body here } elseif { ret } endif

donc les symboles avec un si grand décalage sont faux

vous devrez peut-être charger les symboles réels pour cette adresse pour une pile d'appels raisonnable

vous pouvez voir la taille de la fonction dans clr 4.0.30319 clr.dll est juste 1 octet

0:000> x /v /t clr!LogHelp_TerminateOnAssert
pub func   100115a0             0 <NoType> clr!LogHelp_TerminateOnAssert (<no parameter info>)
0:000> .fnent clr!LogHelp_TerminateOnAssert
Debugger function entry 01bad5e0 for:
(100115a0)   clr!RtlUnwindCallback   |  (100115a1)   clr!memset
Exact matches:
    clr!RtlUnwindCallback (void)
    clr!_TlgDefineProvider_annotation__Tlgg_hClrProviderProv (void)

OffStart:  000115a0
ProcSize:  0x1
Prologue:  0x0
Params:    0n0 (0x0 bytes)
Locals:    0n0 (0x0 bytes)
Registers: 0n0
0:000> u clr!LogHelp_TerminateOnAssert l1
clr!RtlUnwindCallback:
100115a0 c3              ret