détection d’une impasse dans une application suspendue en C # à l’aide de windbg

Mon application multithread en C # 2.0 utilisant threadpool se bloque toutes les quelques semaines environ dans prod.

J’ai fait un sync

 ! syncblk

 Index SyncBlock MonitorHeld Récursion possédant des informations de fil SyncBlock Owner
   201 05b9493c 979 1 05bc1040 bcc 45 022f3490 System.Collections.ArrayList
  2875 05b4c914 1 1 17b99e10 1af8 290 024862d8 MyProg.MyChildClass
  3045 05b4dbec 1 1 17ca7e98 1990 664 02392120 MyProg.MyChildClass
  3046 05b4dc1c 1 1 17ca8668 1038 666 02394b00 MyProg.MyChildClass
  3194 05b4f80c 3 1 05b5b638 1594 31 02537b88 MyProg.MyChildClass 
  3072 05b4e114 1 1 17d660f0 1120 848 023dd578 MyProg.MyChildClass
  3073 05b4e144 1 1 17c45c30 1884 518 023dfc2c MyProg.MyChildClass 
  3390 05b51cfc 3 1 16cefcc0 1350 102 02768868 MyProg.MyChildClass
  3072 05b4e114 1 1 17d660f0 1120 848 023dd578 MyProg.MyChildClass
  3073 05b4e144 1 1 17c45c30 1884 518 023dfc2c MyProg.MyChildClass 

J’ai supprimé des centaines de lignes qui ressemblent à ceci:

 3073 05b4e144 1 1 17c45c30 1884 518 023dfc2c MyProg.MyChildClass 

Le thread contenant 979 moniteurs verrouille une liste de contrôle, mais tous les autres threads en attente essaient d’acquérir un lecteur dans un object différent.

Je sais quels verrous tous les lecteurs tentent d’acquérir, mais je ne sais pas qui détient ce verrou. Comment puis-je savoir cela ??

Tous les threads avec MonitorHeld = 1 ont les mêmes résultats que clrstack et dso. Voici les sorties dso et clrstack pour le thread contenant 979 verrous (id = 45) et les threads de lecteur en attente (id = 290). De même, quand je fais ~ * e! Clrstack tous les threads avec Monitor.Enter ont la même stack que le clrstack sur les 2 threads suivants

 0: 000> ~ 45e! Clrstack
 Identifiant du thread du système d'exploitation: 0xbcc (45)
 ESP EIP     
 17fbe590 77d2013d [GCFrame: 17fbe590] 
 17fbe6cc 77d2013d [HelperMethodFrame: 17fbe6cc] System.Threading.Monitor.Enter (System.Object)
 17fbe720 00638427 MyProg.MyParentClass.ClockTimeElapsed (System.DateTime)
 17fbe798 00637cf6 MyProg.MyEngine.ClockTimeElapsed (System.Object)
 17fbe830 71df843f System.Threading._TimerCallback.TimerCallback_Context (System.Object)
 17fbe838 71e302ff System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
 17fbe850 71df83ab System.Threading._TimerCallback.PerformTimerCallback (System.Object)
 17fbe9dc 74071b4c [GCFrame: 17fbe9dc] 
 0: 000> ~ 45e! Dso
 Identifiant du thread du système d'exploitation: 0xbcc (45)
 Nom de l'object ESP / REG
 17fbe5a8 022a2ff4 System.Globalization.DaylightTime
 17fbe5ac 022a2f3c System.Int32
 17fbe5c8 02537b88 MyProg.MyChildClass
 17fbe738 02537b88 MyProg.MyChildClass
 17fbe740 02537b88 MyProg.MyChildClass
 17fbe7ac 11572f28 System.Collections.ArrayList + ArrayListEnumeratorSimple
 17fbe7b0 022f3490 System.Collections.ArrayList
 17fbe7b4 0231860c System.Ssortingng Erreur lors du chargement de MyConfig.txt
 17fbe7c0 022f3014 MyProg.MyEngine
 17fbe84c 0231b48c System.Threading._TimerCallback
 17fbe9fc 0231b48c System.Threading._TimerCallback
 0: 000> ~ 290e! Clrstack
 Identifiant du thread du système d'exploitation: 0x1af8 (290)
 ESP EIP     
 2e77f39c 77d2013d [HelperMethodFrame_1OBJ: 2e77f39c] System.Threading.ReaderWriterLock.AcquireReaderLockInternal (Int32)
 2e77f3f8 0c3630d4 MyProg.MyEngine.GetBuyValue ()
 2e77f424 076fd4ad MyProg.MyParentClass.Execute (System.Object)
 2e77f474 71e19fcf System.Threading._ThreadPoolWaitCallback.WaitCallback_Context (System.Object)
 2e77f47c 71e302ff System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
 2e77f494 71e1a533 System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal (System.Threading._ThreadPoolWaitCallback)
 2e77f4a8 71e1a3c9 System.Threading._ThreadPoolWaitCallback.PerformWaitCallback (System.Object)
 2e77f638 74071b4c [GCFrame: 2e77f638] 
 0: 000> ~ 290e! Dso
 Identifiant du thread du système d'exploitation: 0x1af8 (290)
 Nom de l'object ESP / REG
 2e77f35c 022f3014 MyProg.MyEngine
 2e77f360 02369b98 System.Threading.ContextCallback
 2e77f378 02369b98 System.Threading.ContextCallback
 2e77f3dc 023188f8 System.Threading.ReaderWriterLock
 2e77f400 024862d8 MyProg.MyChildClass
 2e77f410 02369b98 System.Threading.ContextCallback
 2e77f430 024862d8 MyProg.MyChildClass
 2e77f43c 024862d8 MyProg.MyChildClass
 2e77f460 02369b98 System.Threading.ContextCallback
 2e77f490 1156dd74 System.Threading._ThreadPoolWaitCallback

Je pense que vous devriez essayer l’extension dll SOSEX écrite par ce gars, http://stevestechspot.com/ . Il existe une commande !dlk qui essaie de trouver des blocages et il a récemment ajouté de nouvelles commandes qui pourraient vous intéresser:

! mlocks – Répertorie tous les verrous gérés et les CriticalSections non gérés, ainsi que leur ID de thread propriétaire. ! mwaits – Répertorie tous les threads en attente et, s’il est possible de le déterminer, les objects verrouillés qu’ils attendent.