উইন্ডোজে IRQL (ইন্টারপ্ট রিকোয়েস্ট লেভেল) কী এবং এটি BSOD-এর সাথে কীভাবে সম্পর্কিত?

যদি তুমি কখনও নীল পর্দা দেখে থাকো যেখানে এই ধরনের বার্তা আছে IRQL না কম বা সমান o ড্রাইভার_আইআরকিউএল_কম_অথবা_সমান নয়, আপনি সম্ভবত এমন একটি ধারণার মুখোমুখি হয়েছেন যা ড্রাইভারদের জগতের বাইরে খুব কম পরিচিত: IRQL (ইন্টারপ্ট রিকোয়েস্ট লেভেল)। উইন্ডোজ, সিস্টেম যখন একটি নির্দিষ্ট থ্রেশহোল্ডের উপরে থাকে তখন এই স্তরের ইন্টারাপ্ট অগ্রাধিকার থ্রেড অগ্রাধিকারের চেয়ে অগ্রাধিকার পায় এবং এর সরাসরি প্রভাব স্থায়িত্বের উপর পড়ে।

পরবর্তী লাইনগুলিতে আপনি পাবেন একটি সম্পূর্ণ গাইড এবং স্পেনের স্প্যানিশ ভাষায় IRQL কী, এটি কীভাবে কাজ করে সে সম্পর্কে, কেন এটি নীল পর্দা ট্রিগার করে, WinDbg-এর সমস্যা কীভাবে নির্ণয় করবেন, এবং আপনি যদি ত্রুটির সম্মুখীন হন অথবা কার্নেল-মোড ড্রাইভার তৈরি করেন তবে কী করবেন। আসুন ব্যবসায় নেমে আসি।

উইন্ডোজে IRQL (ইন্টারপ্ট রিকোয়েস্ট লেভেল) কী?

উইন্ডোজে, IRQL অগ্রাধিকার নির্ধারণ করে হার্ডওয়্যার যেখানে একটি প্রসেসর কাজ করে যেকোনো সময়। উইন্ডোজ ড্রাইভার মডেল (WDM) এর মধ্যে, কম IRQL-এ চলমান কোড উচ্চতর IRQL-এ চলমান কোড দ্বারা বাধাগ্রস্ত হতে পারে। প্রকৃতপক্ষে, একটি একক মাল্টি-কোর কম্পিউটারে, প্রতিটি CPU একটি ভিন্ন IRQL-এ থাকতে পারে, যা সিঙ্ক্রোনাইজেশনকে জটিল করে তোলে।

একটি মূল নিয়ম আছে: যখন একটি CPU PASSIVE_LEVEL এর উপরে IRQL এ চলমান থাকে, তখন এটি কেবলমাত্র আরও উচ্চতর IRQL এ কার্যকলাপ দ্বারা প্রিম্পট করা যেতে পারে।এটি ব্যবহারকারী কোড, কার্নেল ফাংশন, ডিফার্ড কলার (DPCs) এবং ডিভাইস ইন্টারাপ্ট সার্ভিস রুটিন (ISRs) এর মধ্যে সহাবস্থানকে সংগঠিত করে।

স্তর এবং অগ্রাধিকার: PASSIVE_LEVEL, APC_LEVEL, DISPATCH_LEVEL এবং DIRQL

সাধারণভাবে, x86-এ, 0 থেকে 31-এর মধ্যে IRQL মান ব্যবহার করা হয়; x64-এ, 0 থেকে 15-এর মধ্যেব্যবহারিক অর্থ একই: IRQL 0 (PASSIVE_LEVEL) হল যেখানে সাধারণ ব্যবহারকারী কোড এবং অনেক ড্রাইভার ফাংশন কার্যকর করা হয়; APC এবং পৃষ্ঠার ত্রুটি এগুলি সাধারণত IRQL 1 (APC_LEVEL) তে ম্যাপ করা হয়; IRQL 2 (DISPATCH_LEVEL) থ্রেড শিডিউলার এবং DPC গুলিকে অন্তর্ভুক্ত করে। DISPATCH_LEVEL এর উপরে ডিভাইস ইন্টারাপ্ট (DIRQL নামে পরিচিত) এবং HIGH_LEVEL এর মতো অন্যান্য অভ্যন্তরীণ ব্যবহারের জন্য সংরক্ষিত স্তর রয়েছে।

