Cross-Device Resume को कैसे बंद करें
इस पृष्ठ पर
संक्षिप्त उत्तर
Section titled “संक्षिप्त उत्तर”Cross-Device Resume को Windows MDM-नीति के माध्यम से अक्षम किया जा सकता है। हमारे
प्रयोग में, इसे लागू करने, पुनः आरंभ करने और साइन इन करने के बाद
CrossDeviceResume.exe अवलोकन के 153 सेकंड तक शुरू नहीं हुआ।
सुविधा को दोबारा अनुमति देने और फिर से पुनः आरंभ करने पर प्रक्रिया फिर से प्रकट हुई।
BoosterX → अनुकूलन → ट्वीक → Cross-Device Resume के माध्यम से सेटिंग लागू करना आसान है: अक्षम करना चुनें, «लागू करें» दबाएँ और PC को पुनः आरंभ करें। इस शोध ने Windows के सार्वजनिक तंत्र की जाँच की, BoosterX के कार्यान्वयन की नहीं: प्रोग्राम वास्तव में सेटिंग कैसे लागू करता है, इस श्रृंखला में इसका परीक्षण नहीं किया गया और लेख में इसका दावा नहीं किया गया है। लागू करने और वापस लौटाने का विवरण सेटिंग पृष्ठ पर उपलब्ध है।
क्या जाँचा गया
Section titled “क्या जाँचा गया”हमारी रुचि केवल Resume सूचनाओं के गायब होने में नहीं, बल्कि Windows में साइन इन करते समय इसकी अलग प्रक्रिया के सामान्य प्रारंभ को रोकने में भी थी। ये अलग परिणाम हैं: प्रोग्राम शुरू होकर तुरंत समाप्त हो सकता है, सूचनाओं के बिना काम करता रह सकता है, या उसे शुरू होने का अनुरोध ही न मिले।
Microsoft DisableCrossDeviceResume को एक उपयोगकर्ता नीति के रूप में वर्णित करता है,
जो फ़ोन से काम जारी रखने की सूचनाओं को अक्षम करती है, और पुनः आरंभ करने की आवश्यकता बताता है। प्रलेखित: नीति का उद्देश्य और लागू होने का क्षण।
हमारे प्रयोग में देखा गया: अलग प्रक्रिया का प्रारंभ न होना।
Microsoft का विवरण।
शोध का दायरा
Section titled “शोध का दायरा”| शर्त | परीक्षित वातावरण |
|---|---|
| सिस्टम | Windows 11 Pro 25H2, बिल्ड 26200.9445 |
| घटक | CrossDeviceResume 2607.27000.0.0 |
| स्टैंड | एक VMware वर्चुअल मशीन |
| परिदृश्य | उसी उपयोगकर्ता का पुनः आरंभ और इंटरैक्टिव साइन इन |
| अवलोकन | प्रक्रियाओं की सूची और उनके निर्माण का ऑडिट, इवेंट 4688 |
| प्रयोग की तिथि | 2026-09-17 |
यह एक कार्यात्मक प्रयोग है, FPS या मेमोरी खपत का परीक्षण नहीं। भौतिक CPU का मॉडल, वर्चुअल संसाधनों का कॉन्फ़िगरेशन और ड्राइवर संस्करण प्रकाशित नमूने में शामिल नहीं हैं। परिणाम को भौतिक PC, अन्य बिल्ड या शुरू करने के अन्य तरीकों पर बिना जाँच के लागू नहीं किया जा सकता।
जाँच कैसे की गई
Section titled “जाँच कैसे की गई”पहले चल रही प्रक्रिया और नीति की प्रारंभिक स्थिति दर्ज की गई। फिर Windows के स्थानीय प्रबंधन तंत्र के माध्यम से निषेधात्मक नीति लागू की, ऑपरेशन की सफलता जाँची और स्थिति वापस पढ़ी। पुनः आरंभ के बाद इंटरैक्टिव साइन इन और शेल के काम शुरू होने की प्रतीक्षा की, प्रक्रियाएँ और उनके निर्माण का लॉग जाँचा।
विपरीत नियंत्रण के लिए Resume को अनुमति दी और साइन इन के साथ पुनः आरंभ दोहराया। अलग से सुविधा को फिर से प्रतिबंधित किया, पहले से चल रही प्रक्रिया को स्पष्ट रूप से समाप्त किया और संभावित पुनः प्रारंभ का अवलोकन किया। प्रक्रिया को समाप्त करना स्वतंत्र कार्रवाई थी, इसे नीति का श्रेय नहीं दिया जा सकता।
Registry में प्रविष्टि अभी अक्षमता सिद्ध क्यों नहीं करती
Section titled “Registry में प्रविष्टि अभी अक्षमता सिद्ध क्यों नहीं करती”Registry में आवश्यक संख्या की उपस्थिति यह पुष्टि नहीं करती कि Windows ने इसे वैध MDM-नीति के रूप में स्वीकार किया। इसलिए «मान लिखा है, फिर भी CrossDeviceResume शुरू होता है» स्थिति इस शोध के परिणाम का खंडन नहीं करती।
इस नीति के प्रकाशित दस्तावेज़ में सामान्य Registry-सेटिंग से तैयार मेल नहीं है। हमारी श्रृंखला में सीधी प्रविष्टि के सभी विकल्पों की अलग नियंत्रित तुलना नहीं है। सीधी प्रविष्टि नीति लागू करने के विकल्प के रूप में पुष्ट नहीं है, लेकिन यह दावा करने का भी आधार नहीं है कि Registry का कोई भी संशोधन हमेशा निष्फल है। कार्यशील परिणाम नीति प्रबंधन तंत्र के माध्यम से प्राप्त हुआ, स्थिति की जाँच और साइन इन के बाद वास्तविक प्रारंभ के साथ।
सिस्टम DLL की भूमिका और प्रयोगशाला बाईपास
Section titled “सिस्टम DLL की भूमिका और प्रयोगशाला बाईपास”प्रयोग में अंतर्निहित mdmlocalmanagement.dll का उपयोग किया गया। यह
स्थानीय प्रबंधन का इंटरफ़ेस प्रदान करता है: RegisterDeviceWithLocalManagement और
ApplyLocalManagementSyncML。उनकी घोषणाएँ
Windows SDK के सार्वजनिक हेडर में उपलब्ध हैं।
सिस्टम लाइब्रेरी ने नीति लागू करने का अनुरोध स्वीकार किया; तृतीय-पक्ष
DLL डाउनलोड करने, Windows फ़ाइलें बदलने या निष्पादन योग्य कोड को पैच करने की आवश्यकता नहीं पड़ी।
Intune और क्लाउड प्रबंधन का उपयोग अनुभव में नहीं किया गया।
परीक्षित Windows Pro पर सामान्य स्थानीय पंजीकरण ने «समर्थित नहीं» लौटाया। प्रयोगशाला में Embedded Mode को अस्थायी रूप से सक्षम करके इस प्रतिबंध को पार करना संभव हुआ, जिसके बाद नीति लागू की और मोड का मूल पैरामीटर बहाल किया। Microsoft Embedded Mode को विशेष उपकरणों के संदर्भ में वर्णित करता है Windows IoT। Pro पर ऐसा उपयोग Microsoft द्वारा पुष्ट समर्थन परिदृश्य नहीं है।
अस्थायी मोड की बहाली ने स्थानीय प्रबंधन पंजीकरण और निर्धारित नीति को नहीं हटाया। परीक्षित परिदृश्य के बाहर मोड को अस्थायी रूप से सक्षम करने के दुष्प्रभावों की जाँच नहीं की गई। यहाँ प्रयोग का सिद्धांत वर्णित है; कमांड, अनुरोध की सामग्री और बाईपास को दोहराने का क्रम प्रकाशित नहीं किए जाते।
परिणाम
Section titled “परिणाम”| जाँच | परिणाम और निष्कर्ष की सीमा |
|---|---|
| निषेधात्मक नीति लागू करना | ऑपरेशन सफल, वापस पढ़ने ने स्थिति की पुष्टि की |
| पहले से चल रही प्रक्रिया | स्वचालित रूप से समाप्त नहीं हुई |
| प्रतिबंध के साथ पुनः आरंभ और साइन इन | प्रक्रिया अनुपस्थित थी; शेल शुरू होने के बाद 153 सेकंड तक उसका कोई प्रारंभ दर्ज नहीं हुआ |
| अनुमति, पुनः आरंभ और साइन इन | प्रक्रिया प्रकट हुई, निर्माण की पुष्टि लॉग ने की |
| दोबारा प्रतिबंध और प्रक्रिया की अलग समाप्ति | 10 सेकंड बाद प्रक्रिया अनुपस्थित थी; अवलोकन के 120 सेकंड तक पुनः प्रारंभ नहीं मिला |
| स्टैंड का पूर्ण रोलबैक | VM स्नैपशॉट से प्रारंभिक स्थिति बहाल की गई और जाँची गई |
नमूने में एक VM और जाँचों का एक क्रम है। 120-सेकंड के अंतराल के भीतर बार-बार किए गए अवलोकन स्वतंत्र प्रयोग नहीं हैं। दूसरे कंप्यूटर पर स्वतंत्र पुनरुत्पादन नहीं है।
क्या पुष्ट हुआ
Section titled “क्या पुष्ट हुआ”- परीक्षित परिदृश्य में नीति ने पुनः आरंभ और साइन इन के बाद अलग प्रक्रिया के सामान्य प्रारंभ को रोका।
- सुविधा को दोबारा अनुमति देने से उसी स्टैंड पर प्रारंभ लौट आया।
- नीति लागू करना अपने आप में पहले से चल रही प्रक्रिया को बंद नहीं करता।
- प्राप्त परिणाम के लिए सिस्टम DLL बदलने या EXE पैच करने की आवश्यकता नहीं पड़ी।
रोका गया प्रारंभ अवलोकित परिदृश्य में इस प्रक्रिया के काम को बाहर करता है। यह अनावश्यक पृष्ठभूमि सुविधा को अक्षम करने का ठोस प्रभाव है, भले ही FPS मापा न गया हो।
क्या पुष्ट नहीं हुआ
Section titled “क्या पुष्ट नहीं हुआ”FPS में वृद्धि, frametime में परिवर्तन, कुल CPU लोड और RAM की बचत मापी नहीं गई।
EXE का मैनुअल प्रारंभ, सक्रियण के सभी वैकल्पिक तरीके, ShellHost के भीतर
Resume की नियुक्ति और किसी अन्य खाते या SYSTEM से काम की जाँच नहीं की गई।
इस श्रृंखला में तैयार BoosterX इंटरफ़ेस के माध्यम से लागू करने का अलग युग्म परीक्षण नहीं था:
तालिका Windows के प्रयोगशाला तंत्र का वर्णन करती है।
सीमाएँ
Section titled “सीमाएँ”जाँच की तिथि पर Microsoft नीति को Windows Insider Preview पर लागू होने योग्य चिह्नित करता है। उल्लिखित Windows 11 Pro 25H2 पर अवलोकन आधिकारिक समर्थन मैट्रिक्स का विकल्प नहीं है। अन्य नियोजित VM पर जाँच नहीं हो सकी, इसलिए उसके परिणाम नहीं हैं। 153 सेकंड तक इवेंट का अभाव किसी भी प्रारंभ के सदा के लिए प्रतिबंध का अर्थ नहीं रखता: पुष्ट प्रभाव पुनः आरंभ और साइन इन के बाद सामान्य प्रारंभ से संबंधित है, और अन्य तरीकों से प्रक्रिया के प्रारंभ का इस शोध में अध्ययन नहीं किया गया।
लेख यह निर्धारित नहीं करता कि BoosterX अपनी सेटिंग किस तरीके से लागू करता है। BoosterX कार्ड और यहाँ परीक्षित MDM-नीति के बीच संबंध प्रयोग की योजना में शामिल नहीं था; प्रोग्राम यही तंत्र उपयोग करता है या नहीं, इसका निर्णय एप्लिकेशन के वास्तविक व्यवहार की अलग जाँच की माँग करता है।
अक्षमता Resume से संबंधित है। इसे पूरी «फ़ोन से कनेक्शन» या Windows के पूरे अंतर-उपकरण ढाँचे को अक्षम करने के रूप में वर्णित नहीं किया जा सकता।
व्यावहारिक निष्कर्ष
Section titled “व्यावहारिक निष्कर्ष”यदि आप फ़ोन से काम जारी रखने का उपयोग नहीं करते, तो Resume को अक्षम करना उचित है। परीक्षित स्टैंड पर MDM-नीति ने इसके सामान्य प्रारंभ से बचने में मदद की। उपयोगकर्ता के लिए BoosterX में मौजूद सेटिंग चुनना और PC को पुनः आरंभ करना नीति भंडार के साथ मैनुअल प्रयोग से आसान है। परिणाम को अपने Windows संस्करण पर जाँचें।
स्थिति बहाल करना
Section titled “स्थिति बहाल करना”प्रयोग में सुविधा को अनुमति देने और फिर से पुनः आरंभ करने से प्रक्रिया का प्रारंभ लौट आया। फिर VM को मूल स्नैपशॉट से पूरी तरह बहाल किया: जाँच के दौरान निर्धारित नीति की अनुपस्थिति, मोड की प्रारंभिक स्थिति, अस्थायी ऑटोसाइन-इन की रद्दगी और प्रक्रिया की वापसी जाँची।
BoosterX में उसी कार्ड में सक्षम करने से लागू करने और पुनः आरंभ के बाद Resume की अनुमति मिलती है। यह स्नैपशॉट रोलबैक का पूर्ण समानार्थी नहीं है: प्रयोगशाला में नीति लागू करने से बना स्थानीय प्रबंधन पंजीकरण बना रहता है, जैसे अन्य टूल के पहले लागू प्रतिबंध। वापस लौटाने का विवरण सेटिंग पृष्ठ पर दिया गया है।
सार्वजनिक प्राथमिक स्रोत
Section titled “सार्वजनिक प्राथमिक स्रोत”- Microsoft: Connectivity / DisableCrossDeviceResume: नीति का उद्देश्य, उपयोगकर्ता का दायरा और पुनः आरंभ; हमारी VM के परिणामों का प्रमाण नहीं।
- Microsoft Windows SDK: mdmlocalmanagement.h: स्थानीय प्रबंधन इंटरफ़ेस की घोषणाएँ; किसी भी संस्करण पर उपलब्धता का वादा नहीं।
- Microsoft: Embedded Mode: Windows IoT का संदर्भ; Pro पर समर्थित उपयोग के निर्देश नहीं।
शोध और उपयोग किए गए उपकरण BoosterX के डेवलपर के हैं, इसलिए डेवलपर का परिणामों में सीधा हित है। कार्यप्रणाली और प्रयोज्यता की सीमाएँ ऊपर वर्णित हैं, और निष्कर्षों को खुले डेटा तथा सूचीबद्ध सार्वजनिक स्रोतों से जाँचा जा सकता है। Microsoft इस शोध का लेखक नहीं है और उसने इसके निष्कर्षों की पुष्टि नहीं की है।
जाँच की तिथि और परिवर्तन इतिहास
Section titled “जाँच की तिथि और परिवर्तन इतिहास”2026-09-17: पहला संस्करण; सार्वजनिक स्रोत जाँचे गए, एक VM के परिणाम, निष्कर्ष की सीमाएँ और प्रारंभ की विपरीत जाँच प्रकाशित की गई।
2026-09-19: स्वतंत्र सत्यापन के बाद निष्कर्ष का ढाँचा सुधारा गया: BoosterX के विशिष्ट तंत्र का दावा हटाया गया। शोध Windows की सार्वजनिक MDM-नीति और उसे लागू करने के प्रयोगशाला मार्ग की जाँच करता है, प्रोग्राम में सेटिंग के कार्यान्वयन की नहीं; प्रयोग के परिणाम, निष्कर्ष की सीमाएँ और स्रोत सुरक्षित रखे गए, पुष्ट प्रभाव की सीमाओं पर टिप्पणियाँ स्पष्ट की गईं।
2026-09-20: हितों के टकराव का डिस्क्लेमर मजबूत किया गया: शोध और उपकरणों के स्वामी डेवलपर के सीधे हित को स्पष्ट रूप से स्वीकार किया गया; description संक्षिप्त किया गया।
