Active Restore- ဘေးဥပဒ်ပြန်လည်ရယူခြင်းက ပိုမြန်နိုင်ပါသလား။ အများကြီးမြန်သလား။

အရေးကြီးသောဒေတာကို အရန်ကူးခြင်းသည် ကောင်းမွန်သောအရာဖြစ်သည်။ သို့သော် အလုပ်ချက်ချင်းဆက်လုပ်ရန် လိုအပ်ပြီး မိနစ်တိုင်း ရေတွက်လျှင်ကော။ Acronis မှကျွန်ုပ်တို့သည်စနစ်စတင်ခြင်းပြဿနာကိုတတ်နိုင်သမျှအမြန်ဆုံးဖြေရှင်းရန်မည်မျှဖြစ်နိုင်သည်ကိုစစ်ဆေးရန်ဆုံးဖြတ်ခဲ့သည်။ ၎င်းသည် Innopolis University နှင့် ကျွန်ုပ်တို့ ပရောဂျက်ကို မည်သို့စတင်ခဲ့သည်၊ မည်သို့သောဖြေရှင်းချက်နှင့် ယနေ့ကျွန်ုပ်တို့လုပ်ဆောင်နေလဲဆိုတာကို ပြောပြပေးမည့် Active Restore စီးရီး၏ ပထမဆုံး ပို့စ်ဖြစ်ပါသည်။ အသေးစိတ်အချက်အလတ်တွေကို အောက်မှာဖော်ပြထားပါတယ်။

မင်္ဂလာပါ! ကျွန်ုပ်၏အမည်မှာ Daulet Tumbayev ဖြစ်ပြီး၊ ယနေ့ ကျွန်ုပ်သည် သဘာဝဘေးအန္တရာယ် ပြန်လည်ထူထောင်ရေးကို အရှိန်မြှင့်ပေးသည့် စနစ်တစ်ခုကို တီထွင်ရာတွင် ကျွန်ုပ်၏အတွေ့အကြုံကို မျှဝေလိုပါသည်။ ပရောဂျက်၏ ဖွံ့ဖြိုးတိုးတက်ရေးလမ်းကြောင်းတစ်ခုလုံးအကြောင်း ပြောရန်၊ ခပ်ဝေးဝေးမှ စတင်ကြပါစို့။ ကျွန်ုပ်သည် လက်ရှိ Acronis တွင် အလုပ်လုပ်နေသော်လည်း ကျွန်ုပ်သည် Software Development Management (MSIT-SE ဟုလူသိများ) တွင် Master's Program ကို ပြီးမြောက်ခဲ့သော Innopolis တက္ကသိုလ်မှ ဘွဲ့ရတစ်ဦးဖြစ်သည်။ Innopolis သည် ငယ်ရွယ်သော တက္ကသိုလ်တစ်ခုဖြစ်ပြီး သင်ရိုးညွှန်းတမ်းသည် ငယ်သေးသည်။ သို့သော် ၎င်းသည် စက်မှုပရောဂျက်များကဲ့သို့ ခေါင်းစဉ်ပါ၀င်သည့် Carnegie Mellon University ၏ သင်ရိုးညွှန်းတမ်းပေါ်တွင် တည်ဆောက်ထားသည်။

