101

विज़ुअल स्टूडियो 2010 में, मेरे पास कई यूनिट टेस्ट हैं। जब मैं परीक्षण सूचियों का उपयोग करके एक बार में कई परीक्षण चलाता हूं, तो मैं कभी-कभी एक या अधिक परीक्षणों के लिए निम्न त्रुटि का पुन: प्रयास करता हूं:

परीक्षण चलने के दौरान एजेंट प्रक्रिया को रोक दिया गया था।

यह कभी भी एक ही परीक्षा विफल नहीं होती है, और अगर मैं फिर से परीक्षण चलाने की कोशिश करता हूं, तो यह सफल होता है।

मुझे यह बग रिपोर्ट कनेक्ट पर मिली , जो एक ही समस्या प्रतीत होती है, लेकिन यह एक समाधान प्रदान नहीं करती है।

क्या किसी और ने भी इस व्यवहार को देखा है? मैं इससे कैसे बच सकता हूं?

संपादित करें

मैं अभी भी इस बग का अनुभव कर रहा हूं, और मेरे कई सहयोगी एक ही सॉफ्टवेयर / हार्डवेयर सेटअप पर हैं। मैंने अब तक उत्तरों का मूल्यांकन किया है, लेकिन वे समस्या का समाधान नहीं करते हैं। मैं इस समस्या के समाधान के लिए एक इनाम शुरू कर रहा हूं।

— driis
स्रोत

मुझे एक ही चीज मिल रही है। मैं इसमें खुदाई कर रहा हूं, लेकिन अब तक कोई समाधान नहीं

— मार्क

इस पर कोई भी समाचार? यहाँ एक ही समस्या ...

— पीटर Gfader

@Peter, स्वीकृत उत्तर के नीचे मेरी टिप्पणी देखें। यह मेरा समाधान था, लेकिन मुझे नहीं पता कि आपकी समस्या समान है।

— driis

एक अनकहे अपवाद के साथ मेरा भी यही व्यवहार था। अपवाद मेरे लिए दिखाई दे रहा था क्योंकि मैं बिल्ड सर्वर पर विजुअल स्टूडियो चलाता हूं और मुझे एक एस्टर-विंडो मिली। परख खिड़की के कारण परीक्षण नहीं चल सका।

41

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

अभी मुझे नहीं पता कि इसे कैसे पार किया जाए।

— satorg
स्रोत

16

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

— driis

6

मेरे पास मेरे कोड में कोई भी फाइनल / विध्वंसक नहीं है ... ~ MyClass () और उसी त्रुटि को प्राप्त करें।

— रेसफेर के

6

फ़ाइनलीज़ में अनियोजित अपवादों के साथ समस्या पृष्ठभूमि कार्यों में अनियोजित अपवादों का एक विशेष मामला है जिसे कुछ परीक्षण द्वारा शुरू किया जा सकता है या शेड्यूल किया जा सकता है (शायद अंतर्निहित) और परीक्षण पूरा होने पर भी निष्पादित करना जारी रख सकता है।

— सटोरग

1

पीटर के रूप में भी, रेस्परर टेस्ट धावक मुझे सभी को हरा देता है। वीएस 2010 टेस्ट धावक विध्वंसक के साथ कक्षा में विफल रहता है।

— RyBolt

1

मैंने गलती से अपने डिस्पोज़ () विधि में एक अनंत पुनरावर्ती लूप को कोडित कर दिया था, जिससे यह भी हुआ।

— रॉबर्ट

88

यह संदेश निष्पादित थ्रेड से भिन्न थ्रेड पर अपवाद के कारण होता है । अब तक के सभी उत्तर इस सरल व्याख्या को उबालते हैं। यह दृश्य स्टूडियो में एक ज्ञात बग है जो उस मामले में कोई भी समझदार जानकारी प्रदर्शित नहीं करता है।

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

— mafu
स्रोत

मेरे लिए भी यही बात थी - मेरा परीक्षण एक अलग सूत्र को जन्म दे रहा था, जिसका अपवाद मिल रहा था। थ्रेड के अंदर अपवाद को पकड़ने से कम से कम मुझे इसे प्रिंट करने और यह जानने की अनुमति मिलती है कि क्या हो रहा है। हालांकि सावधान रहें कि Assert.Fail () को थ्रेड के पकड़ ब्लॉक में न रखें - जो एक अलग अपवाद को उठाता है जो आपको ठीक वही जगह डालता है जहां आपने शुरू किया था।