ড্রাইভার ইকোসিস্টেমে, DISPATCH_LEVEL এ অনেক সাধারণ রুটিন চলে: উদাহরণস্বরূপ, DPC এবং StartIo। এই নকশাটি নিশ্চিত করে যে যখন তাদের মধ্যে একটি অভ্যন্তরীণ সারি বা অন্যান্য ভাগ করা সংস্থানগুলিকে স্পর্শ করছে, একই স্তরের অন্য একটি রুটিন সেই CPU-তে এটিকে প্রিম্পট করে না, কারণ প্রিম্পশন নিয়ম শুধুমাত্র উচ্চ স্তরে ইন্টারাপ্টের অনুমতি দেয়।

DISPATCH_LEVEL এবং প্রোফাইলিং/উচ্চ স্তরের মধ্যে এর জন্য জায়গা আছে প্রতিটি ডিভাইসের হার্ডওয়্যার ইন্টারাপ্ট (DIRQL)একটি ডিভাইসের IRQL অন্যান্য ডিভাইসের তুলনায় তার অগ্রাধিকার নির্ধারণ করে। IRP_MJ_PNP এর সময় IRP_MN_START_DEVICE ব্যবহার করে একটি WDM ড্রাইভার এই IRQLটি পায়। এই ডিভাইসের IRQL একটি বিশ্বব্যাপী, স্থির মান নয়, বরং একটি নির্দিষ্ট ইন্টারাপ্ট লাইনের সাথে সম্পর্কিত মান।

IRQL বনাম থ্রেড অগ্রাধিকার

ধারণাগুলিকে বিভ্রান্ত না করার পরামর্শ দেওয়া হচ্ছে: থ্রেড অগ্রাধিকার নির্ধারণ করে কখন শিডিউলার প্রিম্প্ট করে এবং কোন থ্রেডটি কার্যকর করে; IRQL নিয়ন্ত্রণ করে কোন ধরণের কার্যকলাপ চালানো যেতে পারে এবং কোন বাধাগুলি মাস্ক করা হয়। DISPATCH_LEVEL এর উপরে, কোনও থ্রেড স্যুইচিং নেই: এটি IRQL নিয়ন্ত্রণ করে, থ্রেড অগ্রাধিকার নয়।

IRQL এবং পেজিং: আপনার যা করা উচিত নয়

IRQL বৃদ্ধির একটি তাৎক্ষণিক প্রভাব হল যে সিস্টেমটি পৃষ্ঠার ত্রুটিগুলি পরিচালনা করতে পারছি না. সুবর্ণ নিয়ম: DISPATCH_LEVEL বা তার উপরে চলমান কোড পৃষ্ঠা ত্রুটি সৃষ্টি করতে পারে না। বাস্তবে, এর অর্থ হল সেই রুটিনগুলি এবং তারা যে ডেটা স্পর্শ করে পৃষ্ঠাবিহীন মেমোরিতে থাকা আবশ্যক. এছাড়াও, কিছু কার্নেল হেল্পার IRQL এর উপর ভিত্তি করে তাদের ব্যবহার সীমিত করে: উদাহরণস্বরূপ, KeWaitForSingleObject DISPATCH_LEVEL শুধুমাত্র তখনই কল করা যাবে যদি আপনি ব্লক না করেন (শূন্য টাইমআউট), এবং শূন্য-বহির্ভূত টাইমআউটের জন্য, আপনাকে DISPATCH_LEVEL এর নিচে থাকতে হবে।

IRQL-এর অন্তর্নিহিত এবং স্পষ্ট নিয়ন্ত্রণ

বেশিরভাগ সময়, সিস্টেম নিজেই সঠিক IRQL-এ আপনার রুটিনগুলিকে আহ্বান করে তাদের কী করা উচিত তা জানতে। IRP-এর জন্য ডিসপ্যাচ রুটিনগুলি PASSIVE_LEVEL-এ চলে (তারা যেকোনো সাহায্যকারীকে ব্লক বা কল করতে পারে), StartIo এবং DPC DISPATCH_LEVEL-এ চলে যাতে শেয়ার করা কিউগুলি সুরক্ষিত থাকে, এবং ISR গুলি DIRQL-এ চলে।

