पिछले लेख में, मैंने कुछ विवरणों को प्रकट करने का वादा किया था जिन्हें मैंने जांच के दौरान छोड़ दिया था [Gmail विंडोज पर क्रोम में लटका हुआ है - लगभग। प्रति।], जिसमें पेज टेबल, लॉक्स, WMI और vmmap त्रुटि शामिल हैं। अब मैं अद्यतन कोड उदाहरणों के साथ इन अंतरालों को भरता हूं। लेकिन पहले, संक्षेप में सार को रेखांकित करें।

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

यह ध्यान दिया जाना चाहिए कि अगर वर्चुअलआलोक सामान्य से एक लाख गुना अधिक धीमी गति से चलना शुरू करता है, तो फ्रीज से बचना मुश्किल है।

सीएफजी के अलावा, एक और व्यर्थ मेमोरी है, हालांकि यह इतना नहीं है जितना कि वीएमएपी का दावा है।

सीएफजी और पेज

प्रोग्राम मेमोरी और सीएफजी मेमोरी दोनों को अंततः 4 किलोबाइट पृष्ठों (बाद में इस पर) के साथ आवंटित किया जाता है। चूँकि 4 KB की CFG मेमोरी 256 KB प्रोग्राम मेमोरी (उस पर बाद में अधिक) का वर्णन कर सकती है, इसका मतलब है कि यदि आप 256 KB के साथ संरेखित 256 KB मेमोरी ब्लॉक का चयन करते हैं, तो आपको एक 4 KB CFG पृष्ठ मिलेगा। और यदि आप एक 4 KB निष्पादन योग्य ब्लॉक आवंटित करते हैं, तो आपको अभी भी 4 KB का CFG पृष्ठ मिलेगा, लेकिन इसका अधिकांश उपयोग नहीं किया जाएगा।

निष्पादन योग्य मेमोरी को मुक्त करने पर सब कुछ अधिक जटिल है। यदि आप निष्पादन योग्य मेमोरी के एक ब्लॉक पर VirtualFree फ़ंक्शन का उपयोग करते हैं जो 256 KB से अधिक नहीं है या 256 KB पर संरेखित नहीं है, तो OS को कुछ विश्लेषण करना चाहिए और सत्यापित करना चाहिए कि कुछ अन्य निष्पादन योग्य मेमोरी CFG पृष्ठ का उपयोग नहीं करता है। सीएफजी के लेखकों ने परेशान नहीं करने का फैसला किया - और बस हमेशा के लिए आवंटित सीएफजी मेमोरी छोड़ दें। यह बहुत दुर्भाग्यपूर्ण है। इसका मतलब यह है कि जब मेरा परीक्षण कार्यक्रम आवंटित होता है और फिर 1 गीगाबाइट को संरेखित निष्पादन योग्य मेमोरी से मुक्त करता है, तो यह 16 एमबी का सीएफजी मेमोरी छोड़ देता है।

व्यवहार में, यह पता चलता है कि जब क्रोम जावास्क्रिप्ट इंजन आवंटित करता है और फिर 128 एमबी की संयुक् त निष्पादन योग्य मेमोरी को जारी करता है (यह सभी का उपयोग नहीं किया गया था, लेकिन पूरी रेंज को आवंटित किया गया था और तुरंत मुक्त कर दिया गया था), तो 2 एमबी तक की सीएफजी मेमोरी आवंटित की जाएगी, हालांकि इसे पूरी तरह से मुक्त करने के लिए तुच्छ है। । चूंकि क्रोम बार-बार यादृच्छिक पते पर मेमोरी को आवंटित और मुक्त करता है, इसलिए यह ऊपर वर्णित समस्या की ओर जाता है।

अतिरिक्त खोई हुई स्मृति

