Pourquoi les locals et les paramètres ne montrent aucune donnée sur le stackframe lors de l'utilisation de sos.dll pour déboguer l'application .net?

Mon application ..net 4 asp.net traite une requête, mais la requête est expirée, donc j'obtiens une sauvegarde et essaye de déboguer l'appli en ligne (révisée: il suffit d'analyser le fichier de vidage, pas d'attatch au processus live de l'application.). Je trouve un fil qui consomme la requête coûte 1 min 5 sec. Je passe la pile de ce fil. Je veux essayer de trouver les paramètres et les variables locales, mais la sortie de la commande ne montre aucune donnée, seules certaines variables locales ont une valeur. Puis-je savoir pourquoi cela est arrivé? la méthode 'FilterEntity' appelle 'Concat', la 'Concat' n'est pas retournée. Donc je suppose que les locaux de 'FilterEntity' doivent être là. Où ai-je tort?Pourquoi les locals et les paramètres ne montrent aucune donnée sur le stackframe lors de l'utilisation de sos.dll pour déboguer l'application .net?

J'ai le code source. Je sais que ce morceau de code est très lent car il y a une très grosse chaîne comme '... AEc3988sfdfJDelxn ...' à concaténer avec ',' répétitivement en boucle.

Je veux trouver la vraie grosse chaîne, la preuve de la cause profonde.

!clrstack -a: 

00000000741ebe10 000007feeffa1ff0 System.String.Concat(System.String, System.String, System.String) 
    PARAMETERS: 
     str0 = <no data> 
     str1 = <no data> 
     str2 = <no data> 
    LOCALS: 
     <no data> 
     <no data> 

00000000741ebed0 000007ff0080e918 Business.FilterDataProcess.FilterEntity(Request, Entity) 
    PARAMETERS: 
     Request = <no data> 
     Entity = <no data> 
    LOCALS: 
     <no data> 
     <no data> 
     <no data> 
     <no data> 
     <no data> 
     <no data> 
     <no data> 
     <no data> 
     <no data> 
     <no data> 
     <no data> 
     <no data> 
     <no data> 
     <no data> 
     <no data> 
     <no data> 
     <no data> 
     <no data> 
     <no data> 
     <no data> 
     <no data> 
     <no data> 
     0x00000000741ec160 = 0x000000078b27a018 
     <no data>

Source

2014-05-08 gfan

Vous déboguez une application en direct. Avez-vous une version de construction ou une version de débogage? Avez-vous des symboles pour votre propre code? –

c'est la version de construction. Je n'ai pas de symboles pour mon propre code. – gfan

Le problème est que vous déboguez du code optimisé. Dans ce cas, les informations de suivi des paramètres et des locales ne sont pas générées par la gigue. Pour désactiver l'optimisation afin de faciliter le débogage, consultez les rubriques suivantes: Making an Image Easier to Debug

Source

2014-05-08 14:27:14

Selon le lien, je sais que je peux ajouter un fichier 'MyApp.ini' pour générer des informations de suivi. mais Comment faire avec une application asp.net? Parce que c'est une application en ligne en direct, je peux seulement obtenir un vidage de l'OPS. Existe-t-il un moyen d'explorer le fichier de vidage pour trouver les locals ou les paramètres? – gfan

Oui. Utilisez votre connaissance des locals et des paramètres de la fonction et recherchez-les sur la pile en utilisant! Sos.dso ou! Sosex.mdso. –

Pourquoi les locals et les paramètres ne montrent aucune donnée sur le stackframe lors de l'utilisation de sos.dll pour déboguer l'application .net?

Répondre

Questions connexes