যদি আপনার এটি স্পষ্টভাবে নিয়ন্ত্রণ করার প্রয়োজন হয়, আপনি IRQL বাড়াতে এবং কমাতে পারেন KeRaiseIrql y KeLowerIrqlএকটি বহুল ব্যবহৃত শর্টকাট আছে: KeRaiseIrqlToDpcLevel() পূর্ববর্তী IRQL ফেরত দেয় এবং আপনাকে DISPATCH_LEVEL এ ছেড়ে দেয়। গুরুত্বপূর্ণ: সিস্টেম যখন আপনাকে কল করেছিল তখন IRQL এর মান কখনই তার চেয়ে কম করবেন না; সেই সিঙ্ক্রোনাইজেশন ভেঙে গেলে খুব গুরুতর রেস উইন্ডো খুলতে পারে।

IRQL-সম্পর্কিত নীল পর্দার ত্রুটি: IRQL_NOT_LESS_OR_EQUAL এবং DRIVER_IRQL_NOT_LESS_OR_EQUAL

এই সমস্যাগুলির সাথে সম্পর্কিত দুটি ক্লাসিক বাগ চেক হল IRQL_NOT_LESS_OR_EQUAL (0xA) y ড্রাইভার_আইআরকিউএল_কম_অথবা_সমান নয় (0xD1)উভয়ই ইঙ্গিত দেয় যে, একটি পেজযোগ্য (অথবা অবৈধ) ঠিকানা অ্যাক্সেস করার প্রচেষ্টা একটি IRQL-এ খুব বেশি। এটি সাধারণত ড্রাইভারদের ভুল ঠিকানা ব্যবহার, খারাপ পয়েন্টার ডিরেফারেন্স করা, অথবা অনুপযুক্ত স্তরে পেজযোগ্য কোড কার্যকর করার কারণে হয়।

নির্দিষ্ট ক্ষেত্রে ড্রাইভার_আইআরকিউএল_কম_অথবা_সমান নয় (0x000000D1), প্যারামিটারগুলি খুবই তথ্যবহুল: ১) রেফারেন্সড মেমোরি অ্যাড্রেস; ২) সেই সময়ে IRQL; ৩) অ্যাক্সেস টাইপ (০ রিড, ১ রাইট, ২/৮ এক্সিকিউট); ৪) মেমোরি রেফারেন্সড ইন্সট্রাকশনের অ্যাড্রেস। ডিবাগার দিয়ে আপনি ব্যবহার করতে পারেন ln প্যারামিটার 4 এর জন্য নিকটতম প্রতীকটি তালিকাভুক্ত করুন এবং কোন ফাংশনটি চলছে তা জানুন.

মনে রাখার সাধারণ কারণগুলি

নির্দিষ্ট কোডের বাইরেও, এমন কিছু প্যাটার্ন আছে যা পুনরাবৃত্তি হয়। একটি অবৈধ পয়েন্টারকে DISPATCH_LEVEL বা তার উচ্চতর পয়েন্টারে ডিফারেন্স করা হচ্ছে এটি নিশ্চিতভাবেই বিপর্যয়ের কারণ। সেই স্তরে পেজেবল ডেটা অ্যাক্সেস করা, অথবা পেজেবল কোড (যেমন, পেজেবল হিসেবে চিহ্নিত একটি ফাংশন) কার্যকর করাও বাগ চেককে ট্রিগার করে।

অন্যান্য সাধারণ ক্ষেত্রে অন্তর্ভুক্ত অন্য ড্রাইভারে এমন একটি ফাংশন কল করুন যা ইতিমধ্যেই ডাউনলোড করা হয়েছে (ঝুলন্ত ফাংশন পয়েন্টার), অথবা পরোক্ষভাবে একটি অবৈধ ফাংশন পয়েন্টারের মাধ্যমে আহ্বান করা হয়। প্রায়শই, যদি সিস্টেমটি একটি মডিউল সনাক্ত করতে সক্ষম হয়, তাহলে আপনি নীল পর্দায় তার নামটি দেখতে পাবেন এবং এটি সংরক্ষিতও থাকে KiBugCheckDriver, এর মাধ্যমে অ্যাক্সেসযোগ্য dx KiBugCheckDriver WinDbg থেকে।