စက်မှုလုပ်ငန်းပရောဂျက်၏ ရည်ရွယ်ချက်မှာ ကျောင်းသားအား စစ်မှန်သော ဖွံ့ဖြိုးတိုးတက်မှုတွင် နှစ်မြှုပ်ပြီး ရရှိလာသော အသိပညာများကို လက်တွေ့တွင် စုစည်းရန်ဖြစ်သည်။ ထိုသို့လုပ်ဆောင်ရန်အတွက် တက္ကသိုလ်သည် Yandex၊ Acronis၊ MTC နှင့် အခြားဒါဇင်များစွာသောကုမ္ပဏီများနှင့် ပူးပေါင်းဆောင်ရွက်သည် (စုစုပေါင်း၊ 2018 ခုနှစ်အထိ၊ တက္ကသိုလ်တွင် လုပ်ဖော်ကိုင်ဖက် ၁၄၄ ခုရှိသည်)။ ပူးပေါင်းဆောင်ရွက်မှုသင်တန်းတွင် ကုမ္ပဏီများသည် ၎င်းတို့၏လုပ်ငန်းခွင်များကို တက္ကသိုလ်သို့ ကမ်းလှမ်းကြပြီး ကျောင်းသားများသည် ၎င်းတို့၏ စိတ်ဝင်စားမှုနှင့် လေ့ကျင့်မှုအဆင့်နှင့် ပိုမိုနီးစပ်သော ပရောဂျက်များထဲမှ တစ်ခုကို ရွေးချယ်ကြသည်။ လွန်ခဲ့သောနှစ်နှစ်ခန့်က ကျွန်ုပ်သည် “အတားအဆီးများ၏တစ်ဖက်ခြမ်းတွင်” ရှိနေဆဲဖြစ်ပြီး အခြားသော Acronis ပရောဂျက်တွင် ကျောင်းသားတစ်ဦးအဖြစ် လုပ်ဆောင်ခဲ့သည်။ ဒါပေမယ့် ဒီတစ်ကြိမ်မှာတော့ ကျွန်တော်ဟာ ကုမ္ပဏီဘက်က ကျောင်းသားတွေအတွက် နည်းပညာပိုင်းဆိုင်ရာ အတိုင်ပင်ခံဖြစ်လာပြီး Active Restore ပရောဂျက်ကို Innopolis ကို အဆိုပြုခဲ့ပါတယ်။ Active Restore ၏ စိတ်ကူးကို Acronis မှ Kernel အဖွဲ့မှ ရေးဆွဲခဲ့သော်လည်း ဖြေရှင်းချက်၏ ဖွံ့ဖြိုးတိုးတက်မှုကို Innopolis တက္ကသိုလ်နှင့် အတူ စတင်ခဲ့သည်။

Active Restore – ဘာကြောင့် လိုအပ်တာလဲ။

အစဉ်အလာအားဖြင့်၊ သဘာဝဘေးအန္တရာယ် ပြန်လည်ထူထောင်ရေးသည် စံအစီအစဥ်အရ လုပ်ဆောင်သည်။ သင့်ကွန်ပြူတာတွင် ပြဿနာများပြီးနောက်၊ သင်သည် အရန်စနစ်အချို့၏ ဝဘ်အင်တာဖေ့စ်သို့ သွားရန်၊ ဥပမာ၊ Acronis True Image သို့သွားပြီး ကြီးမားသော “ပြန်ယူခြင်း” ခလုတ်ကို နှိပ်ပါ။ ထို့နောက် N မိနစ်စောင့်ဆိုင်းရန် လိုအပ်ပြီး ၎င်းနောက်မှသာ သင် ဆက်လက်လုပ်ဆောင်နိုင်မည်ဖြစ်သည်။

ပြဿနာမှာ ဤနံပါတ် N၊ RTO (ပြန်လည်ရယူချိန် ရည်မှန်းချက်)၊ ခွင့်ပြုနိုင်သော ပြန်လည်ရယူချိန်သည် အလွန်အထင်ကြီးနိုင်သည်၊ ၎င်းမှာ ချိတ်ဆက်မှုအမြန်နှုန်းပေါ် မူတည်သည် (ပြန်လည်ရယူခြင်းသည် cloud မှဖြစ်ပါက)၊ သင့်စက်၏ hard drive အရွယ်အစား၊ နှင့် အခြားအချက်များစွာ။ လျှော့ချနိုင်ပါ့မလား။ ဟုတ်ကဲ့၊ အလုပ်ပြန်စဖို့အတွက် အမြဲတမ်းကွန်ပြူတာဒစ်အပြည့်မလိုအပ်တာကြောင့် သင်လုပ်နိုင်တယ်။ တူညီသောဓာတ်ပုံနှင့် ဗီဒီယိုများသည် စက်ပစ္စည်း၏လုပ်ဆောင်နိုင်စွမ်းကို မည်သည့်နည်းနှင့်မျှ မထိခိုက်စေဘဲ နောက်ခံတွင် နောက်မှဆွဲယူနိုင်သည်။

