एक मुश्किल विंडोज सेवा स्टार्टअप gremlin

Question

डीबग करने के विचारों की तलाश पिछले कुछ महीनों में मुझे हमारी सेवाओं में से एक के बारे में क्यूए से कुछ रिपोर्ट प्राप्त हुई हैं। WinDbg का उपयोग करके एक हैंग डंप की जांच करने पर, हर बार जब मैंने एक ही चीज़ खोज ली: लोडर लॉक महत्वपूर्ण खंड लॉक है लेकिन थ्रेड का मालिक कहीं भी नहीं मिला है। चूंकि धागा चला गया है और एकमात्र ट्रेस जिसे मैं देख सकता हूं वह एक वैश्विक महत्वपूर्ण खंड है जो पीछे छोड़ दिया गया है, मुझे नहीं पता कि थ्रेड थ्रेड पर कौन सा कोड चल रहा था, या यहां तक ​​कि डीएलएल जो थ्रेड आया था, यह भी एक हो सकता है हमारा (यानी तृतीय पक्ष विक्रेता)।

यह समस्या बहुत ही छिड़काव है, केवल पिछले 6 महीनों में यह जंगली में स्वाभाविक रूप से होने वाले 3-4 बार देखा जाता है। अन्य सभी बार, सेवा पूरी तरह से चलती है। तो यह मुझे विश्वास दिलाता है कि यह किसी प्रकार का समय/दौड़ की स्थिति है।

हाल ही में, मैंने इसे अपने आप को समझने के लिए इसे लेने का फैसला किया है। मैं WinTask स्क्रिप्ट के साथ एक मशीन सेटअप करता हूं जो लगातार सेवा शुरू/बंद करता है। अच्छी खबर यह है कि 5-6 घंटे के भीतर मैं समस्या का पुनरुत्पादन कर सकता हूं।

अब अगले भाग के लिए: मैं इसे अलग कैसे कर सकता हूं?

1. इस्तेमाल किया "डिबगर" gflags छवि सेटिंग्स में क्षेत्र स्वतः CDB के तहत सेवा को चलाने के लिए जब भी यह शुरू होता है:

   यह वही है मैं अब तक की कोशिश की है है। अब तक यह दो दिनों तक चल रहा है और कभी नहीं लटका है, इसलिए मैं सोच रहा हूं कि डीबगर ने इस मुद्दे को अदृश्य बनाने के लिए पर्याप्त समय परिवर्तन किया है।

2. डाउनलोड किए गए एप्लिकेशन सत्यापनकर्ता और उस के साथ चलाने के लिए प्रक्रिया को कॉन्फ़िगर किया गया। एक पूरी तरह से असंबंधित बग मिला जहां हम CComBSTR अस्थायी चर बनाते हैं, इसे एक वैरिएंट को असाइन करते हैं और संस्करण को एक फ़ंक्शन कॉल में पास करते हैं, भले ही CCOMBSTR ने उस बिंदु से आवंटित स्ट्रिंग को लंबे समय तक हटा दिया हो। विश्वास न करें कि यह बग संबंधित है क्योंकि स्ट्रिंग केवल पढ़ने के लिए है और जिस धागे पर चल रहा है वह वह नहीं है जो मर रहा है।

यदि आप लोग ऐसा कुछ सोच सकते हैं जो मैं विचार नहीं कर रहा हूं तो मैं यह पोस्ट कर रहा हूं।

हालांकि मैं एक विंडोज़ उपयोगिता थी जो कृत्रिम रूप से सीपीयू पर लोड डालती थी और दौड़ की स्थिति को पॉप अप करने के लिए अन्य चीजें करता था और मैंने सोचा कि एप्लिकेशन सत्यापनकर्ता ने ऐसी चीज की है, लेकिन स्पष्ट रूप से ऐसा नहीं है। क्या कोई जानता है कि मैं क्या ले रहा हूं, या क्या मैंने बस इसे सपना देखा?

जब तक सप्ताहांत में कुछ नहीं होता है तो मेरा अगला कदम सभी डिबगर्स को अक्षम करना होगा, स्टॉक पर वापस जाना होगा और THREAD_ATTACH/THREAD_DETACH ईवेंट रिकॉर्ड करने के लिए डेलमेन में से एक को हैक करना होगा। कम से कम मैं उस थ्रेड को रोक सकता हूं जो इसे बनने पर मर रहा है। वह कुछ प्रकाश डाल सकता है।

Answer 1

कुछ मैं कोशिश कर सकता हूं कि एक कर्नेल डीबगर संलग्न कर रहा है, फिर प्रक्रिया को एपिलेशन सत्यापन के तहत चलाएं। एवी में डीएलएल को उतारने के लिए जांच होती है, जबकि इसमें सीएस होता है और थ्रेड को समाप्त करता है जो अभी भी सीएस धारण करता है। तो उन ब्रेकपॉइंट्स को कर्नेल डीबगर में ट्रिगर करना चाहिए और फिर उम्मीद है कि आप इसे इस अधिनियम में पकड़ सकते हैं। केडी के तहत इसे चलाने से उम्मीद है कि उपयोगकर्ता-मोड डीबगर की तरह इसे धीमा नहीं किया जाएगा।