একটি ব্যবহারিক বিশদ: বেশিরভাগ D1/A-তে, আসল সমস্যাটি IRQL নিজেই নয়।, বরং রেফারেন্সড মেমোরি অ্যাড্রেস। এই কারণেই রোগ নির্ণয়ের উপর ফোকাস করার জন্য প্যারামিটার 1, 3 এবং 4 অত্যন্ত গুরুত্বপূর্ণ।

WinDbg ব্যবহার করে রোগ নির্ণয়: দরকারী কমান্ড এবং প্যারামিটার রিডিং

এই মামলাগুলিতে কাজ করার জন্য, WinDbg হল মূল হাতিয়ার, এবং যদি BSOD উল্লেখ করে ntoskrnl.exe এই তথ্যটি কার্নেল সাবসিস্টেমে ত্রুটি আছে কিনা সে সম্পর্কে অনেক নির্দেশনা প্রদান করে। শুরু করুন !analyze -v বাগ চেক, স্ট্যাক এবং যদি আপনি ভাগ্যবান হন, তাহলে জড়িত মডিউলের সারাংশ পেতে। যদি ডাম্পে একটি ক্যাপচার ফ্রেম থাকে, .trap আপনাকে ব্যর্থ CPU-র প্রেক্ষাপটে রাখে।

The comandos স্তূপের মতো k, kb, kc, kd, kp, kP, kv তারা আপনাকে ব্যাকট্রেসের বিভিন্ন স্তরের বিবরণ দেখায়। ln প্যারামিটার ৪-এ আপনি এড়িয়ে যেতে পারেন স্মৃতির উল্লেখকারী নির্দেশের প্রতি এবং কাছাকাছি প্রতীকটি পান। এবং যদি আপনার সন্দেহ হয় যে ইন্টারাপ্টের আগে অগ্রাধিকার স্তর চলছে, !irql লক্ষ্য প্রসেসরের জন্য সংরক্ষিত IRQL আপনাকে দেখায় (যেমন DISPATCH_LEVEL)।

প্যারামিটার ১ এর দিক বিশ্লেষণ করতে, !pool এটি আপনাকে বলবে যে এটি একটি পেজড পুলের অন্তর্গত কিনা; !address y !pte সেই এলাকার মেমোরি ম্যাপিংয়ের দিকে নজর দিন। আপনি ব্যবহার করতে পারেন মেমরি ডিসপ্লে কমান্ড যে কন্টেন্টটি অ্যাক্সেস করার চেষ্টা করা হয়েছিল তা পরীক্ষা করার জন্য। অবশেষে, u, ub, uu আপনাকে প্যারামিটার ৪ এর ঠিকানার চারপাশে বিচ্ছিন্ন করার অনুমতি দেয়।

ভুলে যাবেন না lm t n লোড করা মডিউল তালিকাভুক্ত করতে y !memusage স্মৃতির সাধারণ অবস্থার জন্য। যদি KiBugCheckDriver কিছু আছে, dx KiBugCheckDriver এটি ইউনিকোড মডিউলের নাম ফিরিয়ে দেবে: একটি সাধারণ উদাহরণে, বাগ চেকের সময় "Wdf01000.sys" কে ড্রাইভার হিসেবে দেখা হয়েছিল।

সিস্টেম টুলস: ড্রাইভার ভেরিফায়ার, ইভেন্ট ভিউয়ার এবং ডায়াগনস্টিক্স

El ড্রাইভার যাচাইকারী রিয়েল টাইমে ড্রাইভারদের আচরণ পরীক্ষা করে এবং ভুল রিসোর্স ব্যবহার (যেমন পুল) সনাক্ত করলে ত্রুটিগুলি জোর করে, কোডের সমস্যাযুক্ত এলাকাটি আলাদা করার জন্য একটি ব্যতিক্রম উত্থাপন করে। এটি দিয়ে চালু করা হয় verifier থেকে কমান্ড প্রম্পট এবং অতিরিক্ত ওভারহেড যোগ না করার জন্য যতটা সম্ভব ছোট ড্রাইভার নির্বাচন করা যুক্তিযুক্ত।