ယာဉ်မောင်းအလိုရှိသည်...

လည်ပတ်မှုစနစ်သည် ဒစ်အား အပြည့်အဝအဆင်သင့်ဖြင့် စတင်ရန် မျှော်လင့်ထားသည်။ ထို့ကြောင့်၊ Windows သည် disk ၏ခိုင်မာမှုကိုစစ်ဆေးရန်စစ်ဆေးမှုများဆက်တိုက်လုပ်ဆောင်သည်။ OS တွေ့ရှိရန်မျှော်လင့်ထားသော အချို့ဖိုင်များ ပျောက်ဆုံး သို့မဟုတ် ပျက်စီးနေပါက စနစ်သည် ပုံမှန်စတင်ဖွင့်ခြင်းကို ခွင့်မပြုပါ။ ဤပြဿနာကိုဖြေရှင်းရန်၊ ကျွန်ုပ်တို့ဖန်တီးထားသော ပျောက်ဆုံးနေသော သို့မဟုတ် ပျက်စီးနေသောဖိုင်များကို အစားထိုးသည့် ပြန်လည်ညွှန်းပေးသည့်ဖိုင်များကို ဒစ်ပေါ်တွင်ထားရှိရန် ဆုံးဖြတ်ခဲ့သော်လည်း အမှန်တကယ်မှာ အရုပ်များဖြစ်သည်။ အမှန်တကယ်တွင် ၎င်းတို့တွင် မည်သည့်အကြောင်းအရာမှ မရှိသောကြောင့် ထိုသို့သော ပြန်လည်ညွှန်းပေးသူများကို ဖန်တီးရန် အချိန်အကြာကြီး မယူပါ။

နောက်ထပ်ပြန်လည်ထူထောင်ရေးမှာ အောက်ပါအတိုင်းဖြစ်ပေါ်ပါသည်။ နောက်ခံလုပ်ငန်းစဉ်တစ်ခုအားဖြင့်၊ လည်ပတ်မှုစနစ်၏လည်ပတ်မှုနှင့်အပြိုင်၊ "အရုပ်များ" သည် ဒေတာများဖြင့် ပြည့်နေပါသည်။ နောက်ခံပြန်လည်ရယူခြင်းလုပ်ငန်းစဉ်သည် disk load ကိုထည့်သွင်းစဉ်းစားပြီးသတ်မှတ်ကန့်သတ်ချက်ထက်မကျော်လွန်ပါ။ သို့သော်၊ အသုံးပြုသူ သို့မဟုတ် လည်ပတ်မှုစနစ်ကိုယ်တိုင်က မတည်ရှိသေးသော ဖိုင်ကို ရုတ်တရက် လိုအပ်နိုင်သည်။ ဤနေရာတွင် ဒုတိယပြန်လည်ရယူခြင်းမုဒ်သည် ကစားရန်ရောက်ရှိလာသည်။ တောင်းဆိုထားသည့်ဖိုင်၏ ဦးစားပေးကို အမြင့်ဆုံးသို့ တိုးမြှင့်ထားပြီး ပြန်လည်ရယူရေးလုပ်ငန်းစဉ်သည် ဖိုင်ကို ဒစ်ခ်ပေါ်သို့ အမြန်တင်သည်။ လည်ပတ်မှုစနစ်သည် အနည်းငယ်နှောင့်နှေးနေသော်လည်း လိုအပ်သောဖိုင်ကို လက်ခံရရှိပါသည်။