किसी भी आधुनिक ओएस में, प्रत्येक प्रक्रिया को अपना स्वयं का वर्चुअल मेमोरी एड्रेस स्पेस मिलता है, जिससे ओएस प्रक्रियाओं को अलग करता है और मेमोरी की सुरक्षा करता है। यह एक मेमोरी मैनेजमेंट यूनिट (MMU) और पेज टेबल का उपयोग करके किया जाता है। मेमोरी को 4 केबी पेज में विभाजित किया गया है। यह स्मृति की न्यूनतम राशि है जो ओएस आपको देता है। प्रत्येक पृष्ठ को पृष्ठ तालिका में आठ-बाइट रिकॉर्ड द्वारा इंगित किया गया है, और रिकॉर्ड स्वयं 4 केबी पृष्ठों में संग्रहीत हैं। उनमें से प्रत्येक अधिकतम 512 विभिन्न स्मृति पृष्ठों की ओर इशारा करता है, इसलिए हमें पृष्ठ तालिकाओं के पदानुक्रम की आवश्यकता है। 64-बिट ऑपरेटिंग सिस्टम में 48-बिट एड्रेस स्पेस के लिए, सिस्टम निम्नानुसार है:

• एक स्तर 1 तालिका 256 टीबी (48 बिट्स) को कवर करती है, जो 512 विभिन्न पृष्ठ स्तर 2 तालिकाओं की ओर इशारा करती है
• प्रत्येक स्तर 2 तालिका 512 जीबी को कवर करती है, जो 512 स्तर 3 टेबल की ओर इशारा करती है
• प्रत्येक स्तर 3 तालिका 1 जीबी को कवर करती है, जो 512 स्तर 4 तालिकाओं की ओर इशारा करती है
• प्रत्येक स्तर 4 तालिका 2 एमबी तक फैली हुई है, जो 512 भौतिक पृष्ठों की ओर इशारा करती है

MMU पते के पहले 9 (48 में से) बिट्स में 1 स्तर की तालिका को अनुक्रमित करता है, अगले 9 बिट्स में 2 स्तर की तालिकाएं, और शेष स्तरों को 9 बिट्स, यानी केवल 36 बिट्स दिए गए हैं। शेष 12 बिट्स का उपयोग 4 स्तर की तालिका से 4 किलोबाइट पृष्ठों को अनुक्रमित करने के लिए किया जाता है। अच्छा, अच्छा।

यदि आप तुरंत तालिकाओं के सभी स्तरों को भरते हैं, तो आपको 512 जीबी से अधिक रैम की आवश्यकता होती है, इसलिए वे आवश्यकतानुसार भरे जाते हैं। इसका अर्थ है कि जब कोई मेमोरी पेज आवंटित करता है, तो ओएस कुछ पेज टेबल का चयन करता है - शून्य से तीन तक, इस पर निर्भर करता है कि आवंटित पते 2 एमबी के पहले अप्रयुक्त क्षेत्र में हैं, 1 जीबी का पूर्व अप्रयुक्त क्षेत्र या 512 जीबी का स्तर (पहले स्तर का 1 पृष्ठ) हमेशा बाहर खड़ा है)।

संक्षेप में, यादृच्छिक पतों को आवंटित करना आस-पास के पतों को आवंटित करने की तुलना में बहुत अधिक महंगा है, क्योंकि पहले मामले में पेज टेबल साझा नहीं किए जा सकते हैं। सीएफजी लीक दुर्लभ हैं, इसलिए जब वीएमएपी ने क्रोम में 412,480 केबी पेज टेबल का इस्तेमाल किया, तो मुझे लगा कि संख्या सही है। यहाँ पिछले लेख से chrome.exe मेमोरी लेआउट के साथ vmmap का स्क्रीनशॉट है, लेकिन पेज टेबल लाइन के साथ:



लेकिन कुछ गलत लग रहा था। मैंने अपने VirtualScan टूल में एक पेज टेबल सिम्युलेटर जोड़ने का फैसला किया। यह गणना करता है कि स्कैनिंग प्रक्रिया के दौरान सभी आवंटित मेमोरी के लिए पेज टेबल के कितने पेज आवश्यक हैं। आपको बस आवंटित मेमोरी को स्कैन करने की आवश्यकता है, काउंटर पर प्रत्येक 2 एमबी, 1 जीबी या 512 जीबी के कई नंबर को जोड़कर।

यह जल्दी से पता चला था कि सिम्युलेटर परिणाम सामान्य प्रक्रियाओं पर vmap के अनुरूप हैं, लेकिन CFG मेमोरी की एक बड़ी मात्रा के साथ प्रक्रियाओं पर नहीं। अंतर लगभग आवंटित सीएफजी मेमोरी से मेल खाता है। उपरोक्त प्रक्रिया के लिए, जहाँ vmmap 402.8 MB (412,480 KB) पृष्ठ तालिकाओं के बारे में बात करता है, मेरा उपकरण 67.7 MB दिखाता है।

  स्कैन समय, प्रतिबद्ध, पेज टेबल, प्रतिबद्ध ब्लॉक
 कुल: 41.763, 1457.7 MiB, 67.7 MiB, 32112, 98 कोड ब्लॉक
 CFG: 41.759s, 353.3 MiB, 59.2 MiB, 24866 