যদি আপনি নিজেকে WinDbg-এর সাথে দেখতে না পান, মৌলিক ব্যবস্থা প্রয়োগ করুন: সিস্টেম লগ ইন ইভেন্ট ভিউয়ারে কোনও নির্দিষ্ট ডিভাইস/ড্রাইভারের দিকে নির্দেশিত ত্রুটির জন্য পরীক্ষা করুন; নীল স্ক্রিনে উদ্ধৃত ড্রাইভারটি আপডেট বা অক্ষম করুন; আপনার উইন্ডোজ সংস্করণের সাথে হার্ডওয়্যারের সামঞ্জস্যতা যাচাই করুন; এবং যদি আপনার RAM সন্দেহ হয় তবে উইন্ডোজ মেমোরি ডায়াগনস্টিক ব্যবহার করুন। এই পদক্ষেপগুলি, যদিও সহজ, তারা প্রচুর সংখ্যক মামলা সমাধান করে.

বাস্তব জীবনের ঘটনা: যখন BSOD গুলি এলোমেলো মনে হয়

একজন ব্যবহারকারী যার Windows 10 Pro (AMD Ryzen 5 3400G CPU, জিপিইউ এনভিডিয়া GeForce GTX 1660 Ti এবং Gigabyte B450 AORUS PRO WIFI বোর্ড, ১৬ গিগাবাইট র‍্যাম) মাঝেমধ্যে "IRQL_LESS_OR_NOT_EQUAL" স্ক্রিন দেখাচ্ছিল। আমি ইতিমধ্যেই প্রয়োজনীয় ড্রাইভার (নেটওয়ার্ক, গ্রাফিক্স) আপডেট করেছি, সমস্ত উইন্ডোজ আপডেট ইনস্টল করেছি এবং মেমোরি টুলটি চালাচ্ছি, কোনও সমস্যা ছাড়াই।

এই ধরণের পরিস্থিতিতে, পরবর্তী ধাপ হল WinDbg দিয়ে ডাম্প বিশ্লেষণ করা। এবং প্যাটার্নগুলি সন্ধান করুন: এটি পড়ে গেলে জড়িত প্রক্রিয়াগুলি (উদাহরণস্বরূপ, explorer.exe), গ্রাফিক্যাল ইন্টারফেস মডিউল (win32kfull.sys) এবং ফাংশন যেমন xxxProcessNotifyWinEvent স্ট্যাকে দেখা যাচ্ছে। যদিও এই মডিউলটি উইন্ডোজ, ট্রিগারটি প্রায়শই একটি তৃতীয় পক্ষের ড্রাইভার (গ্রাফিক্স, ইনপুট, ওভারলে, ক্যাপচার কার্ড) যা একটি অনুপযুক্ত IRQL-এ মেমরি ব্যবহার করে এবং ত্রুটিটি এর মধ্যেই দেখা দেয় win32k.

এখানে ব্যবহারিক সুপারিশ হল ওভারলে সফ্টওয়্যার সাময়িকভাবে অক্ষম করুন (ক্যাপচার, জিপিইউ ওএসডি), আক্রমণাত্মক সফ্টওয়্যার পেরিফেরাল ড্রাইভার (ম্যাক্রো সহ মাউস/কীবোর্ড), এবং গ্রাফিক্স ড্রাইভারের বিটা সংস্করণ, এবং এটিকে সংকুচিত করুন। সন্দেহভাজনদের উপর ড্রাইভার ভেরিফায়ার ব্যবহার করা একটি পরিষ্কার স্ট্যাকের মাধ্যমে সমস্যাটি সংকুচিত করতে সাহায্য করতে পারে।

একটি খুব সাধারণ নেটওয়ার্ক প্যাটার্ন: ndis.sys সবসময় দোষী নয়।

আরেকটি সাধারণ ঘটনা: ndis.sys সহ স্ক্রিনশট (উইন্ডোজ নেটওয়ার্ক স্তর)। একটি বাস্তব কম্পিউটারে, সিস্টেমটি শুরু হওয়ার সাথে সাথেই ক্র্যাশ হয়ে যেত। ব্যবহারিক সমাধান ছিল বুট ইন করা নিরাপদ মোড নেটওয়ার্ক ফাংশন ছাড়া, খুলুন ডিভাইস ম্যানেজার এবং সমস্যাটি সমাধানের জন্য "নেটওয়ার্ক অ্যাডাপ্টার" এর অধীনে অ্যাডাপ্টারগুলি অক্ষম করুন।