ဒါက စံပြရုပ်ပုံပါပဲ။ သို့သော်လည်း လက်တွေ့ကမ္ဘာတွင် ကြီးမားသော ချို့ယွင်းချက်များနှင့် ဖြစ်နိုင်ခြေရှိသော သော့ခတ်မှုများ ရှိနေပါသည်။ Innopolis မာစတာ၏ကျောင်းသားများနှင့်အတူ၊ ကျွန်ုပ်တို့သည် ဤပြန်လည်ရယူရေးအခြေအနေအား လေ့လာစူးစမ်းရန်၊ RTO တွင် အမြတ်အစွန်းများကို အကဲဖြတ်ရန်နှင့် ထိုသို့သောချဉ်းကပ်မှုသည် ဖြစ်နိုင်ချေရှိမရှိ နားလည်ရန် ဆုံးဖြတ်ခဲ့သည်။ ပြီးနောက်၊ ထိုအချိန်က စျေးကွက်တွင် ထိုသို့သော ဖြေရှင်းနည်းများ မရှိခဲ့ပါ။

Innopolis မှယောက်ျားများအတွက် ၀ န်ဆောင်မှုအစိတ်အပိုင်းကိုငါမွေးမြူရန်ဆုံးဖြတ်ခဲ့လျှင် Acronis တွင်အလုပ်စတင်ခဲ့သည်။ ဖိုင်စနစ်ဒရိုက်ဗာဖြင့် အသေးစားစစ်ထုတ်ခြင်း။. ၎င်းကို Windows Kernel အဖွဲ့မှ လုပ်ဆောင်ခဲ့သည်။ အစီအစဥ်မှာ ဤကဲ့သို့ဖြစ်သည်-

• OS စတင်ခြင်း၏ အစောပိုင်းအဆင့်တွင် ယာဉ်မောင်းကို စတင်ပါ၊
• အလုပ်ချိန်၊ ဘယ်အချိန် အသုံးပြုသူနေရာ လုံးဝအဆင်သင့်ဖြစ်လိမ့်မည်၊ ဝန်ဆောင်မှုကိုဒေါင်းလုဒ်လုပ်ပါ။
• ဝန်ဆောင်မှုသည် ယာဉ်မောင်းတောင်းဆိုမှုများကို လုပ်ဆောင်ပြီး ၎င်း၏ နောက်ထပ်အလုပ်များကို ညှိနှိုင်းဆောင်ရွက်ပေးသည်။

ယာဉ်မောင်းအင်ဂျင်နီယာ၏ ပရိယာယ်များ

အကယ်၍ ကျွန်ုပ်၏လုပ်ဖော်ကိုင်ဖက်များသည် အခြားပို့စ်တစ်ခုတွင် ဝန်ဆောင်မှုအကြောင်းပြောကြမည်ဆိုလျှင်၊ ဤစာသားတွင် ယာဉ်မောင်းဖွံ့ဖြိုးတိုးတက်မှု၏ ရှုပ်ထွေးမှုများကို ဖော်ပြပါမည်။ တီထွင်ပြီးသား mini-filter driver တွင် system ကိုပုံမှန်မုဒ်တွင်စတင်သောအခါ၊ နှင့်စနစ်သည်ချို့ယွင်းမှုနှင့်ပြန်လည်ထူထောင်နေချိန်တို့တွင်လည်ပတ်မှုမုဒ်နှစ်ခုရှိသည်။ အသုံးပြုသူ စာကြည့်တိုက်များနှင့် အပလီကေးရှင်းများကို မတင်မီ၊ ထို့ကြောင့် ကျွန်ုပ်တို့၏ဝန်ဆောင်မှု၊ ယာဉ်မောင်းသည် အလားတူလုပ်ဆောင်သည်။ လောလောဆယ် ဘယ်အခြေအနေမှာ ရှိနေလဲ မသိဘူး။ ရလဒ်အနေဖြင့် ဖန်တီးမှုတိုင်း၊ ဖတ်ရှုခြင်းနှင့် ရေးသားခြင်းတိုင်းကို မှတ်တမ်းတင်ထားပြီး မက်တာဒေတာအားလုံးကို မှတ်တမ်းတင်ထားသည်။ ဝန်ဆောင်မှုသည် အွန်လိုင်းတွင် ရှိနေသောအခါ ယာဉ်မောင်းမှ ဤအချက်အလက်ကို ဝန်ဆောင်မှုသို့ ပေးပါသည်။