मैंने VAllocStress को चलाकर vmmap त्रुटि को सुनिश्चित किया, जो कि डिफ़ॉल्ट सेटिंग्स में विंडोज को 2 गीगाबाइट सीएफजी मेमोरी आवंटित करने का कारण बनता है। vmmap ने पृष्ठ तालिकाओं के 2 गीगाबाइट आवंटित करने का दावा किया है:



और जब मैंने कार्य प्रबंधक के माध्यम से प्रक्रिया पूरी की, तो vmmap ने दिखाया कि आवंटित मेमोरी की मात्रा केवल 2 गीगाबाइट घट गई। तो, vmmap गलत है, पेज टेबल के साथ मेरी गणना सही है, और ट्विटर पर एक उपयोगी चर्चा के बाद , मैंने vmmap त्रुटि पर एक रिपोर्ट भेजी, जिसे ठीक किया जाना चाहिए। सीएफजी मेमोरी अभी भी पृष्ठ तालिका प्रविष्टियों (उपरोक्त उदाहरण में 59.2 एमबी) की बहुत खपत करती है, लेकिन उतना नहीं जितना कि vmmap कहते हैं, और इसे ठीक करने के बाद कुछ भी उपभोग नहीं करेंगे।

CFG और CFG क्या है?

मैं थोड़ा पीछे हटना चाहता हूं और अधिक विस्तार से बताना चाहता हूं कि सीएफजी क्या है।

CFG का मतलब है कंट्रोल फ्लो गार्ड। यह फंक्शन पॉइंट्स को फिर से लिखने के द्वारा कारनामों से सुरक्षा का एक तरीका है। सीएफजी सक्षम होने के साथ, संकलक और ओएस एक साथ शाखा लक्ष्य की वैधता की जांच करते हैं। सबसे पहले, इसी सीएफजी नियंत्रण बाइट को 2 टीबी आरक्षित सीएफजी क्षेत्र से लोड किया जाता है। विंडोज में 64-बिट प्रक्रिया 128 टीबी पता स्थान का प्रबंधन करती है, इसलिए पते को 64 से विभाजित करने से आपको इस ऑब्जेक्ट के लिए संबंधित सीएफजी बाइट खोजने की अनुमति मिलती है।

uint8_t cfg_byte = cfg_base[size_t(target_addr) / 64];

अब हमारे पास एक बाइट है जो यह वर्णन करना चाहिए कि 64-बाइट रेंज में कौन से पते वैध शाखा लक्ष्य हैं। ऐसा करने के लिए, सीएफजी बाइट को चार दो-बिट मानों के रूप में मानता है, जिनमें से प्रत्येक 16-बाइट रेंज से मेल खाती है। यह दो-बिट संख्या (जिसका मूल्य शून्य से तीन तक है) की व्याख्या इस प्रकार है :

• 0 - इस 16-बाइट ब्लॉक में सभी लक्ष्य अप्रत्यक्ष शाखाओं के अवैध लक्ष्य हैं
• 1 - इस 16-बाइट ब्लॉक में शुरुआती पता अप्रत्यक्ष शाखा का वैध लक्ष्य है
• 2 - "दमन" सीएफजी कॉल के साथ जुड़े ; पता संभावित रूप से अमान्य है
• 3 - इस 16-बाइट ब्लॉक में अन-असाइन किए गए पते एक अप्रत्यक्ष शाखा के वैध लक्ष्य हैं, हालांकि एक 16-बाइट संरेखित संभावित रूप से अमान्य हैं

यदि अप्रत्यक्ष शाखा का लक्ष्य अमान्य है, तो प्रक्रिया समाप्त हो जाती है और शोषण को रोक दिया जाता है। हुर्रे!



इससे हम यह निष्कर्ष निकाल सकते हैं कि अधिकतम सुरक्षा के लिए, शाखा के अप्रत्यक्ष लक्ष्यों को 16 बाइट्स द्वारा संरेखित किया जाना चाहिए, और हम समझ सकते हैं कि प्रक्रिया के लिए सीएफजी मेमोरी कार्यक्रम मेमोरी का लगभग 1/64 क्यों है।

