2014-05-05 13 views
8

में उच्च प्रक्रिया रिज़ॉल्यूशन सेट करने के लिए कौन सी प्रक्रिया बताती है मेरी प्रणाली एक उच्च टाइमर रिज़ॉल्यूशन (NtQueryTimerResolution रिटर्न 0.5ms) से पीड़ित है।विंडोज़

Maximum timer interval: 15.600 ms 
Minimum timer interval: 0.500 ms 
Current timer interval: 0.500 ms 

कुछ प्रक्रिया 5000 (0.5ms) के मान के साथ NtSetTimerResolution बुला होना चाहिए, लेकिन मैं जो एक कैसे तय कर सकते हैं? मैंने देखा कि इंटेल के पास Battery Life Analyzer नामक टूल है जो प्रति प्रक्रिया वर्तमान टाइमर रिज़ॉल्यूशन दिखाता है, लेकिन यह टूल केवल इंटेल पार्टनर के लिए उपलब्ध है। क्या WinDbg के माध्यम से इसे देखने का कोई अन्य टूल या तरीका है? नोट: ऐसा लगता है कि बूट समय पर ऐसा होता है क्योंकि ब्रेकपॉइंट सेट करना काम नहीं कर रहा है (डीबगर शुरू होने पर संकल्प पहले से ही अधिक है)।

+2

Powercfg.exe/ऊर्जा एक स्लिम रिपोर्ट उत्पन्न करेगी जो बुराई करने वाले को उंगली देगी। इस तरह के प्रश्न पूछने के लिए superuser.com का प्रयोग करें। –

+1