— काइल क्रुल

4

मेरे लिए एक ही बात, एक ढेर अतिप्रवाह को छोड़कर, जो कि जावा की तुलना में सी # में नीचे ट्रैक करने के लिए बहुत कठिन हैं ...

— जॉन गार्डनर

वास्तव में, मैंने देखा कि जब मैंने थ्रेड ऑब्जेक्ट्स का उपयोग करना शुरू किया और उन्हें रोकने के लिए एबॉर्ट () को कॉल किया।

— espaciomore

1

यह तब भी होता है जब async voidपरीक्षण के दौरान कहा जाने वाला एक तरीका अपवाद को फेंक देता है

— मैथियास बीचर

1

ध्यान दें कि ट्रक्स में त्रुटि की जानकारी हो सकती है, आप इसे या तो टेक्स्ट एडिटर में खोलकर या विजुअल स्टूडियो में देख सकते हैं और टेस्ट रिजल्ट विंडो में टेस्ट रन एरर हाइपरलिंक पर क्लिक कर सकते हैं।

— ओहद श्नाइडर

16

मुझे यह समस्या हो रही थी, और यह मेरे कोड में एक समस्या थी जो टेस्ट फ्रेमवर्क ठीक से नहीं पकड़ रही थी। थोड़ा आकस्मिक प्रतिशोध ने मुझे इस कोड के साथ छोड़ दिया था:

public void GetThingy()
{
    this.GetThingy();
}

यह निश्चित रूप से एक अनंत पुनरावृत्ति है, और एक StackOverflowException (मुझे लगता है) का कारण बना। इसके कारण जो कुछ हुआ वह खतरनाक था: "जब परीक्षण चल रहा था तब एजेंट प्रक्रिया को रोक दिया गया था।"

एक त्वरित कोड निरीक्षण ने मुझे समस्या दिखाई, और मेरे परीक्षण अब ठीक चल रहे हैं। उम्मीद है कि यह मदद करता है - मुद्दों की तलाश में कोड का निरीक्षण करने या शायद एक सांत्वना ऐप में थोड़ा सा निकालने और वहां ठीक से काम करने की जांच करने के लायक हो सकता है।

— साइमन स्टील
स्रोत

3

यह मुद्दा नहीं है (मुझे पता है क्योंकि यह अलग-अलग परीक्षण है जो हर बार विफल होते हैं), लेकिन जवाब देने के लिए समय निकालने के लिए धन्यवाद।

— ट्राईस

6

+1 क्योंकि यह इस समस्या के लिए कई मान्य उत्तरों में से एक है। मेरी कक्षाओं में से एक पर एक sstatic पद्धति में एक SO अपवाद इस समस्या का कारण बना।

— पीटर टी। लाकॉम्ब जूनियर

6

+1, मैंने इसे भी देखा है। परीक्षण (वीएस 11 में) डिबगिंग समस्या को बहुत जल्दी ढूंढता है।

— जेरेमी मैक्गी

जेरेमी से सहमत हैं। यदि आप इकाई परीक्षणों को डिबग करते हैं तो यह बंद हो जाना चाहिए जहां अपवाद फेंक दिया गया है। हालाँकि अगर आप सिर्फ यूनिट परीक्षण चलाते हैं तो वे सभी हरे रंग की रोशनी के साथ आएंगे। बहुत विचित्र।

— एंड्रयू स्टीफंस

8

