कभी-कभी विंडोज एक प्रक्रिया को क्यों नहीं मार सकता है?

30

अभी मैं विजुअल स्टूडियो में अपने एप्लिकेशन को चलाने / डिबग करने का प्रयास कर रहा हूं, लेकिन यह इसे नहीं बना सकता क्योंकि app.vshost.exeअभी भी इसका अंतिम उदाहरण चल रहा है। फिर, टास्क मैनेजर का उपयोग करके मैं इसे मारने की कोशिश कर रहा हूं, लेकिन यह सिर्फ गतिविधि का कोई संकेत नहीं है।

उस विशेष मामले से परे (शायद एक विजुअल स्टूडियो बग), मैं तकनीकी कारणों से बहुत उत्सुक हूं कि कभी-कभी विंडोज एक प्रक्रिया को क्यों नहीं मार सकता है?

कर सकते हैं, एक प्रबुद्ध ओएस संबंधित डेवलपर, कृपया समझाने की कोशिश करें?

(और कृपया विंडोज के खिलाफ एक यूनिक्स / लिनक्स / मैक लड़ाई शुरू न करें।)

— नेस्टॉर सैंचेज़ ए।
स्रोत

10

अगर मेरे पास केवल इस सवाल का जवाब चाहिए था, तो हर बार एक निकल ...

— स्टीवन ऑक्सले

3

मैं उत्तर की सराहना करता हूं, लेकिन मैं एक ऑपरेटिंग सिस्टम डेवलपर को यह बताना चाहता हूं कि इस युग का ओएस गैर-कोर / कर्नेल (या जो भी विशेषण उपयुक्त हो) प्रक्रिया को क्यों नहीं मार सकता है। मेरा मानना है कि 386 के बाद से "रिंग 0" (या कुछ एक जैसे) कुछ विशेष कोड को दूसरे पर विशेष अधिकार दे रहा था, मुझे लगता है कि जिस तरह से (ओएस) प्रक्रिया दूसरों पर अधिकार थी। शायद मैं पूरी तरह से गलत हूं, लेकिन सवाल अनुत्तरित है।

— नेस्टर सैंचेज़ ए।

21

कारण आमतौर पर कुछ गैर-जिम्मेदार चालक है जो प्रगति में आई / ओ अनुरोधों को अधूरा करता है।

मार्क रोसिनोविच का ब्लॉग प्रविष्टि अनकबिल प्रोसेस ( संग्रह ) देखें

— इयान बॉयड
स्रोत

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

— लॉरेंस

उद्योग (इंटेल, एएमडी, एआरएम, आदि) को अंत में उपयोगकर्ता को (अपने जोखिम पर) एक प्रक्रिया को मारने की वास्तविक क्षमता और एक बार और हमेशा के लिए इस समस्या से छुटकारा पाने के लिए "मेटा-रिंग" बनाएं। ????

— Néstor Sánchez A.

16

एक संभावित कारण: आप उस कार्य को नहीं मार सकते जो डिबगर से जुड़ा हुआ है।

कार्य को रोकने का एकमात्र तरीका डीबगर से ही है।

— harrymc
स्रोत

3

मैं कैसे पता लगाऊं कि क्या डिबगर जुड़ा हुआ है और यह किस प्रक्रिया से जुड़ा हुआ है? क्योंकि मैं कुछ भी डिबग नहीं कर रहा हूं, लेकिन टास्क मैनेजर के साथ नहीं बल्कि टास्क मैनेजर के साथ मर जाएगा, साथ नहीं, साथ taskkill /fनहीं wmic ... call terminate... यह "त्रुटि:" कहती रहती है: pid Y के साथ प्रक्रिया X को समाप्त नहीं किया जा सकता है । इस कार्य का कोई चल उदाहरण नहीं है। "

— ल्यूक

3

एक कारण यह होगा कि आपको इसे मारने की अनुमति नहीं है। जैसे अगर प्रक्रिया प्रशासक के रूप में चल रही है और आप एक सामान्य उपयोगकर्ता हैं।

— ब्रायन लिटल
स्रोत

3