@ हंसपैसेंट धन्यवाद लेकिन यह काम नहीं किया। रिपोर्ट में कहा गया है 'अनुरोध संख्या 1' लेकिन यह नहीं दिखाता कि किसने इसका अनुरोध किया था। मैंने पूरी रिपोर्ट अपलोड की [यहां] (http://rustyx.org/energy-report.html)। – rustyx

+0

Powercfg.exe/ऊर्जा यह नहीं कर रहा है, इंटेल इसे कर सकता है। मैं एपीआई कॉल भी देखना चाहता हूं। – Arno

उत्तर

3

एक ही रास्ता मैं जानता हूँ कि और अब तक का इस्तेमाल किया है चल रही प्रक्रियाओं की प्रत्येक में और उस प्रक्रिया प्रत्येक वृद्धि हुई संकल्प के लिए timeEndPeriod बुला अंदर इंजेक्शन है इन प्रस्तावों पर एक पाश में (1-15 को महत्व देता है) और देखना हो के लिए timeEndPeriod कॉल एक वर्तमान संकल्प TIMERR_NOCANDO या TIMERR_NOERROR लौटाता है (नोट: ये वापसी मान संगत रूप से झूठे और सत्य नहीं हैं)। और यदि यह TIMERR_NOERROR देता है तो यह निष्कर्ष निकाला जाता है कि प्रोग्राम उस आवृत्ति का उपयोग कर रहा है, और उसके बाद प्रोग्राम द्वारा अनुरोध किए गए मूल समाधान को पुनर्स्थापित करने के लिए timeBeginPeriod पर कॉल कर रहा है।

दुर्भाग्यवश यह विधि 0.5 एमएस टाइमर संकल्पों का पता नहीं लगाती है जिसे अनियंत्रित NtSetTimerResolution फ़ंक्शन द्वारा सेट किया जा सकता है।

आप लगातार तो ntdll.dll में गैर-दस्तावेजी NtSetTimerResolution समारोह के लिए कॉल hooking नई टाइमर प्रस्तावों की निगरानी करना चाहते हैं जिस तरह से मैं वर्तमान में (समारोह के हस्ताक्षर here से उदाहरण के लिए लिया जा सकता है) का उपयोग है।

दुर्भाग्य hooking टाइमर प्रस्तावों कि हुक स्थापित किया गया था इससे पहले कि अनुरोध किया गया पता नहीं लगा पाया है, तो आप इसके बाद के संस्करण timeEndPeriod चाल और टिप्पणी भी कि hooking मनाने से पहले 0.5 एमएस संकल्प अनुरोध चल पाता साथ संयोजित करने की जरूरत है।

और मैं सहमत हूं, यह विधि बोझिल लगती है। इसके अलावा, यह थोड़ा घुसपैठ कर रहा है क्योंकि यह प्रक्रिया की स्थिति को संशोधित करता है, और यह भी मानता है कि आप सभी प्रक्रियाओं में इंजेक्ट करने में सक्षम हैं।

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

+1

मुझे इंजेक्ट विचार पसंद है! लेकिन सबसे पहले, इंजेक्शन कोड को केवल "वर्तमान" रिज़ॉल्यूशन की जांच करनी होगी और दूसरी बात यह STATUS_TIMER_RESOLUTION_NOT_SET के परीक्षण के लिए एनटीएसटीटीमर रेसोल्यूशन का भी उपयोग कर सकती है। – Arno

+0

हालांकि, यह एक छोटा अंतराल का कारण बनता है जबकि एप्लिकेशन इसके वांछित संकल्प को खो देता है। क्या आपको लगता है कि 'powercfg - energy' लागू किया गया तरीका है? और: ड्राइवर्स? बूट समय पर सिस्टम? वैसे भी बक्षीस दिया, आपके प्रयास के लिए धन्यवाद। मैंने इस मामले पर फिर से एक और प्रश्न में ध्यान खींच लिया है [यहां] (http://stackoverflow.com/q/23734775/1504523)। – Arno

+0

मैं एक प्रक्रिया में इंजेक्ट कैसे कर सकता हूं और समय अवधि को कॉल कर सकता हूं? मुझे वही समस्या है, सिवाय इसके कि टाइमर आवृत्ति 1.25ms होने के लिए कॉल कर रहा है। –

5

मैंने पाया कि विंडोज 7 _EPROCESS कर्नेल संरचना में प्रति प्रक्रिया टाइमर रिज़ॉल्यूशन का ट्रैक रखता है।

lkd> !list "-e -x \"dt nt!_EPROCESS @[email protected]@(#FIELD_OFFSET(nt!_EPROCESS,TimerResolutionLink)) ImageFileName UniqueProcessId SmallestTimerResolution RequestedTimerResolution\" nt!ExpTimerResolutionListHead"

मेरे मामले में हालांकि प्रक्रिया ID था:

डिबगिंग के साथ (/debug साथ बूट) सक्षम यह windbg (चलाने windbg -kl) के साथ ExpTimerResolutionListHead सूची ब्राउज़ करें और इस तरह घड़ी जानकारी निकालने के लिए संभव है नल (शायद क्योंकि चालक ने अनुरोध किया था), और मैं अभी भी यह पता नहीं लगा सका कि यह कौन सा चालक था।

+0

+1 बीटीडब्लू भेज या अपलोड कर सकते हैं: powercfg -energy किसी भी कोड को इंजेक्ट नहीं करता है, इस प्रकार इसे किसी और जानकारी को प्राप्त करना होगा। लेकिन यह ड्राइवर द्वारा अधिग्रहित टाइमर सेटिंग्स को भी हल नहीं कर सकता है। – Arno

+0

powercfg -energy भी कॉल के कॉल स्टैक को दिखाता है जो प्रक्रिया को उच्चतम टाइमर रिज़ॉल्यूशन सेट करता है। मुझे लगता है कि यह कॉल स्टैक भी retroactively काम करता है - कॉल के लिए जो powercfg -energy चलाने से पहले किया गया था। तो शायद कर्नेल को इन कॉलस्टैक के लिए भी जानकारी है। मुझे आश्चर्य है कि क्यों ...? और मुख्य रूप से इस संदर्भ में - यह जानकारी कहां स्थित हो सकती है? क्या यह एक ही कर्नेल डेटा संरचना में भी है? कोई भी आश्चर्यचकित हो सकता है कि ड्राइवरों के कॉल स्टैक क्यों संग्रहीत नहीं किए जाते हैं। अगर मैं सही ढंग से समझता हूं तो ड्राइवर्स सिस्टम प्रक्रिया के तहत चलाए जाते हैं। –

+0

मैंने थोड़ा Google खोज किया था। ऐसा लगता है कि हाँ, _EPROCESS में टाइमर रिज़ॉल्यूशन अनुरोधों से संबंधित डायग्नोस्टिक स्टैक भी शामिल हैं: http: //msdn.moonsols।com/win7rtm_x86/EPROCESS.html –