मैं परीक्षा परिणाम फ़ाइल (/TestResults/*.trx) को देखकर अपनी समस्या का स्रोत खोजने में सक्षम था। इसने पृष्ठभूमि थ्रेड में होने वाले अपवाद का पूरा विवरण प्रदान किया, और एक बार मैंने उस अपवाद को हल कर दिया "एजेंट संसाधित" रोका ... "त्रुटि दूर हो गई।

मेरे मामले में मैं अनायास ही अपने यूनिट टेस्ट में GUI लॉन्च कर रहा था, जो अंततः System.ComponentModel.InvalidAsynchronousStateException को फेंकने का कारण बना।

तो मेरी .trx फ़ाइल में समाहित:

   <RunInfo computerName="DT-1202" outcome="Error" timestamp="2013-07-29T13:52:11.2647907-04:00">
    <Text>One of the background threads threw exception: 
System.ComponentModel.InvalidAsynchronousStateException: An error occurred invoking the method.  The destination thread no longer exists.
at System.Windows.Forms.Control.WaitForWaitHandle(WaitHandle waitHandle)
at System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object[] args, Boolean synchronous)
at System.Windows.Forms.Control.Invoke(Delegate method, Object[] args)
at System.Windows.Forms.Control.Invoke(Delegate method)
...
</Text>
  </RunInfo>

इसने कोई भी जानकारी नहीं दी कि किस परीक्षा में त्रुटि हुई, लेकिन इसने मुझे दिखाया कि अपवाद कहां था, जो बहुत उपयोगी था।

— डेनिस स्किडमोर
स्रोत

5

यह संदेश आम तौर पर उत्पन्न होती है जब परीक्षण प्रक्रिया दुर्घटनाओं और हो सकता है जब वहाँ एक पृष्ठभूमि धागे पर एक बिना क्रिया अपवाद नहीं है, एक ढेर अतिप्रवाह होता है, या करने के लिए एक स्पष्ट कॉल Process.GetCurrentProcess().Kill()या Environment.Exit। एक अन्य संभावित कारण अप्रबंधित कोड में एक पहुंच उल्लंघन है।

किसी ने कुछ भी उल्लेख नहीं किया है कि इवेंट लॉग में अतिरिक्त जानकारी हो सकती है। आमतौर पर आपको इस बारे में अधिक जानकारी नहीं मिलेगी कि परीक्षण परिणामों में क्यों दुर्घटनाग्रस्त हो गया, हालांकि एक पृष्ठभूमि थ्रेड पर एक अनहेल्ड अपवाद की स्थिति में, फिर परीक्षण ढांचा स्रोत VSTTExecution के साथ एप्लिकेशन ईवेंट लॉग में विवरण लिखता है। यदि इवेंट लॉग में कोई जानकारी नहीं लिखी गई है, तो संभवतः ऊपर सूचीबद्ध अन्य कारणों में से एक है।

— माइक जोबरे
स्रोत

4

मेरे मामले में आउटपुट विंडो की जाँच करके समाधान निकाला गया था ।

'QTAgent32.exe' (प्रबंधित (v4.0.30319)): 'C: \ TestResults \ bdewey_XXXXXX072 2011-01-11 17_00_40 \ Out \ MyCode.dll', सिंबल लोड किए गए। E, 9024, 9, 2011/01/11, 17: 00: 46.827, XXXXX072 \ QTAgent32.exe, अनचाहे अपवाद पकड़ा गया, वाटसन के माध्यम से रिपोर्टिंग: [अपवाद संदेश]

मेरे मामले में मेरे पास एक FileSystemWatcher था जो एक अलग थ्रेड पर एक त्रुटि फेंक रहा था।

— bendewey
स्रोत

आपने इसे कैसे ठीक किया? मैं एम $ से कुछ सैंपल कोड का उपयोग कर रहा हूं जो कि फाइलसेविटवेयर को एक सेवा में लपेटता है और उसी के आसपास एक डब्ल्यूएफ वर्कफ़्लो बनाता है। मुझे इनमें से बहुत कुछ मिल रहा है ...

— ekkis

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

— क्वर्टी

3

मैंने उसी समस्या का सामना किया और इसे हटाते समय हल किया

Environment.Exit(0);

इसलिए मुझे पूरा यकीन है, कि परीक्षण के दौरान आपके परीक्षण या विधि के दौरान यह त्रुटि होती है, निष्पादन प्रक्रिया को समाप्त करने का कारण बनती है।

— गोन
स्रोत

2

सवाल पोस्ट करने के लिए धन्यवाद। मैं बस इस समस्या में भाग गया और एक कारण पता लगा कि आप में भाग रहा हो सकता है।

एक अतुल्यकालिक अपवाद हो सकता है

अपने परीक्षण सेटअप के दौरान, मैं एक ऑब्जेक्ट बनाता हूं जो थ्रेड पूल में एक श्रमिक थ्रेड को कतार में रखता है। अगर मैं डिबगिंग के माध्यम से तेजी से दौड़ता हूं तो मेरा कोड पास हो जाता है।

यदि श्रमिक थ्रेड बंद हो जाता है और त्रुटि हो जाती है, तो परीक्षण सेटअप पूरा हो जाता है, तो मुझे बिना किसी तर्क के एबर्ड का परिणाम मिलता है।

यदि श्रमिक धागा बंद हो जाता है और त्रुटि होती है, तो परीक्षण शुरू हो गया है, तो मुझे इसका परिणाम मिलता है: त्रुटि - परीक्षण की प्रक्रिया के दौरान एजेंट प्रक्रिया को रोक दिया गया था।

नोट करने के लिए महत्वपूर्ण: यह एक घटक है जिसे मैं अपने कई परीक्षणों में उपयोग करता हूं। यदि परीक्षण ढाँचा इनमें से कई त्रुटियों का सामना करता है, तो यह बाकी परीक्षणों को रद्द कर देता है।

उम्मीद है की यह मदद करेगा

— ब्रेंट वेंडरमाइड को दर्शाता है
स्रोत

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

— ट्राईसिटी

2

मैंने descructor ~ ClassName () {} में प्रयास / कैच ब्लॉक जोड़े हैं जो मेरे परीक्षणों में शामिल किसी भी वर्ग में परिभाषित किए गए थे। इससे मेरे लिए समस्या ठीक हो गई।

~MyClass()
{
    try
    {
        // Some Code
    }
    catch (Exception e)
    {
        // Log the exception so it's not totally hidden
        // Console.WriteLine(e.ToString());
    }
}

— जर्रोड चेसनी
स्रोत

2

यह पता लगाने के लिए कि अपवाद को हाइपरलिंक "टेस्ट रन एरर" पर क्लिक किया गया था, टेस्ट परिणाम विंडो में विस्मयादिबोधक आइकन के बगल में। स्टैक ट्रेस के साथ एक विंडो खोली गई है।

यह त्रुटि को ट्रैक करने में बहुत मदद करता है!

— BlackTuareg
स्रोत

1

मेरे पास भी यही समस्या थी और यह एक अनवांटेड रिसोर्स के लिए फाइनल होने के कारण हुआ था (एक फाइल राइटर जो किसी कारण से ठीक से निपटारा नहीं हो रहा था)।

फाइनल-कोड को एक कोशिश-पकड़ने में लपेटने के बाद जो अपवाद को निगलता है, समस्या गायब हो गई। मैं इस तरह के अपवादों को निगलने की सलाह नहीं देता, इसलिए यह स्पष्ट रूप से यह पता लगाना बुद्धिमानी होगी कि पहली जगह में अपवाद क्यों हो रहा है।

— बेन छुरी
स्रोत

1

मैंने ऐसा अजीब अवसर पर किया है, और अपराधी लगभग हमेशा थ्रेडिंग करता है।

अजीब तरह से सभी परीक्षण विकास मशीनों पर ठीक काम करेंगे, फिर बिल्ड सर्वर पर बेतरतीब ढंग से विफल हो जाएंगे।

करीब से निरीक्षण करने पर यह पता चला कि हालांकि परीक्षणों को देव बक्से पर पारित किया जा रहा था, लेकिन अपवाद फेंके जा रहे थे। अपवादों को एक अलग धागे पर फेंक दिया जा रहा था जो एक त्रुटि के रूप में नहीं उठाया गया था।

अपवाद विवरण परीक्षण ट्रेस के खिलाफ लॉग किए जा रहे थे, इसलिए हम यह पहचानने में सक्षम थे कि कौन से कोड / परीक्षणों को संशोधित करने की आवश्यकता है।

आशा है कि यह किसी की मदद करता है।

— एश
स्रोत

0

मेरे मामले में मेरे पास डब्ल्यूसीएफ-सेवा के लिए कुछ यूनिट-परीक्षण थे। WCF की यह सेवा 2 समय से शुरू हो रही थी।
उन टाइमर के कारण दुष्प्रभाव हुए।
-> मैं इन टाइमर को डिफ़ॉल्ट रूप से अक्षम करता हूं और सब कुछ ठीक है!

BTW: मैं WCF सेवा को नकली करने के लिए WCFMock का उपयोग करता हूं , इसलिए मेरी WCF सेवा के आसपास "वास्तविक" यूनिट परीक्षण हैं

— पीटर Gfader
स्रोत

0

यह त्रुटि मेरे लिए भी एक फाइनल के कारण हुई थी।
फ़ाइनलीज़र को कुछ डीबी कोड कहा गया था, जिसका मजाक नहीं उड़ाया गया था। मुझे इसे खोजने में थोड़ा समय लगा क्योंकि यह एक वर्ग नहीं था जिसे मैंने लिखा था और इसके संदर्भ में काफी कुछ वर्गों पर प्रतिबंध लगाया गया था।

— Cwoo
स्रोत

0

मैं एक ऐसी ही समस्या में चला गया हूँ जहाँ एक परीक्षण TestInitialize में विफल हो रहा है और एक ddl से मेरी अन्य परियोजनाओं में से कोड भी चला रहा है। मुझे ऊपर वर्णित त्रुटि संदेश मिलता है और यदि मैं परीक्षण को डीबग करने का प्रयास करता हूं, तो परीक्षण बिना किसी अपवाद विवरण के निरस्त कर दिया जाता है।

मुझे संदेह है कि समस्या यह हो सकती है कि मेरे अन्य प्रोजेक्ट के dll एक विज़ुअल स्टूडियो 2012 प्रोजेक्ट से हैं और मैं VS2010 प्रोजेक्ट में अपने परीक्षण चला रहा हूं, और / या संभवतः 2 प्रोजेक्ट्स से UnitTestFramwork dll संस्करण बेमेल हैं।

— DevDave
स्रोत

0

समस्या को एक TestClass के कन्स्ट्रक्टर में अपवाद या Stackoverflow द्वारा भी ट्रिगर किया जा सकता है।

— फिल सोर्डी
स्रोत

0

जैसा कि इस त्रुटि के कई अलग-अलग कारण हो सकते हैं, मैं इस धागे की पूर्णता के लिए एक और जोड़ना चाहूंगा।

यदि आपके सभी परीक्षण ओपी द्वारा बताए गए हैं, तो इसका कारण गलत प्रोजेक्ट कॉन्फ़िगरेशन हो सकता है। मेरे मामले में लक्ष्य फ्रेमवर्क .NET फ्रेमवर्क 3.5 पर सेट किया गया था। प्रोजेक्ट गुण पृष्ठ (टैब एप्लिकेशन ) के माध्यम से इसे उच्च संस्करण में सेट करने से समस्या हल हो गई।

— गुड नाइट नर्ड प्राइड
स्रोत

0

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

QTAgent32_40.exe, PID 10432, Thread 2) AgentProcess:CurrentDomain_UnhandledException: IsTerminating : System.NullReferenceException: Object reference not set to an instance of an object.
   at XXX.YYY.ZZZ.cs:line 660
   at XXX.YYY.AAA.Finalize() in C:\JenkinsSlave\workspace\XXX.YYY.AAA.cs:line 180

यह वास्तव में एक क्लास फाइनलिज़र से बुलाए गए तरीके के भीतर एक शून्य संदर्भ अपवाद था।

— डीआईबी
स्रोत

0

इस पुराने प्रश्न पर किसी के लिए भी और यह सोचकर कि उनके धागे से क्या फेंका जा रहा है, यहाँ एक टिप है। Task.Run का उपयोग करना (जैसा कि, थॉट.टार्ट का विरोध किया जाता है), चाइल्ड थ्रेड अपवादों को अधिक मज़बूती से रिपोर्ट करेगा। संक्षेप में, इसके बजाय:

Thread t = new Thread(FunctionThatThrows);
t.Start();
t.Join();

यह करो:

Task t = Task.Run(() => FunctionThatThrows());
t.Wait();

और आपकी त्रुटि लॉग अधिक उपयोगी होनी चाहिए।

— जेसन
स्रोत

वीएस 2010 टेस्ट रनर त्रुटि "एजेंट प्रक्रिया रोक दी गई थी जब परीक्षण चल रहा था।"

संपादित करें