ပုံမှန်စတင်သည့်ကိစ္စတွင်၊ ဝန်ဆောင်မှုသည် ယာဉ်မောင်းအား "အပန်းဖြေရန်" အချက်ပြမှုတစ်ခု ပေးပို့ပြီး ဒေတာအားလုံးကို တိကျသေချာစွာ မှတ်တမ်းတင်ခြင်းကို ရပ်သွားစေသည်။ ဤကိစ္စတွင်၊ ဒရိုက်ဘာသည် ဒစ်ခ်ပေါ်ရှိ အပြောင်းအလဲများကိုသာ မှတ်တမ်းမှတ်ရာသို့ ပြောင်းပြီး အခြား Acronis ကိရိယာများကို အသုံးပြုကာ သုံးစွဲသူက သတ်မှတ်ထားသည့် မီဒီယာပေါ်ရှိ နောက်ဆုံးပေါ်နောက်ဆုံးအခြေအနေတွင် ဒစ်ခ်အရန်ကူးခြင်းကို ထိန်းသိမ်းပေးသည့် ဝန်ဆောင်မှုသို့ အကြောင်းကြားသည်။ ၎င်းသည် cloud၊ အဝေးထိန်း၊ တဖြည်းဖြည်း သို့မဟုတ် ညစဉ် အရန်သိမ်းခြင်း ဖြစ်နိုင်သည်။

ပြန်လည်ရယူခြင်းမုဒ်ကို ဖွင့်ထားပါက၊ ဝန်ဆောင်မှုသည် “ပြန်လည်ရယူခြင်း” မုဒ်တွင် အလုပ်လုပ်ရန် လိုအပ်ကြောင်း ယာဉ်မောင်းအား ပြောပြသည်။ စနစ်သည် ပျက်စီးမှုမှ ပြန်လည်ကောင်းမွန်လာခဲ့ပြီး ဒစ်ခ်ပေါ်တွင် ဖိုင်တစ်ခုဖွင့်ရန် တောင်းဆိုလာသည်နှင့်တပြိုင်နက်၊ အသေးစား စစ်ထုတ်မှုသည် ဤလုပ်ဆောင်ချက်ကို ကြားဖြတ်၊ ဤတောင်းဆိုချက်ကို သူ့ဘာသာသူ ပြုလုပ်ရမည်၊ ထိုကဲ့သို့သော ဖိုင်တစ်ခုသည် ဒစ်ခ်ပေါ်တွင် ရှိ၊ မရှိ စစ်ဆေးရန်၊ ၎င်းကိုဖွင့်နိုင်သည်။

ဖိုင်တစ်ခုပျောက်ဆုံးပါက၊ အသေးစားစစ်ထုတ်မှုသည် ဤအချက်အလက်ကို ဖိုင်ပြန်လည်ရယူခြင်း၏ ဦးစားပေးမှုကို တိုးလာစေသည် (ဤအချိန်တိုင်း၊ ပြန်လည်ရယူခြင်းမှာ နောက်ခံတွင်ဖြစ်နေသည်)။ ဤဖိုင်သည် တန်းစီခြင်း၏အစသို့ ရိုးရိုးတန်းတန်းခုန်သွားကြောင်း ထွက်ပေါ်လာသည်။ ယင်းနောက်၊ ဝန်ဆောင်မှုကိုယ်တိုင် (သို့မဟုတ် အခြားသော Acronis ဆိုလိုသည်မှာ) ဤဖိုင်ကို ပြန်လည်ရယူပြီး အရာအားလုံး အဆင်ပြေကြောင်း ဒရိုက်ဘာကို ပြောပြသည်၊ ယခုအခါ လည်ပတ်မှုစနစ်သည် ၎င်းကို ဝင်ရောက်နိုင်ပြီဖြစ်ပြီး ဒရိုက်ဘာမှ မူလတောင်းဆိုချက်အား စနစ်မှ disk သို့ “ထုတ်လွှတ်သည်” ဖြစ်သည်။