दरअसल CFG एक बार में 32 बिट्स लोड करता है, लेकिन ये कार्यान्वयन विवरण हैं। कई स्रोत सीएफजी मेमोरी को 16-बाइट डबल-बिट के बजाय 8-बाइट सिंगल-बिट के रूप में वर्णित करते हैं। मेरी व्याख्या बेहतर है।

इसलिए सब कुछ खराब है

जीमेल दो कारणों से लटका हुआ है। सबसे पहले, विंडोज 10 16299 या इससे पहले के सीएफजी मेमोरी को स्कैन करना काफी धीमा है। मैंने देखा कि कैसे एक प्रक्रिया के पता स्थान को स्कैन करने में 40 सेकंड या उससे अधिक समय लगता है, और इस समय का शाब्दिक 99.99% आरक्षित CFG मेमोरी स्कैन किया जाता है, हालांकि यह फिक्स्ड मेमोरी ब्लॉकों का लगभग 75% बनाता है। मुझे नहीं पता कि स्कैनिंग इतनी धीमी क्यों थी, लेकिन उन्होंने इसे विंडोज 10 17134 में तय किया, इसलिए इस समस्या का अधिक विस्तार से अध्ययन करने का कोई मतलब नहीं है।

स्लो स्कैनिंग की वजह से मंदी का सामना करना पड़ा क्योंकि Gmail को CFG अतिरेक चाहिए था, और WMI ने स्कैन की अवधि के लिए लॉक को रखा था। लेकिन पूरे स्कैन में मेमोरी रिजर्वेशन लॉक नहीं था। मेरे उदाहरण में, CFG क्षेत्र में लगभग 49,000 ब्लॉक हैं, और NtQueryVirtualMemory फ़ंक्शन, जो लॉक प्राप्त करता है और जारी करता है, उनमें से प्रत्येक के लिए एक बार कॉल किया गया था। इसलिए, लॉक प्राप्त किया गया था और ~ 49,000 बार जारी किया गया था और प्रत्येक बार 1 मिलीसेकंड से कम समय के लिए आयोजित किया गया था।

लेकिन हालांकि लॉक को 49,000 बार रिलीज़ किया गया था, किसी कारण से क्रोम प्रक्रिया नहीं मिल सकी। यह अनुचित है!

यही समस्या का सार है। जैसा कि मैंने पिछली बार लिखा था:

ऐसा इसलिए है क्योंकि विंडोज़ लॉक स्वाभाविक रूप से अनुचित हैं - और यदि थ्रेड लॉक को रिलीज़ करता है और फिर तुरंत इसे फिर से अनुरोध करता है, तो यह इसे हमेशा के लिए प्राप्त कर सकता है।

फेयर लॉकिंग का मतलब है कि दो प्रतिस्पर्धा वाले धागे इसे बदले में प्राप्त करेंगे। लेकिन इसका मतलब बहुत सारे महंगे संदर्भ स्विच हैं, इसलिए लंबे समय तक लॉक का उपयोग नहीं किया जाएगा।



अनुचित ताले सस्ते हैं, और वे धागे को लाइन में इंतजार नहीं करते हैं। वे सिर्फ लॉक को कैप्चर करते हैं, जैसा कि जो डफी के लेख में बताया गया है। वह यह भी लिखते हैं:

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

100% बार-बार और दीर्घकालिक समस्या पर अपने अनुभव से भूख की दुर्लभता पर 2006 से जो के बयान को कैसे सहसंबंधित किया जाए? मुझे लगता है कि मुख्य कारण 2006 में हुआ। इंटेल ने कोर डुओ जारी किया , और मल्टी-कोर कंप्यूटर सर्वव्यापी हैं।

आखिरकार, यह पता चला है कि भूख की यह समस्या केवल मल्टी-कोर सिस्टम पर होती है! ऐसी प्रणाली में, WMI थ्रेड लॉक को रिलीज़ करेगा, क्रोम थ्रेड को जगाने के लिए संकेत देगा, और जारी रखेगा। चूंकि WMI स्ट्रीम पहले से ही चल रही है, इसलिए इसमें Chrome स्ट्रीम के सामने "हैंडीकैप" है, इसलिए यह आसानी से NtQueryVirtualMemory को कॉल कर सकता है और क्रोम को ऐसा करने का मौका मिलने से पहले फिर से लॉक प्राप्त कर सकता है।