সেই দলে ছিল একজন রিয়েলটেক PCIe GBE ফ্যামিলি কন্ট্রোলার এবং একটি Atheros AR5007G। উভয়কেই নিষ্ক্রিয় করে, এটি সনাক্ত করা হয়েছিল যে আসল কারণটি ছিল athrx.sys (অ্যাথেরোস), যদিও নীল পর্দায় উল্লেখ করা হয়েছে ndis.sysডাম্পটি এটি নিশ্চিত করেছে: স্ট্যাকটি এর মধ্য দিয়ে গেছে ndis!NdisFreeTimerObject কিন্তু দোষী মডিউলটি ছিল athrx.sysচূড়ান্ত সংশোধন ছিল ডিভাইসটি আনইনস্টল করুন এবং আপডেট করা অফিসিয়াল ড্রাইভার ইনস্টল করুন Atheros প্রস্তুতকারকের ওয়েবসাইট থেকে। নীতি: BSOD-তে উদ্ধৃত মডিউলটি প্রভাবিত সাবসিস্টেমের অংশ হতে পারে, উৎসের অংশ নয়।

ব্যবহারকারীদের জন্য সাধারণ সহায়তা প্রতিক্রিয়া এবং দ্রুত পদক্ষেপ

সত্যিকারের সহায়তা বিনিময়ে, একজন টেকনিশিয়ান উত্তর দিলেন: "অসুবিধার জন্য আমি দুঃখিত। এটি ড্রাইভার, মেমোরি, অথবা অ্যান্টিভাইরাস সমস্যা হতে পারে। অনুগ্রহ করে আপনার ড্রাইভারগুলি আপডেট করুন এবং যদি এটি অব্যাহত থাকে, তাহলে মেমোরি ডায়াগনস্টিক চালান।"এটি মৌলিক কিন্তু বৈধ পরামর্শ; তবে, যদি ত্রুটিগুলি অব্যাহত থাকে, তাহলে যাচাইকারী এবং ডাম্প বিশ্লেষণের সাথে আরও এগিয়ে যাওয়া একটি ভাল ধারণা।

অ-প্রযুক্তিগত ব্যবহারকারীদের জন্য, একটি যুক্তিসঙ্গত প্রোটোকল হবে: ১) সিস্টেম ইভেন্ট পরীক্ষা করুন, ২) কী ড্রাইভার আপডেট করুন (চিপসেট/নেটওয়ার্ক/গ্রাফিক্স), ৩) RAM পরীক্ষা করুন সমন্বিত টুল সহ, 4) পরীক্ষা বুট কার্নেল/GUI-তে হুক ঢোকানো তৃতীয় পক্ষের সফ্টওয়্যার ছাড়াই পরিষ্কার করুন, এবং 5) যদি কিছুই পরিষ্কার না হয় তবে তৃতীয় পক্ষের ড্রাইভারগুলিতে ভেরিফায়ার ব্যবহার করুন।

ড্রাইভার ডেভেলপারদের জন্য সর্বোত্তম অনুশীলন

যদি আপনি বিকাশ করছেন এবং D1/A-তে হোঁচট খাচ্ছেন, তাহলে পরীক্ষা করে দেখুন যে চলমান রুটিনটি পৃষ্ঠাযোগ্য হিসাবে চিহ্নিত করা হয়নি DISPATCH_LEVEL বা তার বেশি ভার্সনে চলাকালীন পেজেবল ফাংশন কল করবেন না। এর মধ্যে রয়েছে পেজড সেকশনে ডেটার রেফারেন্স এড়িয়ে যাওয়া এবং DDK-তে বর্ণিত কার্নেল হেল্পারদের জন্য IRQL বিধিনিষেধ মেনে চলা।

ভাগ করা ডেটা সিঙ্ক্রোনাইজ করতে, "সর্বদা একই উচ্চ IRQL-এ ভাগ করা ডেটা অ্যাক্সেস করুন" নিয়মটি প্রয়োগ করুন। এবং উপযুক্ত হলে স্পিন লক ব্যবহার করুন। মাল্টিপ্রসেসরগুলিতে, কেবল IRQL বিভিন্ন CPU-র মধ্যে বর্জনের গ্যারান্টি দেয় না; স্পিন লকগুলি IRQL (DISPATCH_LEVEL-তে) বাড়ায় এবং কোরগুলির মধ্যে অ্যাক্সেস সমন্বয় করে। যদি আপনার সংবেদনশীল হার্ডওয়্যার রেজিস্টারে কাজ করার প্রয়োজন হয়, KeSynchronizeExecution সঠিক DIRQL-এ গুরুত্বপূর্ণ বিভাগগুলি কার্যকর করতে সাহায্য করে।