ပြန်လည်ရယူရန် မဖြစ်နိုင်ပါက၊ ဝန်ဆောင်မှုသည် ဖိုင်ကို အရန်သိမ်းထားခြင်းမရှိကြောင်း ယာဉ်မောင်းအား အသိပေးသည်။ ကျွန်ုပ်တို့၏ mini-filter driver သည် system request ကိုနောက်ထပ်သာလွန်စေပြီး မူရင်းတောင်းဆိုသူ (OS ကိုယ်တိုင် သို့မဟုတ် အပလီကေးရှင်း) သည် "ဖိုင်မတွေ့ပါ" အမှားကို လက်ခံရရှိပါသည်။ သို့သော်၊ ဖိုင်အမှန်တကယ် disk နှင့် backup တွင်မရှိပါက၎င်းသည်ပုံမှန်ဖြစ်သည်။

ဖိုင် သို့မဟုတ် စာကြည့်တိုက်ကို ဝေးလံခေါင်သီသော အရင်းအမြစ်များကို ဝင်ရောက်ကြည့်ရှုခြင်းဖြင့် အဆင့်များစွာတွင် ဖြစ်ပျက်နေသောကြောင့် လည်ပတ်မှုစနစ်သည် များစွာနှေးကွေးသွားမည်ဖြစ်သည်။ သို့သော် ပြန်လည်ရယူရေး လုပ်ဆောင်နေချိန်တွင် အသုံးပြုသူသည် တတ်နိုင်သမျှ အမြန်ဆုံး ပြန်လည်လုပ်ဆောင်နိုင်သည်။

အောက်လည်း နိမ့်ရမယ်...

ရှေ့ပြေးပုံစံသည် ၎င်း၏လုပ်ဆောင်နိုင်စွမ်းကို သက်သေပြခဲ့သည်။ သို့သော် အချို့သောကိစ္စများတွင် သော့ခတ်မှုများရှိနေသေးသောကြောင့် ဆက်လက်လုပ်ဆောင်ရန် လိုအပ်ကြောင်း ကျွန်ုပ်တို့တွေ့ရှိခဲ့သည်။ ဥပမာအားဖြင့်၊ လည်ပတ်မှုစနစ်သည် ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုကို သူ့အလိုလိုပြန်လှည့်ပတ်သွားစေရန် ကဏ္ဍများစွာရှိ အမျိုးမျိုးသော စာကြည့်တိုက်များကို တောင်းဆိုနိုင်သည်။