जाहिर है, एकल-कोर प्रणाली में, एक समय में केवल एक धागा काम कर सकता है। एक नियम के रूप में, विंडोज एक नए धागे की प्राथमिकता को बढ़ाता है, और प्राथमिकता बढ़ाने का मतलब है कि जब लॉक जारी किया जाता है, तो नया क्रोम धागा तैयार हो जाएगा और तुरंत WMI थ्रेड से आगे निकल जाएगा । इससे क्रोम थ्रेड को उठने और लॉक प्राप्त करने में बहुत समय लगता है, और भूख कभी नहीं आती है।

क्या आप समझते हैं? मल्टी-कोर सिस्टम में, ज्यादातर मामलों में एक प्राथमिकता वृद्धि WMI स्ट्रीम को प्रभावित नहीं करती है, क्योंकि यह एक अलग कर्नेल पर चलेगा!

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

इस प्रकार, अनुचित ताले उत्पादकता बढ़ाते हैं, लेकिन भूख को जन्म दे सकते हैं। मुझे संदेह है कि समाधान वह हो सकता है जिसे मैं "कभी-कभी निष्पक्ष" ताले कहता हूं। कहो, 99% समय वे अनुचित होंगे, लेकिन 1% में ताला एक और प्रक्रिया को देते हैं। यह भूख की समस्या से बचने के साथ अधिक के साथ उत्पादकता के लाभों को संरक्षित करेगा। पहले, विंडोज में ताले निष्पक्ष रूप से वितरित किए गए थे और आप सही संतुलन पाकर शायद आंशिक रूप से इस पर लौट सकते हैं। डिस्क्लेमर: मैं तालों या ओएस इंजीनियर का विशेषज्ञ नहीं हूं, लेकिन मैं इसके बारे में विचारों को सुनने में दिलचस्पी रखता हूं, और कम से कम मैं ऐसा कुछ करने वाला पहला व्यक्ति नहीं हूं।

लिनुस टॉर्वाल्ड्स ने हाल ही में निष्पक्ष ताले के महत्व की सराहना की: यहां और यहां । शायद यह विंडोज पर भी बदलाव का समय है।

संक्षेप में : कुछ सेकंड के लिए लॉक करना अच्छा नहीं है, यह संक्षिप्तता को सीमित करता है। लेकिन अनुचित लॉक के साथ मल्टी-कोर सिस्टम पर, हटाने और फिर तुरंत लॉक प्राप्त करने पर फिर से वैसा ही व्यवहार होता है - अन्य थ्रेड्स के पास काम करने का कोई तरीका नहीं है।

ETW के साथ लगभग एक विफलता

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

ऐसा हुआ कि Chrome M68 बाहर आया, और इसे VC ++ लिंकर के बजाय lld-link का उपयोग करके जोड़ा गया। यदि आप डंपबिन चलाते हैं और डिबगिंग जानकारी को देखते हैं, तो आप देखेंगे:

C:\b\c\b\win64_clang\src\out\Release_x64\./initialexe/chrome.exe.pdb

खैर, शायद WPA इन स्लैश को पसंद नहीं करता है। लेकिन यह अभी भी समझ में नहीं आता है, क्योंकि मैंने लिंक करने वाले को lld-link में बदल दिया है, और मुझे याद है कि मैंने इससे पहले WPA का परीक्षण किया था, इसलिए क्या हुआ ...

यह पता चला कि इसका कारण नए WPA संस्करण 17134 में था। मैंने lld-Link लेआउट का परीक्षण किया - और इसने WPA 16299 में ठीक काम किया। क्या संयोग है! नया लिंकर और नया WPA संगत नहीं थे।

मैंने जांच जारी रखने के लिए WPA के पुराने संस्करण को स्थापित किया (पुराने संस्करण के साथ मशीन से xcopy) और एक लेड-लिंक बग की सूचना दी, जिसे डेवलपर्स ने जल्दी से ठीक कर दिया। अब आप WPA 17134 पर वापस आ सकते हैं जब M69 को एक निश्चित लिंकर के साथ इकट्ठा किया जाता है।

WMI

