2010-07-12 10 views
7

का कारण बन रहा है जब मेरी विंडोज़ Winform एप्लिकेशन चलाया जाता है तो मुझे नीली स्क्रीन मिल रही है। ऐसा लगता है कि केवल एक उपयोगकर्ता ही यह प्राप्त कर रहा है। मुझे यकीन नहीं है कि इस समय समस्या को देखने के लिए कहां है। हालांकि मैं कुछ कोड का उपयोग कर रहा हूं जो मुझे कोडप्रोजेक्ट पर माउस इवेंट्स और कीबोर्ड इवेंट्स को फंसाने के लिए मिला है http://www.codeproject.com/KB/cs/globalhook.aspx क्या यह संभवतः यह हो सकता है?मेरा .net प्रोग्राम बीएसओडी

मैं इस त्रुटि को कैसे जा सकता हूं इस पर सुझावों की तलाश में हूं। यह केवल 40 उपयोगकर्ताओं में से एक कंप्यूटर कंप्यूटर पर हो रहा है, इसलिए मैं थोड़ा परेशान हूं - खासकर जब से यह उपयोगकर्ता प्राथमिक हितधारक है।

अद्यतन: हमारे पास एक और घटना है - आम संप्रदाय डॉकिंग पोर्ट है। उपयोगकर्ता एक ही डॉकिंग पोर्ट का उपयोग कर रहा था।

+9

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

+1

क्या आपका ऐप अप्रबंधित कोड या PInvoke का उपयोग करता है? – David

+1

दूसरा राउफैमैटिक। "प्राथमिक हितधारक" अक्सर सबसे अधिक शक्ति और कम से कम ज्ञान वाला व्यक्ति होता है ... –

उत्तर

12

आपके कोड के लिए असंभव है एक बीएसओडी। यदि आप कर्नेल मोड में नहीं चल रहे हैं, तो बीएसओडी आपकी गलती नहीं है (यदि आप पन क्षमा करेंगे)।

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

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

कहानी का नैतिक यह है कि किसी को क्रैश डंप को देखने की आवश्यकता होती है और पता चलता है कि कर्नेल-मोड सॉफ़्टवेयर का कौन सा टुकड़ा दुर्घटना का कारण बनता है, तो शायद आप यह समझ सकते हैं कि कर्नेल को ट्रिगर करने के लिए सिस्टम में क्या चल रहा था क्रैश करने के लिए सॉफ्टवेयर सॉफ्टवेयर।

+1

पन के लिए +1। – overslacked

3

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

  1. खराब स्मृति। यदि एक स्मृति त्रुटि विकसित हुई है तो यह एक असामान्य प्रोग्राम देखने के लिए असामान्य नहीं है जो खराब स्मृति को 'कारण' पहुंचा सकता है और इसलिए बीएसओडी का कारण बनता है। उदाहरण के लिए यदि वह आम तौर पर हल्के हल्के अनुप्रयोग चला रहा है तो स्मृति त्रुटि के लिए संभवतः सामान्य रूप से उपयोग नहीं किया जा सकता है। जब आप अपना ऐप लोड करते हैं - विशेष रूप से यदि इसे बड़ी मेमोरी पदचिह्न मिलती है और कई निर्भरताओं में कॉलिंग होती है, तो आप अप्रत्यक्ष रूप से क्रैश को ट्रिगर कर सकते हैं। तो मशीन रैम पर एक पूर्ण जांच चलाएं।

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

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

+0

यह खराब हो सकता है * <हार्डवेयर का कोई भी टुकड़ा> *, या खराब * * ड्राइवर। यह किसी अन्य अप्रबंधित (कर्नेल-स्तर) कोड में भी एक बग हो सकता है। –

+1

@ ब्लू - ओह बिल्कुल, यह कुछ भी हो सकता है। यह सिर्फ इतना अनुभव दिखाता है कि खराब मेमोरी और खराब प्रिंटर ड्राइवर सबसे आम हैं जो पहले जांच कर रहे हैं। – Cruachan

1

मुझे पहले इस समस्या को हल करना पड़ा है। मैं यूएसबी बस पर एक छिपा डिवाइस से बात करने के लिए उपयोगकर्ता मोड सी # कोड लिख रहा था। यह समस्या मेरे लैपटॉप पर हुई लेकिन किसी और की मशीन पर नहीं हुई। यह पता चला कि यह समस्याएं पैदा कर रहा था क्योंकि मैं 64-बिट ओएस चला रहा था और इसलिए 64-बिट ड्राइवर थे। अन्य सभी उपयोगकर्ताओं के पास 32-बिट ड्राइवर थे, जिनमें समस्या नहीं थी। यह उपयोगकर्ताओं का हल्का नियंत्रित सेट था। मैं प्रत्येक उपयोगकर्ता को जानता था और वे सक्षम उपयोगकर्ता थे जो मुझे अपने हार्डवेयर, ओएस और ड्राइवरों के बारे में जानकारी दे सकते थे। हम सभी एक ही डिवाइस का उपयोग कर रहे थे।

मुझे याद नहीं है कि मैंने समस्या को कैसे हटाया। लेकिन मैंने केवल 32-बिट विंडोज़ को लक्षित करने के लिए एप्लिकेशन प्रोजेक्ट को सेट करके इसे हल किया। 64-बिट ऐप के बिना, दोषपूर्ण ड्राइवर का कभी भी उपयोग नहीं किया जाता है।

क्या उपयोगकर्ता अपने ड्राइवर, हार्डवेयर, या ड्राइवर को पूरी तरह से उपयोग करने से बचने के लिए कोड को बदलते हैं।

संबंधित मुद्दे