ကျွန်တော် လက်ရှိလုပ်ဆောင်နေတဲ့ ပြဿနာက Active Restore ရဲ့ အရှိန်ကို တိုးမြှင့်ပေးပြီး စနစ်လုံခြုံရေး အဆင့်ကို တိုးမြှင့်ပေးတာပါ။ စနစ်သည် ဖိုင်တစ်ခုလုံး မလိုအပ်သော်လည်း အစိတ်အပိုင်းတစ်ခုသာ ဖြစ်သည်ဆိုပါစို့။ ဤရည်ရွယ်ချက်အတွက်၊ အခြားဒရိုက်ဘာ - disk filter driver ကိုတီထွင်ခဲ့သည်။ ၎င်းသည် ဖိုင်အဆင့်တွင် အလုပ်မလုပ်တော့ဘဲ ပိတ်ဆို့သည့်အဆင့်တွင် ဖြစ်သည်။ လုပ်ဆောင်ချက်၏နိယာမသည် ဆင်တူသည်- ပုံမှန်လည်ပတ်မှုမုဒ်တွင်၊ ယာဉ်မောင်းသည် ဒစ်ခ်ပေါ်ရှိ ပြောင်းထားသော ဘလောက်များကို မှတ်တမ်းပြုပြီး ပြန်လည်ရယူခြင်းမုဒ်တွင် ၎င်းသည် ၎င်း၏ကိုယ်ပိုင်ပိတ်ဆို့ခြင်းကို ဖတ်ရန်ကြိုးစားကာ မအောင်မြင်ပါက ဦးစားပေးမှုကို တိုးမြှင့်ရန် ဝန်ဆောင်မှုကို တောင်းဆိုပါသည်။ သို့သော်လည်း စနစ်၏ အခြားအစိတ်အပိုင်းများအားလုံးသည် အတူတူပင်ဖြစ်ပါသည်။ ဥပမာအားဖြင့်၊ OS အဆင့်ဝန်ဆောင်မှုသည် အခြားဒရိုင်ဘာနှင့် ဆက်သွယ်ရန် ခိုင်းစေခြင်းကို သံသယရှိခြင်းမရှိပါ၊ အဘယ်ကြောင့်ဆိုသော် အဓိကတာဝန်မှာ OS လည်ပတ်ရန်အတွက် လိုအပ်သောဒေတာအတိအကျကို ပေးဆောင်ရန်ဖြစ်သည်။ ဝန်ဆောင်မှုသည် ဘလောက်အဆင့်တွင် မည်သို့တွေးရမည်ကို မသိသေးသောကြောင့်သာ ဤနယ်ပယ်တွင် သိသာထင်ရှားသောတိုးတက်မှုများ လိုအပ်ပါသည်။

နောက်တစ်ဆင့်တွင် ဝန်ဆောင်မှုအစား UEFI ဒရိုက်ဘာများနှင့် Native Windows အပလီကေးရှင်းများအဆင့်သို့ ဆင်းရန် ယာဉ်မောင်းကို ပိုမိုနက်ရှိုင်းပြီး စောစီးစွာ ဖွင့်ရန် ဆုံးဖြတ်ခဲ့သည်။ ဤရည်ရွယ်ချက်အတွက်၎င်းကိုတီထွင်ခဲ့သည်။ UEFI boot driver OS မစတင်မီတွင်ပင် (သို့မဟုတ် DXE ဒရိုက်ဘာ) သည် စတင်ပြီး သေဆုံးသည်။ သို့သော် UEFI ဒရိုက်ဘာများ၏ "သမိုင်း"၊ တပ်ဆင်ခြင်းနှင့်တပ်ဆင်ခြင်းဆိုင်ရာအသေးစိတ်အချက်များအပြင် နောက်ပို့စ်တွင် Windows Native အပလီကေးရှင်းများ၏အသေးစိတ်အချက်အလက်များကိုကြည့်ရှုပါမည်။ ထို့ကြောင့် ကျွန်ုပ်တို့၏ဘလော့ဂ်ကို စာရင်းသွင်းပါ၊ ထိုအချိန်တွင် အလုပ်၏နောက်ထပ်အဆင့်နှင့်ပတ်သက်သည့် ဇာတ်လမ်းတစ်ပုဒ်ကို ပြင်ဆင်ပါမည်။ မင်းရဲ့မှတ်ချက်တွေနဲ့ အကြံဉာဏ်တွေကို မြင်ရတာ ဝမ်းသာပါတယ်။

စာရင်းသွင်းအသုံးပြုသူများသာ စစ်တမ်းတွင် ပါဝင်နိုင်ပါသည်။ ဆိုင်းအင်လုပ်ခြင်း, ကျေးဇူးပြု။

ပြန်လည်နာလန်ထဖို့ အချိန်အကြာကြီးယူရတဲ့ အခြေအနေမျိုး ရှိဖူးပါသလား။

• 65.1%ဟုတ်တယ်28

• 23.2%နံပါတ် ၂၄၄

• 11.6%မစဉ်းစားခဲ့ပါဘူး ၅

အသုံးပြုသူ 43 ဦး မဲပေးခဲ့သည်။ အသုံးပြုသူ ၃ ဦး ရှောင်နေခဲ့ပါတယ်။

source: www.habr.com