যখন পরিকল্পনার জন্য IRQL বাড়ানোর প্রয়োজন হয়, আমেরিকা KeRaiseIrqlToDpcLevel DISPATCH_LEVEL এর জন্য অথবা KeRaiseIrql সাবধানে, পূর্ববর্তী IRQL সংরক্ষণ করে এবং ঠিক এর সাথে পুনরুদ্ধার করে KeLowerIrql. ইনপুট IRQL এর নিচে যান, এমনকি এক মুহূর্তের জন্যও, এটি একটি গুরুতর সিঙ্ক্রোনাইজেশন ত্রুটি।.

ইন্টারাপ্ট এবং হার্ডওয়্যারের সাথে সম্পর্ক

IRQL হল সেই প্রক্রিয়া যার মাধ্যমে উইন্ডোজ অগ্রাধিকার এবং কিছু অভ্যন্তরীণ কাজকে বাধাগ্রস্ত করার আদেশ দেয়স্থাপত্য স্তরে, এটি "ইন্টারপ্ট", "ইন্টারপ্ট হ্যান্ডলার" বা "ইন্টারপ্ট অগ্রাধিকার স্তর" এর মতো ধারণাগুলির সাথে সম্পর্কিত এবং ক্লাসিক প্ল্যাটফর্মগুলিতে, প্রোগ্রামেবল ইন্টারাপ্ট কন্ট্রোলার (PIC)অন্যান্য সিস্টেমে, অগ্রাধিকার নিয়ন্ত্রণ প্রক্রিয়ার মাধ্যমে প্রকাশ করা হয় যেমন SPL en ইউনিক্স; সাধারণ ধারণাটি একই: কে কাকে বাধা দিতে পারে।

উন্নত ডিবাগিং টিপস

ডাম্পগুলিতে যেখানে স্ট্যাকটি নির্দেশ করে win32kfull!xxxProcessNotifyWinEvent বাগ চেক 0xA/0xD1 সহ, প্রসঙ্গটি পরীক্ষা করুন .process y .thread (যদি পাওয়া যায়), প্রক্রিয়াগুলি দেখুন যেমন explorer.exe en !process 0 1 এবং ওভারলে এবং GUI ইন্টারঅ্যাকশন ড্রাইভার পরীক্ষা করুন। অনেক সময় সমস্যা হয় এটি সেই পথে আবির্ভূত তৃতীয় পক্ষের দ্বারা দূষিত স্মৃতি।.

IRQL চেক করতে ভুলবেন না !irql, এবং বৈসাদৃশ্য: যদি আপনি DISPATCH_LEVEL (2) এ থাকেন এবং প্যারামিটার 3 পঠন/লেখা/চালনা নির্দেশ করে একটি পৃষ্ঠাযুক্ত পৃষ্ঠায়, কেন এটি পড়ে গেছে তার একটি সূত্র আপনার কাছে ইতিমধ্যেই আছে। সেই সূত্রটি অতিক্রম করুন ln নির্দিষ্ট ফাংশন পেতে প্যারামিটার 4-এ।

বোঝা IRQL কী? এবং এটি কার্নেল এক্সিকিউশনে কীভাবে ফিট করে তা সংকেত থেকে শব্দ আলাদা করতে সাহায্য করে। আপনি যদি একজন ব্যবহারকারী হন, তাহলে ফোকাস করুন ড্রাইভার এবং হার্ডওয়্যার (ডিফল্টরূপে যাচাইকারী, ইভেন্ট এবং পরীক্ষা সহ)। যদি আপনি বিকাশ করেন, তাহলে IRQL, নন-প্যাজড মেমরি এবং স্পিন লকগুলির সাথে সিঙ্ক্রোনাইজেশনের নিয়মগুলি কঠোরভাবে অনুসরণ করুন। সঠিক সরঞ্জাম (WinDbg, যাচাইকারী) এবং প্যারামিটারগুলির যত্ন সহকারে পড়া (1, 3, এবং 4) সহ, এই বাগ চেকগুলি আর রহস্য নয় এবং এগুলি এমন সমস্যায় পরিণত হয় যা পদ্ধতিগতভাবে সমাধান করা যেতে পারে।