2009-05-26 10 views
12

मेरे पास एक ऐप है जो लाइब्रेरी में कीबोर्ड हुक प्रक्रिया का उपयोग करता है। एक संदेश के लिए हुक में wParam 255 है जो हमें लगता है "(आरक्षित/OEMClear)" है। मैं इस संदेश के स्रोत को काम करना चाहता हूं क्योंकि यह मेरे एप्लिकेशन को लाइब्रेरी में क्रैश होने का कारण बनता है, और यह नहीं दिया जाना चाहिए कि यह पहचानना अच्छा होगा। संदेश हमारे पास केवल एक पीसी पर बार-बार आता है - अन्य कंप्यूटर बिल्कुल संदेश नहीं देखते हैं।मेरा ऐप विंडोज़ संदेश के प्रेषक को कैसे ढूंढ सकता है?

तो, वहाँ एक संदेश के स्रोत कृपया एक खिड़की के लिए भेजा, या सिस्टम पर उन सभी का पता लगाने के लिए एक रास्ता है?

+0

इस के लिए अंतिम समाधान है, दुर्भाग्य से, एक चिपके प्लास्टर था। मैंने अपने ऐप में एक और हुक जोड़ा जो इस wParam मान को देखता है और मिलान होने पर हुक श्रृंखला को कॉल नहीं करता है। मैं इसे पीसी विशिष्ट (रजिस्ट्री) बना रहा हूं लेकिन उस पीसी के साथ कुछ गलत लगता है। – mj2008

उत्तर

5

कोई अंतर्निहित तरीका जो खिड़की संदेश भेजा पता लगाने के लिए नहीं है यहां तक ​​कि win32k इस का ट्रैक रखता है नहीं; आप इसे कर्नेल डीबगर और एक सशर्त ब्रेकपॉइंट के साथ ढूंढ पाएंगे।

हालांकि, मैं तर्क है कि तुम सच में इस जानकारी की जरूरत नहीं है; आपको अपने एप को किसी भी संदेश को सही तरीके से संभालने की आवश्यकता है।

+4

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

+1

@ mj2008: यदि आप मशीनों पर इसे तैनात कर रहे हैं तो आप पूरी तरह से नियंत्रण नहीं करते हैं, आप काटने के लिए जा रहे हैं; बुरी तरह से लिखे गए ऐप्स बहुत सारे काम करने के प्रयासों में सभी खिड़कियों को अजीब संदेश भेजते हैं और आप * इसके साथ * सौदा करने के लिए * हैं। बस उन संदेशों को कैप्चर करें जिनमें आप रुचि रखते हैं, और बाकी को श्रृंखला में अगले हुक के साथ पास करें। –

+1

मैं संदेश में प्रेषक आईडी जोड़ने का सुझाव देता हूं। – Alpay

-1

इम यकीन नहीं करता है, तो यह है कि क्या आप इसे करना चाहते हैं लेकिन sysinternals द्वारा प्रक्रिया मॉनिटर पर एक नज़र है।

http: // technet.microsoft.com/en-us/sysinternals/bb896645.aspx

यह सब कुछ है कि एक प्रक्रिया के लिए होता तो मैं यह संदेश फैल जाती है और साथ ही यह मान दर्शाता है। साइट लिखने के समय नीचे थी इसलिए मैं जांच नहीं कर सका।

+0

धन्यवाद - यह संदेशों का पता लगाने के लिए प्रतीत नहीं होता है, लेकिन यह मुझे http://msdn.microsoft.com/en-us/library/cc267862.aspx पर ले जाता है जो डीबग बिल्ड में डीबग विकल्प का विवरण देता है। लेकिन संदेश ट्रेसिंग के लिए कुछ भी नहीं! – mj2008

+0

मुझे प्रक्रिया मॉनीटर में 'ऑपरेशन' के रूप में विंडोज संदेश नहीं दिख रहे हैं। – Aardvark

1

(मैंने मूल रूप से जासूस ++ या विजेता का उपयोग करने का सुझाव दिया है, लेकिन वे संदेशों में संदेश भेजकर नहीं हैं। यह भी समझ में नहीं आता है! एक विंडो को संदेश प्राप्त होते हैं लेकिन वे उन्हें नहीं भेजते हैं, एक थ्रेड करता है । मैं एक डिबगर का उपयोग कर के बारे में मेरे सुझाव छोड़ देंगे।)

कभी कभी डिबगिंग कर सकते हैं। विंडोज PDB फ़ाइलों को डाउनलोड करने और ब्रेकपॉइंट सेट करने का प्रयास करें जो केवल तब होता है जब इनमें से कोई एक संदेश होता है। उस बिंदु पर कॉल स्टैक को देखते हुए अक्सर चीजें क्यों हो रही हैं, इस पर कुछ प्रकाश डाल सकता है। पोस्ट किए गए संदेश और संदेश अन्य प्रक्रियाओं से भेजे गए इस दृष्टिकोण को विफल करेंगे।

+0

मैंने पहले विंस्पेक्टर को देखा (इसे वर्षों तक इस्तेमाल किया) लेकिन यह स्रोत नहीं दिखाता है। डीबगर एकमात्र विकल्प हो सकता है ... – mj2008

1

जो खिड़की संदेश

बेशक

है भेजा पता लगाने के लिए कोई अंतर्निहित तरीका नहीं है। लेकिन यह उन्नत Win32 प्रोग्रामिंग (CSRSS hooking द्वारा)

+1

सीएसआरएसएस विंडो संदेशों को संभाल नहीं करता है, Win32k कर्नेल मोड में करता है। –

+2

विस्तार से देखभाल? – Virus721