Cross-Device Resume বন্ধ করার উপায়
На этой странице
সংক্ষিপ্ত উত্তর
Заголовок раздела «সংক্ষিপ্ত উত্তর»Cross-Device Resume Windows-এর MDM নীতির মাধ্যমে বন্ধ করা যায়। আমাদের
পরীক্ষায় এটি প্রয়োগ, পুনরায় বুট এবং সাইন-ইনের পর
CrossDeviceResume.exe 153 সেকেন্ড পর্যবেক্ষণকালে চালু হয়নি।
ফিচারটি আবার অনুমোদন করে পুনরায় বুট করার পর প্রক্রিয়াটি আবার দেখা গেছে।
BoosterX → অপ্টিমাইজেশন → টুইক → Cross-Device Resume-এর মাধ্যমে সেটিং প্রয়োগ করা সহজ: বন্ধ করার বিকল্প বেছে নিন, «প্রয়োগ করুন» চাপুন এবং পিসি পুনরায় বুট করুন। এই গবেষণাটি Windows-এর একটি প্রকাশ্য প্রক্রিয়া যাচাই করেছে, BoosterX-এর বাস্তবায়ন নয়: প্রোগ্রামটি ঠিক কীভাবে সেটিং প্রয়োগ করে, তা এই সিরিজে পরীক্ষা করা হয়নি এবং নিবন্ধে দাবি করা হয়নি। প্রয়োগ ও ফেরানোর বিস্তারিত আছে সেটিং পৃষ্ঠায়।
কী যাচাই করা হয়েছে
Заголовок раздела «কী যাচাই করা হয়েছে»আমাদের আগ্রহ ছিল শুধু Resume বিজ্ঞপ্তি অদৃশ্য হওয়া নয়, Windows-এ সাইন-ইনের সময় এর আলাদা প্রক্রিয়ার স্বাভাবিক চালু হওয়া প্রতিরোধও। এগুলো ভিন্ন ফলাফল: প্রোগ্রামটি চালু হয়ে সঙ্গে সঙ্গে শেষ হতে পারে, বিজ্ঞপ্তি ছাড়াই চলতে থাকতে পারে, বা চালু হওয়ার অনুরোধই না পেতে পারে।
Microsoft DisableCrossDeviceResume-কে একটি ব্যবহারকারী নীতি হিসেবে বর্ণনা করে,
যা ফোন থেকে কাজ চালিয়ে যাওয়ার বিজ্ঞপ্তি বন্ধ করে, এবং পুনরায় বুট করার প্রয়োজনীয়তা উল্লেখ করে।
নথিভুক্ত: নীতির উদ্দেশ্য ও প্রয়োগের সময়। আমাদের পরীক্ষায় পর্যবেক্ষিত: আলাদা প্রক্রিয়ার চালু না হওয়া।
Microsoft-এর বিবরণ।
গবেষণার পরিধি
Заголовок раздела «গবেষণার পরিধি»| শর্ত | পরীক্ষিত পরিবেশ |
|---|---|
| সিস্টেম | Windows 11 Pro 25H2, বিল্ড 26200.9445 |
| উপাদান | CrossDeviceResume 2607.27000.0.0 |
| স্ট্যান্ড | একটি VMware ভার্চুয়াল মেশিন |
| দৃশ্যপট | একই ব্যবহারকারীর পুনরায় বুট ও ইন্টারঅ্যাকটিভ সাইন-ইন |
| পর্যবেক্ষণ | প্রক্রিয়ার তালিকা ও তাদের সৃষ্টির অডিট, ইভেন্ট 4688 |
| পরীক্ষার তারিখ | 2026-09-17 |
এটি একটি কার্যকরী পরীক্ষা, FPS বা মেমরি ব্যবহারের পরীক্ষা নয়। ভৌত CPU-এর মডেল, ভার্চুয়াল রিসোর্সের কনফিগারেশন এবং ড্রাইভার সংস্করণ প্রকাশিত নমুনায় অন্তর্ভুক্ত নয়। যাচাই ছাড়া ফলাফল ভৌত পিসি, অন্য বিল্ড বা চালু করার অন্য উপায়ে প্রয়োগ করা যাবে না।
যাচাই কীভাবে করা হয়েছে
Заголовок раздела «যাচাই কীভাবে করা হয়েছে»প্রথমে চলমান প্রক্রিয়া ও নীতির প্রাথমিক অবস্থা লিপিবদ্ধ করা হয়েছে। তারপর Windows-এর স্থানীয় ব্যবস্থাপনা প্রক্রিয়ার মাধ্যমে নিষিদ্ধকারী নীতি প্রয়োগ করা হয়েছে, কাজটি সফল হয়েছে কি না যাচাই করা হয়েছে এবং অবস্থা আবার পড়া হয়েছে। পুনরায় বুটের পর ইন্টারঅ্যাকটিভ সাইন-ইন ও শেল চালু হওয়ার জন্য অপেক্ষা করা হয়েছে, প্রক্রিয়া ও তাদের সৃষ্টির লগ যাচাই করা হয়েছে।
বিপরীত নিয়ন্ত্রণের জন্য Resume অনুমোদন করা হয়েছে এবং সাইন-ইনসহ পুনরায় বুট পুনরাবৃত্তি করা হয়েছে। আলাদাভাবে আবার ফিচারটি নিষিদ্ধ করা হয়েছে, ইতিমধ্যে চলমান প্রক্রিয়া স্পষ্টভাবে শেষ করা হয়েছে এবং সম্ভাব্য পুনরায় চালু হওয়া পর্যবেক্ষণ করা হয়েছে। প্রক্রিয়া শেষ করা একটি স্বতন্ত্র কাজ ছিল, এটি নীতির কৃতিত্ব হিসেবে ধরা যাবে না।
কেন রেজিস্ট্রিতে লেখা এখনও বন্ধ হওয়া প্রমাণ করে না
Заголовок раздела «কেন রেজিস্ট্রিতে লেখা এখনও বন্ধ হওয়া প্রমাণ করে না»রেজিস্ট্রিতে প্রয়োজনীয় সংখ্যার উপস্থিতি নিশ্চিত করে না যে Windows এটিকে কার্যকর MDM নীতি হিসেবে গ্রহণ করেছে। তাই «মান লেখা হয়েছে, কিন্তু CrossDeviceResume তবুও চালু হচ্ছে» পরিস্থিতি এই গবেষণার ফলাফলের সঙ্গে সাংঘর্ষিক নয়।
এই নীতির প্রকাশিত ডকুমেন্টেশনে সাধারণ Registry-সেটিংয়ের কোনো প্রস্তুত মিল নেই। আমাদের সিরিজে সরাসরি লেখার সব বিকল্পের আলাদা নিয়ন্ত্রিত তুলনা নেই। নীতি প্রয়োগের বিকল্প হিসেবে সরাসরি লেখা নিশ্চিত নয়, তবে যেকোনো রেজিস্ট্রি সম্পাদনা সবসময় অকার্যকর, এমন দাবি করারও ভিত্তি নেই। কার্যকর ফলাফল পাওয়া গেছে নীতি ব্যবস্থাপনার প্রক্রিয়ার মাধ্যমে, অবস্থা ও সাইন-ইনের পর প্রকৃত চালু হওয়া যাচাই করে।
সিস্টেম DLL ও ল্যাবরেটরি বাইপাসের ভূমিকা
Заголовок раздела «সিস্টেম DLL ও ল্যাবরেটরি বাইপাসের ভূমিকা»পরীক্ষায় অন্তর্নির্মিত mdmlocalmanagement.dll ব্যবহার করা হয়েছে। এটি
স্থানীয় ব্যবস্থাপনার ইন্টারফেস প্রদান করে: RegisterDeviceWithLocalManagement এবং
ApplyLocalManagementSyncML। তাদের ঘোষণা পাওয়া যায়
Windows SDK-এর প্রকাশ্য হেডারে।
সিস্টেম লাইব্রেরি নীতি প্রয়োগের অনুরোধ গ্রহণ করেছে; তৃতীয় পক্ষের
DLL ডাউনলোড, Windows ফাইল প্রতিস্থাপন বা এক্সিকিউটেবল কোড প্যাচ করার প্রয়োজন হয়নি।
Intune ও ক্লাউড ব্যবস্থাপনা পরীক্ষায় ব্যবহার করা হয়নি।
পরীক্ষিত Windows Pro-তে সাধারণ স্থানীয় নিবন্ধন «সমর্থিত নয়» ফিরিয়েছে। ল্যাবরেটরিতে সাময়িকভাবে Embedded Mode চালু করে এই সীমাবদ্ধতা অতিক্রম করা গেছে, এরপর নীতি প্রয়োগ ও মোডের প্রাথমিক প্যারামিটার পুনরুদ্ধার করা হয়েছে। Microsoft বিশেষায়িত ডিভাইসের প্রসঙ্গে Embedded Mode বর্ণনা করে Windows IoT। Pro-তে এমন ব্যবহার Microsoft-সমর্থিত দৃশ্যপট নয়।
সাময়িক মোড পুনরুদ্ধার স্থানীয় ব্যবস্থাপনা নিবন্ধন ও নির্ধারিত নীতি মুছেনি। পরীক্ষিত দৃশ্যপটের বাইরে সাময়িক মোড চালুর পার্শ্বপ্রতিক্রিয়া গবেষণা করা হয়নি। এখানে পরীক্ষার নীতি বর্ণনা করা হয়েছে; কমান্ড, অনুরোধের বিষয়বস্তু এবং বাইপাস পুনরুৎপাদনের ক্রম প্রকাশ করা হয় না।
| যাচাই | ফলাফল ও সিদ্ধান্তের সীমা |
|---|---|
| নিষিদ্ধকারী নীতি প্রয়োগ | কাজ সফল, বিপরীত পাঠ অবস্থা নিশ্চিত করেছে |
| ইতিমধ্যে চলমান প্রক্রিয়া | স্বয়ংক্রিয়ভাবে শেষ হয়নি |
| নিষেধসহ পুনরায় বুট ও সাইন-ইন | প্রক্রিয়া অনুপস্থিত ছিল; শেল চালু হওয়ার পর 153 সেকেন্ডে এর কোনো চালু হওয়া নিবন্ধিত হয়নি |
| অনুমোদন, পুনরায় বুট ও সাইন-ইন | প্রক্রিয়া দেখা গেছে, সৃষ্টি লগে নিশ্চিত |
| আবার নিষেধ ও আলাদাভাবে প্রক্রিয়া শেষ করা | 10 সেকেন্ড পর প্রক্রিয়া অনুপস্থিত ছিল; 120 সেকেন্ড পর্যবেক্ষণে পুনরায় চালু পাওয়া যায়নি |
| স্ট্যান্ডের সম্পূর্ণ রোলব্যাক | VM স্ন্যাপশট দিয়ে প্রাথমিক অবস্থা পুনরুদ্ধার ও যাচাই করা হয়েছে |
নমুনায় একটি VM ও যাচাইয়ের একটি ক্রম। 120-সেকেন্ডের ব্যবধানের ভেতরের পুনরাবৃত্ত পর্যবেক্ষণ স্বাধীন পরীক্ষা নয়। দ্বিতীয় কম্পিউটারে স্বাধীন পুনরুৎপাদন নেই।
কী নিশ্চিত হয়েছে
Заголовок раздела «কী নিশ্চিত হয়েছে»- পরীক্ষিত দৃশ্যপটে নীতি পুনরায় বুট ও সাইন-ইনের পর আলাদা প্রক্রিয়ার স্বাভাবিক চালু হওয়া প্রতিরোধ করেছে।
- ফিচার আবার অনুমোদন করলে একই স্ট্যান্ডে চালু হওয়া ফিরে এসেছে।
- নীতি প্রয়োগ নিজে থেকে ইতিমধ্যে চলমান প্রক্রিয়া বন্ধ করে না।
- প্রাপ্ত ফলাফলের জন্য সিস্টেম DLL প্রতিস্থাপন বা EXE প্যাচের প্রয়োজন হয়নি।
প্রতিরোধিত চালু হওয়া পর্যবেক্ষিত দৃশ্যপটে এই প্রক্রিয়ার কাজ বাদ দেয়। এটি অপ্রয়োজনীয় পটভূমি ফিচার বন্ধ করার একটি নির্দিষ্ট প্রভাব, এমনকি FPS মাপা না হলেও।
কী নিশ্চিত হয়নি
Заголовок раздела «কী নিশ্চিত হয়নি»FPS বৃদ্ধি, frametime পরিবর্তন, মোট CPU লোড ও RAM সাশ্রয় মাপা হয়নি।
EXE ম্যানুয়ালি চালু করা, সক্রিয় করার সব বিকল্প উপায়, ShellHost-এর ভেতরে
Resume রাখা এবং অন্য অ্যাকাউন্ট বা SYSTEM থেকে কাজ যাচাই করা হয়নি।
এই সিরিজে প্রস্তুত BoosterX ইন্টারফেসের মাধ্যমে প্রয়োগের আলাদা জোড়া
পরীক্ষা ছিল না: সারণিটি Windows-এর ল্যাবরেটরি প্রক্রিয়া বর্ণনা করে।
সীমাবদ্ধতা
Заголовок раздела «সীমাবদ্ধতা»যাচাইয়ের তারিখে Microsoft নীতিটিকে Windows Insider Preview-এর জন্য প্রযোজ্য হিসেবে চিহ্নিত করে। উল্লিখিত Windows 11 Pro 25H2-এ পর্যবেক্ষণ সরকারি সমর্থন ম্যাট্রিক্সের বিকল্প নয়। পরিকল্পিত অন্য VM-এ যাচাই হয়নি, তাই তার ফলাফল নেই। 153 সেকেন্ডে ইভেন্টের অনুপস্থিতি চিরকালের জন্য যেকোনো চালু হওয়া নিষিদ্ধ বোঝায় না: নিশ্চিত প্রভাব পুনরায় বুট ও সাইন-ইনের পর স্বাভাবিক চালু হওয়া সম্পর্কিত, আর অন্য উপায়ে প্রক্রিয়া চালু হওয়া এই গবেষণায় অধ্যয়ন করা হয়নি।
নিবন্ধটি নির্ধারণ করে না BoosterX কোন উপায়ে তার সেটিং প্রয়োগ করে। BoosterX কার্ড ও এখানে যাচাই করা MDM নীতির মধ্যে সম্পর্ক পরীক্ষার পরিকল্পনায় ছিল না; প্রোগ্রামটি এই একই প্রক্রিয়া ব্যবহার করে কি না, সেই বিচারের জন্য অ্যাপ্লিকেশনের প্রকৃত আচরণ অনুযায়ী আলাদা যাচাই দরকার।
বন্ধ করা Resume সম্পর্কিত। এটিকে সম্পূর্ণ «ফোনের সঙ্গে সংযোগ» বা Windows-এর সম্পূর্ণ আন্তঃডিভাইস অবকাঠামো বন্ধ করা হিসেবে বর্ণনা করা যাবে না।
ব্যবহারিক সিদ্ধান্ত
Заголовок раздела «ব্যবহারিক সিদ্ধান্ত»যদি ফোন থেকে কাজ চালিয়ে যাওয়া ব্যবহার না করেন, Resume বন্ধ করা যুক্তিসঙ্গত। পরীক্ষিত স্ট্যান্ডে MDM নীতি এর স্বাভাবিক চালু হওয়া এড়াতে পেরেছে। ব্যবহারকারীর জন্য BoosterX-এ বিদ্যমান সেটিং বেছে নিয়ে পিসি পুনরায় বুট করা নীতির ভাণ্ডার নিয়ে হাতে-কলমে পরীক্ষার চেয়ে সহজ। নিজের Windows সংস্করণে ফলাফল যাচাই করুন।
অবস্থা পুনরুদ্ধার
Заголовок раздела «অবস্থা পুনরুদ্ধার»পরীক্ষায় ফিচার অনুমোদন ও পুনরায় বুট প্রক্রিয়ার চালু হওয়া ফিরিয়ে এনেছে। তারপর VM সম্পূর্ণভাবে প্রাথমিক স্ন্যাপশট থেকে পুনরুদ্ধার করা হয়েছে: যাচাইয়ের সময় নির্ধারিত নীতির অনুপস্থিতি, মোডের প্রাথমিক অবস্থা, সাময়িক অটোসাইন-ইনের বাতিল এবং প্রক্রিয়ার প্রত্যাবর্তন যাচাই করা হয়েছে।
BoosterX-এ একই কার্ডে চালু করলে প্রয়োগ ও পুনরায় বুটের পর Resume অনুমোদিত হয়। এটি স্ন্যাপশট রোলব্যাকের সম্পূর্ণ সমতুল্য নয়: ল্যাবরেটরি নীতি প্রয়োগে সৃষ্ট স্থানীয় ব্যবস্থাপনা নিবন্ধন সংরক্ষিত থাকে, যেমন অন্যান্য টুলের আগে প্রয়োগ করা সীমাবদ্ধতাও। ফেরানোর বিস্তারিত আছে সেটিং পৃষ্ঠায়।
প্রকাশ্য প্রাথমিক সূত্র
Заголовок раздела «প্রকাশ্য প্রাথমিক সূত্র»- Microsoft: Connectivity / DisableCrossDeviceResume: নীতির উদ্দেশ্য, ব্যবহারকারী পরিধি ও পুনরায় বুট; আমাদের VM-এর ফলাফলের প্রমাণ নয়।
- Microsoft Windows SDK: mdmlocalmanagement.h: স্থানীয় ব্যবস্থাপনার ইন্টারফেসের ঘোষণা; যেকোনো সংস্করণে উপলব্ধতার প্রতিশ্রুতি নয়।
- Microsoft: Embedded Mode: Windows IoT-এর প্রসঙ্গ; Pro-তে সমর্থিত প্রয়োগের নির্দেশিকা নয়।
গবেষণা ও ব্যবহৃত টুল BoosterX-এর ডেভেলপারের মালিকানাধীন, তাই ফলাফলে ডেভেলপারের সরাসরি স্বার্থ আছে। পদ্ধতি ও প্রযোজ্যতার সীমা উপরে বর্ণিত, আর সিদ্ধান্ত খোলা তথ্য ও তালিকাভুক্ত প্রকাশ্য সূত্র থেকে যাচাই করা যায়। Microsoft এই গবেষণার লেখক নয় এবং এর সিদ্ধান্ত নিশ্চিত করেনি।
যাচাইয়ের তারিখ ও পরিবর্তনের ইতিহাস
Заголовок раздела «যাচাইয়ের তারিখ ও পরিবর্তনের ইতিহাস»2026-09-17: প্রথম সংস্করণ; প্রকাশ্য সূত্র যাচাই করা হয়েছে, একটি VM-এর ফলাফল, সিদ্ধান্তের সীমা ও চালু হওয়ার বিপরীত যাচাই প্রকাশ করা হয়েছে।
2026-09-19: স্বাধীন মিলিয়ে দেখার পর সিদ্ধান্তের কাঠামো সংশোধিত: BoosterX-এর নির্দিষ্ট প্রক্রিয়া সম্পর্কিত দাবি সরানো হয়েছে। গবেষণাটি Windows-এর প্রকাশ্য MDM নীতি ও তার প্রয়োগের ল্যাবরেটরি পথ যাচাই করে, প্রোগ্রামে সেটিংয়ের বাস্তবায়ন নয়; পরীক্ষার ফলাফল, সিদ্ধান্তের সীমা ও সূত্র সংরক্ষিত, নিশ্চিত প্রভাবের সীমা সম্পর্কিত শর্তাবলি স্পষ্ট করা হয়েছে।
2026-09-20: স্বার্থের সংঘাত সম্পর্কিত ডিসক্লেইমার জোরদার: গবেষণা ও টুলের মালিক ডেভেলপারের সরাসরি স্বার্থ স্পষ্টভাবে স্বীকার করা হয়েছে; description সংক্ষিপ্ত করা হয়েছে।