2011-03-14 4 views
3

J'ai une application fonctionnant sur le framework .Net 4 et mon application exécute du code managé ET non managé. Dans le code non managé, les sockets UDP sont utilisés. Lorsque l'application est exécutée à partir de Visual Studio, tout va bien, mais quand il est exécuté seul, il se fige souvent. J'ai vu le comportement sur Windows XP SP3 et Windows 7 SP1. Lorsque j'attache le débogueur à l'application et l'arrête, je peux voir que beaucoup de threads sont bloqués à la même adresse mémoire dans ntdll.dll. Lors du démontage, la commande netdll.dll en cours d'exécution est "ret".Comment résoudre un blocage (ou un blocage) dans ntdll.dll?

Cela vous dit quelque chose?

Il semble qu'il y a déjà eu des problèmes similaires, comme rapporté ici, et il était lié à UDP: http://social.msdn.microsoft.com/Forums/en-US/netfxnetcom/thread/1b54b2f2-6e7c-405b-bdda-62197ac8a287 Aucune réponse n'a été jamais donné.

J'ai aussi trouvé un vieux correctif pour un problème similaire, mais selon Microsoft, il applique uniquement à Windows NT 4.

Toute aide serait appréciée.

+0

mode bloquant ou non bloquant? Codes d'erreur précédents? –

Répondre

3

Ce n'est pas le système d'exploitation qui provoque le blocage. Oui, votre trace de pile le montrera bloquant sur KiFastSystemCallRet() à l'intérieur de ntdll.dll. Avec la trace de la pile pointant vers l'instruction RET après SYSENTER. Mais il fait simplement ce que vous lui avez demandé de faire. Utilisez la fenêtre Debug + Windows + Threads pour voir ce que font vos threads. Le scénario de blocage classique est que l'un des threads a acquis l'objet de synchronisation et bloque. L'objet de synchronisation qu'un autre thread essaie d'acquérir. C'est l'un des maux de tête les plus courants.

+1

Je suis d'accord avec Hans - que cela fonctionne bien dans le débogueur aurait tendance à indiquer que certaines tâches sont sérialisées différemment (par exemple en effectuant une sortie de débogage) en évitant ce qui serait alors un blocage. – stephbu

+0

Merci pour votre aide! – Ssebu

+1

Le problème que j'ai est alors quand je regarde les traces de la pile, tout ce que je vois sont des appels dans les DLL Microsoft (avec la racine AND la pointe à la fois dans ntdll.dll), ce qui rend difficile de comprendre d'où il vient mon code. En outre, lors de la connexion au processus en cours, je dois joindre en utilisant l'option Native, car les piles d'appels ne sont pas en code managé. – Ssebu

Questions connexes