WMI फ्रीज़ ट्रिगर एक विंडोज मैनेजमेंट इंस्ट्रूमेंटेशन स्नैप-इन है , और मैं इस पर अच्छा नहीं हूँ। मैंने पाया कि 2014 या उससे पहले, कोई व्यक्ति perfproc के अंदर WmiPrvSE.exe में महत्वपूर्ण CPU उपयोग की समस्या में भाग गया ! GetProcessVaData , लेकिन उन्होंने बग के कारणों को समझने के लिए पर्याप्त जानकारी प्रदान नहीं की। कुछ बिंदु पर, मैंने एक गलती की और यह पता लगाने की कोशिश की कि एक पागल WMI अनुरोध क्या जीमेल को कुछ सेकंड के लिए लटका सकता है। मैंने कुछ विशेषज्ञों को जांच से जोड़ा और इस जादुई क्वेरी को खोजने में बहुत समय बिताया। मैंने ETW निशान में Microsoft-Windows- WMI- गतिविधि गतिविधि दर्ज की, सभी Win32_Perf प्रश्नों को खोजने के लिए PowerShell के साथ प्रयोग किया, और चर्चा करने के लिए बहुत उबाऊ हैं कि कुछ और गोल चक्कर तरीकों में खो गया। अंत में, मैंने पाया कि एक जीमेल हैंग ने इस काउंटर का कारण बना, Win32_PerfRawData_PerfProc_ProcessAddressSpace_Costly , जो एकल-पंक्ति द्वारा ट्रिगर किया गया है PowerShell:

 measure-command {Get-WmiObject -Query “SELECT * FROM Win32_PerfFormattedData_PerfProc_ProcessAddressSpace_Costly”} 

मैं तब काउंटर के नाम ("प्रिय"? वास्तव में?) के कारण और भी अधिक भ्रमित हो गया और क्योंकि यह काउंटर प्रकट होता है और उन कारकों के आधार पर गायब हो जाता है जिन्हें मैं नहीं समझता।

लेकिन WMI के विवरण से कोई फर्क नहीं पड़ता। WMI ने कुछ भी गलत नहीं किया - वास्तव में नहीं - यह सिर्फ मेमोरी को स्कैन करता है। समस्या की जांच में अपना स्वयं का स्कैन कोड लिखना अधिक उपयोगी साबित हुआ।

Microsoft के लिए परेशानी

Chrome ने एक पैच जारी किया है, बाकी Microsoft के लिए है।

1. सीएफजी क्षेत्र की स्कैनिंग स्पीड - ओके, इट्स डन
2. निष्पादन योग्य मेमोरी से मुक्त होने पर सीएफजी मेमोरी को मुक्त कर दिया जाता है - कम से कम 256K संरेखण के मामले में, यह आसान है
3. सीएफजी मेमोरी के बिना निष्पादन योग्य मेमोरी आवंटित करने की अनुमति देने वाले एक ध्वज पर विचार करें, या इस उद्देश्य के लिए PAGE_TARGETS_INVALID का उपयोग करें। ध्यान दें कि विंडोज इंटर्नल पार्ट 1 7 वें संस्करण मैनुअल का कहना है कि "आपको कम से कम एक बिट सेट {1, एक्स}" के साथ [सीएफजी] पृष्ठों का चयन करना चाहिए - यदि विंडोज 10 इसे लागू करता है, तो PAGE_TARGETS_INVALID ध्वज (जो वर्तमान में इंजन द्वारा उपयोग किया जाता है) v8 ) मेमोरी आवंटन से बचना होगा
4. बड़ी संख्या में CFG आवंटन वाली प्रक्रियाओं के लिए vmmap में पृष्ठ तालिकाओं की गणना को ठीक करें

कोड अपडेट

मैंने कोड उदाहरणों को अद्यतन किया, विशेष रूप से वैल्लोस्ट्रेस। एक प्रक्रिया के लिए सीएफजी आरक्षण खोजने के लिए 20 लाइनें शामिल हैं। मैंने टेस्ट कोड भी जोड़ा है जो CFG बिट्स के मूल्य की जांच करने के लिए SetProcessValidCallTargets का उपयोग करता है और उन्हें सफलतापूर्वक कॉल करने के लिए आवश्यक ट्रिक प्रदर्शित करता है (संकेत: GetProcAddress के माध्यम से कॉल करने से CFG का उल्लंघन होने की संभावना है!)