Answer 2

कुछ यादृच्छिक विचार: यदि डीबगर संलग्न करना मदद नहीं करता है, तो उपकरण (आपका अंतिम बिंदु) अगला चरण है। लेकिन पूरी प्रक्रिया को कम किए बिना धागा कैसे मर सकता है, क्या आप कहीं अपवाद पकड़ रहे हैं? आप वहां भी लॉगिंग करना चाहेंगे। यदि आप मदद करते हैं तो आप सभी प्रथम-अवसर अपवादों को तोड़ने के लिए WinDbg भी सेट कर सकते हैं। WinDbg आउटपुट विंडो पहले-मौके अपवादों को दिखाएगी, भले ही आप ब्रेक न करें।

Answer 3

मैं एक गैर-आक्रामक डीबगर कोशिश करता हूं, और देखता हूं कि यह कैसे चलता है, जबकि आप प्रक्रिया को रोकने में सक्षम नहीं होंगे, आप किसी भी डिबगिंग संदेश के साथ-साथ किसी भी थ्रेड को शुरू और बंद करने में सक्षम होना चाहिए, और यह प्रक्रिया प्रदर्शन पर कम से कम प्रभाव होना चाहिए। मैं आमतौर पर अपने डीबगिंग के लिए विंडबग का उपयोग करता हूं, लेकिन मुझे लगता है कि सीडीआई के पास भी इसी तरह के विकल्प हैं। इससे आपको यह देखने की संभावना है कि प्रक्रिया में क्या हो रहा है, और कम से कम इसे कम करने में मदद करना शुरू करें। एक चीज जो आप करना चाहते हैं, यह सुनिश्चित करने के लिए आउटपुट (.logopen में windbg) को रीडायरेक्ट करना है ताकि यह सुनिश्चित किया जा सके कि आपके बफर के बाहर कुछ भी नहीं है।

Answer 4

तो पता चला कि मैं समाधान के करीब था, मुझे एहसास हुआ। सीडीबी के तहत चल रही सेवा के साथ, जिसने समय बदल दिया और फिर इसे एप्लिकेशन सत्यापनकर्ता के साथ चलाया, जिसने समय को और भी बदल दिया (पृष्ठ ढेर सक्षम आवंटन धीमा कर देता है), गुप्त घटक जो मैं खो रहा था वह prim95.exe था। सामान्य सामान्य प्राथमिकता पर prime95.exe चल रहा है, वास्तव में जो कुछ भी मैं बदलने की कोशिश नहीं कर रहा था, उसे खराब कर दिया, लेकिन यह समस्या 15 मिनट से कम में दिखाई दे रही है।

कारण:

हार्डवेयर बोर्डों से डेटा प्राप्त करने के लिए 3 पार्टी एसडीके। जब हमारी सेवा शुरू होती है, तो हम उनकी क्षमताओं के लिए अलग-अलग कैप्चर घटकों से पूछेंगे। पूछताछ के बाद, हम घटक उदाहरण जारी करते हैं। जाहिर है, इस एक डीएलएल ने एक अलग थ्रेड शुरू किया, जिसने लोडर लॉक हासिल किया और फिर उस थ्रेड में प्रारंभिकता का एक गुच्छा करने लगा। यदि उस समय के दौरान, हमारी क्षमता क्वेरी पूरी हो गई और हमने घटक जारी किया, तो उनका कोड टर्मिनट थ्रेड() को इस अन्य थ्रेड पर कॉलर लॉक को स्थायी रूप से लॉक कर देगा। Prime95 नीचे सब कुछ धीमा बस मुझे इस रेस स्थिति को पकड़ने और पाने के लिए निम्नलिखित सत्यापनकर्ता रोक संदेश पर्याप्त:

======================================= 
VERIFIER STOP 00000200: pid 0x1A8C: Thread cannot own a critical section. 

0000091C : Thread ID. 
77E17340 : Critical section address. 
00000000 : Critical section debug information address. 
00000000 : Critical section initialization stack trace. 

अजीब हिस्सा था कि इस धागे किसी भी प्रकार की कोई भी बिना किसी अपवाद के "गायब" है, इसलिए डिबगर नहीं होगा यहां तक ​​कि पहले मौका भी पकड़ो। TerminateThread का उपयोग कौन करता है ????

धन्यवाद, सुझाव और समर्थन के लिए सभी। मैं वास्तव में एक सीरियल केबल खरीदने के लिए दोपहर के भोजन के दौरान रेडियोशैक में ड्राइविंग करने और फिर केडी के साथ खेलने में कुछ दिन बिता रहा था। ऐसा लगता है कि अगली बार तक इंतजार करना होगा :)