प्रोजेक्ट के लिए गुण पृष्ठ खोलें , डीबग टैब पर जाएं, और "अप्रबंधित कोड डीबगिंग सक्षम करें" जांचें। या, होस्ट प्रक्रिया का उपयोग करने के लिए विकल्प को अनचेक करें।

— Tadjou
स्रोत

2

यदि अंतिम app.vshost.exe अभी भी चल रहा है, तो बस डिबगर के साथ उस प्रक्रिया से कनेक्ट करें।

डिबग-> AttachToProcess के तहत मेनू में पाया जाना चाहिए फिर फांसी की प्रक्रिया चुनें और इसे कनेक्ट करें।

— ओलिवर फ्रेडरिक
स्रोत

2

मेरा केवल ओएस-स्तरीय विकास का अनुभव ग्रेड स्कूल में था, लेकिन मुझे संदेह है कि यह क्या हो रहा है (या कुछ इसी तरह):

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

C:\Windows\system32>taskkill /pid 9564 /f /t
ERROR: The process with PID 9564 (child process of PID 22520) could not be
terminated.
Reason: There is no running instance of the task.

क्या आपको माता-पिता पर एक ही चीज़ आज़माने का फैसला करना चाहिए (मेरे मामले में माता-पिता डिबगर प्रक्रिया msvsmon.exe था), यह उसी तरह विफल रहता है:

C:\Windows\system32>taskkill /pid 22520 /f /t
ERROR: The process with PID 9564 (child process of PID 22520) could not be
terminated.
Reason: There is no running instance of the task.
ERROR: The process with PID 22520 (child process of PID 13964) could not be
terminated.
Reason: There is no running instance of the task.

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

प्रक्रिया में संलग्न करने में असमर्थ। एक ऑपरेशन वर्तमान स्थिति में कानूनी नहीं है।

डिबगर के माध्यम से एक और उदाहरण को चलाने से रोकने के लिए लाश अभी भी पर्याप्त रूप से प्रक्रिया तालिका में है, लेकिन आप शायद आईडीई के ठीक बाहर एक और उदाहरण शुरू कर सकते हैं।

यह वीएस एक ज़ोंबी प्रक्रिया बनाने के अधिक विशिष्ट मुद्दे को संबोधित करता है। लेकिन, ज़ोंबी प्रक्रियाओं में अक्सर मृत्यु नहीं होती है। खैर, अक्सर विंडोज पर, कभी-कभी लिनक्स पर, तब तक नहीं जब तक आप उन्हें एक बन्दूक के साथ शूट नहीं करते। या कि एक बंद था? लेकिन लंबित विंडोज अपडेट के आकस्मिक आवेदन से सावधान रहें।

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

— hlongmore
स्रोत

धन्यवाद, यह निश्चित रूप से सबसे अच्छा जवाब है जो मेरी समस्या से मेल खाता है।

— पाब्लो एरियल

1

शायद यहाँ उद्धृत उपकरणों में से कुछ की एक परीक्षा उत्तर दे सकती है?

https://stackoverflow.com/questions/49988/really-killing-a-process-in-windows

(अभी-अभी मैंने पाया कि पीस्किल केवल कई उपकरण थे जो एक उपयोगकर्ता के विंडोज 7 सत्र के तहत चलने वाली प्रक्रिया को मार सकते थे, दूसरे उपयोगकर्ता के सत्र (या क्रेडेंशियल्स, मुझे लगता है)।

— r_alex_hall
स्रोत

-1

आप ऐसा कर सकते हैं!

ProcessHacker (प्रक्रिया पर राइट क्लिक करें) का उपयोग करना -> टर्मिनेटर।

— Valmond
स्रोत

-1

यदि आप VS का उपयोग डिबग प्रक्रिया के लिए कर रहे हैं, और आप इसे कार्य प्रबंधक के साथ मार देते हैं। तो VS इससे अच्छे से निपट नहीं सकता।

इसलिए वीएस अभी भी लक्ष्य प्रक्रिया को डिबग कर रहा है, लेकिन आप वीएस में सिर्फ स्टॉप प्रक्रिया को दबा नहीं सकते। बस अपने वीएस को छोड़ दें और आप अपनी प्रक्रिया से बाहर निकल जाएंगे।

— VictorV
स्रोत