জানুন কিভাবে Mark Russinovich-এর Windows Internals মানসিকতা Sysinternals, WinDbg ও বাস্তব পরিবীক্ষণকে গঠন করেছে — উইন্ডোজে ডিবাগিং ও নির্ভরযোগ্যতার জন্য ব্যবহারিক ওয়ার্কফ্লো।
আপনি যদি প্রোডাকশনে উইন্ডোজ চালান—ল্যাপটপ, সার্ভার, VDI, বা ক্লাউড VM—তাহলে Mark Russinovich-এর কাজ দৈনন্দিন অপারেশনে এখনও দেখা যায়। না, সেটা ব্যক্তিত্ব বা নস্টালজিয়ার কারণে নয়, বরং কারণ তিনি সমস্যার সমাধানে প্রমান-প্রধান পদ্ধতি প্রসারিত করেছেন: OS আসলে কী করছে সেটা দেখুন, তারপর লক্ষণের ব্যাখ্যা প্রমাণ সহ দিন।
পর্যবেক্ষণযোগ্যতা (Observability) মানে আপনি সিস্টেম থেকে উৎপন্ন সিগন্যাল (ইভেন্ট, ট্রেস, কাউন্টার) ব্যবহার করে “এখন কী ঘটছে?” উত্তর দিতে পারেন। যখন একটি সার্ভিস ধীর হয়ে যায় বা লগঅন হ্যাং করে, পর্যবেক্ষণযোগ্যতাই অনুমান বনাম জ্ঞানের পার্থক্য নির্ধারণ করে।
ডিবাগিং হল অস্পষ্ট সমস্যা ("এটি ফ্রিজ করেছে")কে একটি নির্দিষ্ট মেকানিজমে পরিণত করা ("এই থ্রেডটি I/O-তে ব্লক করছে", "এই প্রসেস পেজ ফাইল থ্র্যাশ করছে", "এই DLL injection আচরণ বদলে দিয়েছে")।
নির্ভরযোগ্যতা হল চাপের অধীনে কাজ চালিয়ে যাওয়ার এবং পূর্বানুমেয়ভাবে পুনরুদ্ধার করার ক্ষমতা—কম ইনসিডেন্ট, দ্রুত রিস্টোর, এবং নিরাপদ পরিবর্তন।
অধিকাংশ “রহস্যময় আউটেজ” আসলে রহস্য নয়—এগুলো হল উইন্ডোজ আচরণ যেগুলো আপনি এখনও ম্যাপ করেননি: হ্যান্ডেল লিক, অস্থির চাইল্ড প্রসেস, আটকে থাকা ড্রাইভার, DNS টাইমআউট, ভাঙা অটো-স্টার্ট এন্ট্রি, বা সিকিউরিটি টুলিং যা ওভারহেড যোগ করে। উইন্ডোজ ইন্টার্নালস (প্রসেস, থ্রেড, হ্যান্ডেল, সার্ভিস, মেমরির, I/O) সম্পর্কে একটি মৌলিক ধারণা আপনাকে দ্রুত প্যাটার্ন চিনতে এবং সমস্যা অদৃশ্য হওয়ার আগেই সঠিক প্রমাণ সংগ্রহ করতে সাহায্য করে।
আমরা প্র্যাকটিকাল, অপারেশন-ফ্রেন্ডলি ওয়ার্কফ্লোতে ফোকাস করব, বিশেষ করে:
লক্ষ্যটি আপনাকে কার্নেল ইঞ্জিনিয়ার তৈরি করা নয়। বরং উইন্ডোজ ইনসিডেন্টগুলো ছোট, শান্ত এবং বোঝানো সহজ করে তোলা—যাতে ফিক্সগুলো নিরাপদ ও পুনরাবৃত্তিযুক্ত হয়।
উইন্ডোজ “ইন্টার্নালস” সহজভাবে বলতে গেলে সেই মেকানিজমগুলোর সেট যা উইন্ডোজ বাস্তব কাজ করার জন্য ব্যবহার করে: থ্রেড শিডিউলিং, মেমরি ম্যানেজমেন্ট, সার্ভিস শুরু/বন্ধ, ড্রাইভার লোড, ফাইল ও রেজিস্ট্রি কার্যকলাপ, এবং সিকিউরিটি বাউন্ডারি প্রয়োগ। প্রায়োগিক প্রতিশ্রুতি সরল: যখন আপনি OS কী করছে তা বুঝবেন, আপনি অনুমান বন্ধ করে ব্যাখ্যা শুরু করবেন।
এটা গুরুত্বপূর্ণ কারণ অধিকাংশ অপারেশনাল লক্ষণ পরোক্ষ। “মেশিন ধীর” হতে পারে CPU কণ্টেনশন, একক হট থ্রেড, ড্রাইভার ইন্টারাপ্ট স্টর্ম, পেজিং প্রেসার, বা অ্যান্টিভাইরাস ফিল্টার ফাইল I/O ব্লক করছে। “এটি হ্যাং করছে” হতে পারে ডেডলক, আটকে থাকা নেটওয়ার্ক কল, স্টোরেজ টাইমআউট, বা একটি সার্ভিস যে নির্ভরতায় অপেক্ষা করছে। ইন্টার্নালস জ্ঞান অস্পষ্ট অভিযোগগুলোকে পরীক্ষাযোগ্য হাইপোথিসিসে পরিণত করে।
উপরের স্তরে, ইউজার-মোডেই বেশিরভাগ অ্যাপ ও সার্ভিস চলে; এগুলো ক্র্যাশ করলে সাধারণত কেবল নিজেকে নিয়ে যায়। কার্নেল-মোডে উইন্ডোজ নিজেই এবং ড্রাইভারগুলি চলে; সেখানে সমস্যা হলে পুরো সিস্টেম ফ্রিজ, বাগচেক (ব্লু স্ক্রিন) কিংবা নীরবে নির্ভরযোগ্যতা কমতে পারে।
এ পার্থক্য ব্যবহার করতে গিয়ে গভীর তত্ত্বের দরকার নেই—শুধু যথেষ্ট যাতে আপনি প্রমাণ বেছে নিতে পারেন। একটি অ্যাপ CPU পেগ করলে সেটা প্রায়শই ইউজার-মোড; বারবার স্টোরেজ রিসেট বা নেটওয়ার্ক ড্রাইভার সমস্যা হলে সেটা কার্নেল-মোড ইঙ্গিত করে।
Russinovich-এর মানসিকতা—Sysinternals এবং Windows Internals-এ প্রতিফলিত—হল “প্রমাণ প্রথম।” সেটিং বদলানোর, অন্ধভাবে রিবুট দেওয়ার, বা পুনরায় ইনস্টল করার আগে, সিস্টেম ঠিক কি করছে তা ধরুন: কোন প্রসেস, কোন থ্রেড, কোন হ্যান্ডেল, কোন রেজিস্ট্রি কী, কোন নেটওয়ার্ক কানেকশন, কোন ড্রাইভার, কোন ইভেন্ট।
একবার আপনি উত্তর দিতে পারেন “উইন্ডোজ এখন কী করছে এবং কেন,” ফিক্সগুলো ছোট, নিরাপদ এবং যুক্তিসঙ্গত হয়ে ওঠে—এবং নির্ভরযোগ্যতা কাজ প্রতিক্রিয়াশীল ফায়ারফাইটিং থেকে বন্ধ হয়ে যায়।
Sysinternals সবচেয়ে ভালোভাবে বোঝা যায় একটি “দৃশ্যমানতা টুলকিট” হিসেবে: ছোট, পোর্টেবল ইউটিলিটি যেগুলো সিস্টেম আসলে কী করছে তা প্রকাশ করে—প্রসেস বাই প্রসেস, হ্যান্ডেল বাই হ্যান্ডেল, রেজিস্ট্রি কী বাই কী। উইন্ডোজকে একটি ব্ল্যাকবক্স হিসেবে না দেখে, Sysinternals আপনাকে “অ্যাপ ধীর”, “CPU উচ্চ”, বা “সার্ভার সংযোগ হারাচ্ছে” মত লক্ষণের পেছনের আচরণ পর্যবেক্ষণ করতে দেয়।
অপারেশনাল ব্যথার অনেকটাই যুক্তিসংগত শোনানো অনুমান থেকে আসে: এটা অবশ্যই DNS, এটা সম্ভবত অ্যান্টিভাইরাস, উইন্ডোজ আপডেট আবার আটকে গেছে। Sysinternals মনোভাব সহজ: আপনার অন্তঃদৃষ্টি যথেষ্ট করে একটি হাইপোথিসিস গঠন করুন, তারপর প্রমাণ দিয়ে তা যাচাই করুন।
কোন প্রসেস CPU খাচ্ছে, কোন থ্রেড অপেক্ষা করছে, কোন ফাইলপাথ টার্গেট হচ্ছে, বা কোন রেজিস্ট্রি ভ্যালু বারবার ওভাররাইট হচ্ছে—যখন আপনি এসব দেখতে পারেন, আলোচনা তর্ক থেকে সংকোচনে যায়। এই পরিবর্তন—কাহিনী থেকে পরিমাপ—ইইন্টার্নালস জ্ঞানকে ব্যবহারিক করে তোলে, শিক্ষাবিষয়ক নয়।
এই টুলগুলো “সবকিছু আগুনে” মুহূর্তের জন্য তৈরি:
এইগুলো তখনই জরুরি যখন আপনি দীর্ঘ সেটআপ সাইকেল, ভারী এজেন্ট রোলআউট, বা ভাল ডেটা সংগ্রহের জন্য রিবুট চালাতে পারবেন না।
Sysinternals শক্তিশালী, এবং শক্তি সহ গার্ড্রেইল দরকার:
এইভাবে ব্যবহৃত হলে, Sysinternals একটি শৃঙ্খলাবদ্ধ পদ্ধতি হয়: অদৃশ্যকে পর্যবেক্ষণ করুন, সত্য পরিমাপ করুন, এবং আশা নিয়ে নয়—যুক্তিসহ পরিবর্তন করুন।
যদি আপনি আপনার অ্যাডমিন টুলকিটে শুধু দুইটি Sysinternals টুল রাখেন, তা হলে রাখুন Process Explorer এবং Process Monitor। একসাথে এগুলো সবচেয়ে সাধারণ “উইন্ডোজ এখন কী করছে?” প্রশ্নগুলোর উত্তর দেয়, কোনো এজেন্ট, রিবুট, বা ভারী সেটআপ ছাড়াই।
Process Explorer হলো Task Manager-এর এক্স-রে ভিশন। যখন একটি মেশিন ধীর বা অস্থিতিশীল, এটা আপনাকে নির্দিষ্ট করে দেয় কোন প্রসেস দায়ী এবং কি সাথে এটি সংযুক্ত।
এটি বিশেষভাবে উপযোগী:
শেষটি একটি নির্ভরযোগ্যতা সুপারপাওয়ার: “কেন আমি এই ফাইলটি মুছতে পারি না?” প্রায়শই হয়ে ওঠে “এই সার্ভিসটির কাছে এটা ওপেন হ্যান্ডেল আছে।”
Process Monitor (Procmon) ফাইল সিস্টেম, রেজিস্ট্রি, এবং প্রসেস/থ্রেড কার্যকলাপ জুড়ে বিস্তারিত ইভেন্ট ক্যাপচার করে। এটি সেই টুল যখন আপনি জানতে চান: “অ্যাপ হ্যাং হলে কী বদলেছে?” বা “প্রতি 10 মিনিটে ডিস্ক কে টপকে দিচ্ছে?”
ক্যাপচার শুরু করার আগে প্রশ্নটি ফ্রেম করুন:
Procmon আপনাকে ওভারওয়েল্ম করতে পারে যদি আপনি কঠোরভাবে ফিল্টার না করেন। শুরু করুন:
সাধারণ ফলাফলগুলো খুবই ব্যবহারিক: একটি খাটো সার্ভিস বারবার অনুপস্থিত রেজিস্ট্রি কী কোয়েরি করছে, একটি রিয়েল-টাইম ফাইল স্ক্যান হাজার হাজার ফাইল স্পর্শ করছে, বা একটি মিসিং DLL লোড প্রচেষ্টা (“NAME NOT FOUND”) যা ব্যাখ্যা করে কেন একটি অ্যাপ এক মেশিনে শুরু হয় না কিন্তু অন্যটিতে হয়।
যখন একটি উইন্ডোজ মেশিন "অদ্ভুত লাগে," প্রায়শই একটি পূর্ণ মনিটরিং স্ট্যাক দরকার হয় না। কিছু Sysinternals টুল দ্রুত তিনটি বাস্তব প্রশ্নের উত্তর দিতে পারে: কি স্বয়ংক্রিয়ভাবে চালু হয়? কে নেটওয়ার্কে কথা বলছে? মেমরি কোথায় গেছে?
Autoruns হল দ্রুততম উপায় সবকিছুকে বোঝার যা ব্যবহারকারী স্পষ্টভাবে চালাবার আগেই লোড হতে পারে: সার্ভিস, শিডিউল টাস্ক, শেল এক্সটেনশন, ড্রাইভার ইত্যাদি।
কেন এটি নির্ভরযোগ্যতার জন্য গুরুত্বপূর্ণ: স্টার্টআপ আইটেমগুলো ধীর বুট, ইন্টারমিটেন্ট হ্যাং, এবং লগইন-পরবর্তী CPU স্পাইক-এর সাধারণ উৎস। একটি একেবারে অস্থিতিশীল আপডেটার, লেগ্যাসি ড্রাইভার হেলপার, বা ভাঙা শেল এক্সটেনশন পুরো সিস্টেমকে ব্যাহত করতে পারে।
প্রায়োগিক টিপ: প্রথমে unsigned, সাম্প্রতিকভাবে যোগকরা, বা লোড করতে ব্যর্থ এন্ট্রিগুলোর দিকে ফোকাস করুন। যদি একটি আইটেম নিষ্ক্রিয় করে বক্স স্থিতিশীল হয়, আপনি অস্পষ্ট লক্ষণকে একটি নির্দিষ্ট কম্পোনেন্টে পরিণত করেছেন যেটা আপডেট/অপসারণ/প্রতিস্থাপন করা যাবে।
TCPView আপনাকে প্রসেস নাম ও PID-র সাথে সংযুক্ত সক্রিয় কানেকশন এবং লিসেনারগুলোর একটি ইনস্ট্যান্ট মানচিত্র দেয়। দ্রুত স্যানিটি চেকের জন্য এটা আদর্শ:
নন-সিকিউরিটি তদন্তেও, এটি রানেরওয়ে এজেন্ট, ভুল কনফিগার করা প্রক্সি, বা “রিট্রাই স্টর্ম” আবিষ্কার করতে পারে যেখানে অ্যাপ ধীর মনে হলেও মূল কারণ নেটওয়ার্ক আচরণ।
RAMMap আপনাকে দেখায় RAM আসলে কোথায় বরাদ্দ করা হচ্ছে।
একটি ব্যবহারযোগ্য বেসলাইন পার্থক্য:
যদি ব্যবহারকারীরা “কম মেমরি” রিপোর্ট করে কিন্তু Task Manager বিভ্রান্তিকর দেখায়, RAMMap নিশ্চিত করতে পারে যে আপনার কাছে প্রকৃত প্রক্রিয়াজাত বৃদ্ধি আছে কি না, ভারী ফাইল ক্যাশ আছে কি না, অথবা কোনো ড্রাইভার ননপেজড মেমরি ব্যবহার করছে কি না।
যদি একটি অ্যাপ কয়েক দিন ধরে ধীর হয়ে যায়, Handle দেখাবে হ্যান্ডেল কাউন্ট অনবরত বাড়ছে কি না (একটি ক্লাসিক লিক প্যাটার্ন)। VMMap সাহায্য করবে যখন মেমরি ব্যবহার অদ্ভুত—ফ্র্যাগমেন্টেশন, বড় রিজার্ভড অঞ্চল, বা এমন অ্যলোকেশন যা সরল “private bytes” হিসেবে দেখা যায় না।
উইন্ডোজ অপারেশন প্রায়ই শুরু হয় সহজেই পাওয়া জিনিস দিয়ে: Event Viewer এবং কিছু Task Manager স্ক্রিনশট। সেটা ক্রামের জন্য ঠিক আছে, কিন্তু নির্ভরযোগ্য ইনসিডেন্ট রেসপন্সের জন্য তিনটি পরিপূরক সিগন্যাল দরকার: লগ (কি ঘটল), মেট্রিকস (কত খারাপ), এবং ট্রেস (সিস্টেম মুহূর্ত-প্রতি-কী করছিল)।
উইন্ডোজ ইভেন্ট লগ পরিচয়, সার্ভিস লাইফসাইকেল, নীতি পরিবর্তন এবং অ্যাপ-লেভেল ত্রুটির জন্য চমৎকার। তবু এগুলো অসমান: কিছু কম্পোনেন্ট সমৃদ্ধ লগ করে, কিছু কম করে, এবং মেসেজ টেক্সট ঝিমঝিম (“The application stopped responding”) হতে পারে। এগুলোকে টাইমলাইন অ্যাংকার হিসেবে নিন, পুরো গল্প হিসেবে নয়।
সাধারণ জয়:
পারফরম্যান্স কাউন্টারগুলো উত্তর দেয়, “মেশিন কি হেলদি?” আউটেজের সময় শুরু করুন:
মেট্রিকস আপনাকে কেন না বলে, কিন্তু কেন শুরু হয়েছে এবং এটি উন্নত হচ্ছে কি না তা বলবে।
Event Tracing for Windows (ETW) উইন্ডোজের বিল্ট-ইন ফ্লাইট রেকর্ডার। অ্যাড-হক টেক্সট মেসেজের বদলে, ETW কার্নেল, ড্রাইভার, এবং সার্ভিস থেকে স্ট্রাকচার্ড ইভেন্ট উত্সর্গ করে—প্রসেস/থ্রেড কার্যক্রম, ফাইল I/O, রেজিস্ট্রি অ্যাক্সেস, TCP/IP, শিডিউলিং, এবং আরও অনেক কিছু। অনেক “রহস্যময় স্টল” এই স্তরে বোধগম্য হয়ে ওঠে।
একটি ব্যবহারিক নিয়ম:
“সবকিছু সর্বদা চালু রাখুন” এড়ান। একটি ছোট সবসময়-অন বেসলাইন রাখুন (কী লগ + কোর মেট্রিকস) এবং ইনসিডেন্টে টার্গেটেড ETW ক্যাপচার ব্যবহার করুন।
সবচেয়ে দ্রুত নির্ণয় আসে তিনটি ঘড়ি মিলিয়ে: ব্যবহারকারীর রিপোর্ট (“10:42-এ ফ্রিজ”), মেট্রিক ইনফ্লেকশন (CPU/Disk স্পাইক), এবং লগ/ETW ইভেন্ট একই টাইমস্ট্যাম্পে। একবার আপনার ডেটা একটি সঙ্গত সময়ভিত্তি শেয়ার করলে, আউটেজগুলো অনুমান নয়—নিশ্চিত গল্প হয় যা যাচাই করা যায়।
উইন্ডোজের ডিফল্ট ইভেন্ট লগগুলো উপযোগী, কিন্তু প্রায়শই “কেন এখন?” বিস্তারিতগুলো অনুপস্থিত থাকে। Sysmon (System Monitor) সেই গ্যাপ পূরণ করে উচ্চ-ফিডেলিটি প্রসেস ও সিস্টেম কার্যকলাপ রেকর্ড করে—বিশেষ করে লঞ্চ, পারসিস্টেন্স, এবং ড্রাইভার আচরণ সংক্রান্ত।
Sysmon-এর শক্তি হল প্রসঙ্গ। কেবল “একটি সার্ভিস শুরু হয়েছে” বলার বদলে আপনি প্রায়ই দেখতে পাবেন কোন প্রসেস এটি শুরু করেছে, পূর্ণ কমান্ড লাইন, প্যারেন্ট প্রসেস, হ্যাশ, ইউজার অ্যাকাউন্ট, এবং করিলেশন-সহ টেম্পস্ট্যাম্প।
নির্ভরযোগ্যতার জন্য এটি মূল্যবান কারণ অনেক ইনসিডেন্ট ছোট পরিবর্তন দিয়ে শুরু হয়: একটি নতুন শিডিউল টাস্ক, একটি সাইলেন্ট আপডেটার, একটি ভুল স্ক্রিপ্ট, বা খারাপ আচরণকারী ড্রাইভার।
সবকিছু লগ করার Sysmon কনফিগ সাধারণত প্রথম ধাপে ভালো নয়। একটি ন্যূনতম, নির্ভরযোগ্যতা-কেন্দ্রিক সেট দিয়ে শুরু করুন এবং স্পষ্ট প্রশ্ন থাকলেই এক্সপ্যান্ড করুন।
ভালো প্রাথমিক পছন্দ:
টার্গেটেড include নিয়ম (ক্রিটিক্যাল পাথ, নির্দিষ্ট সার্ভিস একাউন্ট, কী সার্ভার) এবং সাবধানে নির্বাচিত exclude নিয়ম যুক্ত করুন যাতে সিগন্যাল পাঠযোগ্য থাকে।
Sysmon প্রায়ই এই সাধারণ “রহস্যময় পরিবর্তন” পরিস্থিতি নিশ্চিত বা বাতিল করতে সাহায্য করে:
প্রতিনিধি মেশিনে প্রভাব পরীক্ষা করুন। Sysmon ডিস্ক I/O এবং ইভেন্ট ভলিউম বাড়াতে পারে, এবং কেন্দ্রীভূত সংগ্রহ দ্রুত ব্যয়বহুল হতে পারে।
কম্যান্ডলাইন, ইউজারনেম, ও পাথের মত ফিল্ডগুলো সংবেদনশীল—অ্যাক্সেস কন্ট্রোল, রিটেনশন সীমা, এবং ফিল্টারিং প্রয়োগ করুন বিস্তৃত রোলআউটের আগে।
Sysmon সবচেয়ে ভাল উচ্চ-মূল্য ব্রেডক্রাম্ব হিসেবে কাজ করে। ETW-র সাথে গভীর পারফরম্যান্স প্রশ্নের জন্য, ট্রেন্ড সনাক্তের জন্য মেট্রিকস, এবং সংযুক্ত ইনসিডেন্ট নোটের সাথে ব্যবহার করুন যাতে আপনি কি বদলেছে তা, কেন সেটা ভেঙেছে, এবং কিভাবে ঠিক করা হয়েছে সেটি সংযুক্ত করতে পারেন।
কিছু যখন “শুধু ক্র্যাশ করে,” সবচেয়ে মূল্যবান আর্টিফ্যাক্ট প্রায়শই একটি ডাম্প ফাইল: মেমরির স্ন্যাপশট ও পর্যাপ্ত এক্সিকিউশন স্টেট সহ যাতে ব্যর্থতার মুহূর্তে প্রক্রিয়াটির কার্যকলাপ পুনর্নির্মাণ করা যায়। লগের মত নয়—ডাম্পগুলো আপনাকে পরে থেকেই প্রমাণ ধরে দেয়, তাই আপনাকে আগে সঠিক মেসেজ prévoir করতে হয় না।
ডাম্প সাধারণত একটি নির্দিষ্ট মডিউল, কল-পাথ, ও ব্যর্থতা প্রকার (access violation, heap corruption, deadlock, driver fault) দেখায়—যা লক্ষণ থেকে অনুমান করা কঠিন।
WinDbg এক ডাম্পকে গল্পে রূপান্তর করে। মূল বিষয়গুলো:
একটি সাধারণ ওয়ার্কফ্লো: ডাম্প খুলুন → সিম্বল লোড করুন → অটোমেটেড বিশ্লেষণ চালান → শীর্ষ স্ট্যাকে চেক করে যাচাই করুন।
“এটি ফ্রিজ” একটি লক্ষণ, নির্ণয় নয়। হ্যাং-এর জন্য, অ্যাপ অপ্রত্যাশিত অবস্থায় থাকাকালীন একটি ডাম্প নিন এবং পরীক্ষা করুন:
আপনি প্রায়ই নিজেই দ্রুত-স্পষ্ট ইস্যুগুলি ডায়াগনোসিস করতে পারবেন (এক মডিউলে পুনরাবৃত্ত ক্র্যাশ, স্পষ্ট ডেডলক, একটি নির্দিষ্ট DLL/ড্রাইভার-এ শক্ত সংশ্লেষ)। যখন ডাম্প তৃতীয়-পার্টি ড্রাইভার/সিকিউরিটি সফটওয়্যার, কার্নেল কম্পোনেন্ট, বা সিম্বল/সোর্স অ্যাক্সেস অনুপস্থিত করে—তখন এসক্যালেট করুন; সেই ক্ষেত্রে ভেণ্ডর (বা মাইক্রোসফট) পুরো চেইন ব্যাখ্যা করতে প্রয়োজন হতে পারে।
অনেক “রহস্যময় উইন্ডোজ ইস্যু” একই প্যাটার্ন বার বার প্রকাশ পায়। অনুমান ও মেরামতের মধ্যে পার্থক্য হল OS কী করছে তা বোঝা—এবং Internals/Sysinternals মানসিক মডেল আপনাকে সেটা দেখতে সাহায্য করে।
যখন লোকজন বলে “অ্যাপ লিক করছে,” তারা প্রায়শই দুটি ভিন্ন জিনিসের কথা বোঝায়।
Working set হল প্রসেসের ফিজিক্যাল RAM যা বর্তমানে ব্যাকিং দিচ্ছে। এটা চাপের সময় উইন্ডোজ যতাবে ট্রিম করতে পারে।
Commit হল ভার্চুয়াল মেমরি যা সিস্টেম র্যাম বা পেজ ফাইল দিয়ে ব্যাক করার প্রতিশ্রুতি দিয়েছে। যদি commit ধারাবাহিকভাবে বাড়ে, তাহলে আপনার একটি প্রকৃত লিক রিস্ক আছে: শেষ পর্যন্ত আপনি commit limit-এ পৌঁছাবেন এবং এলোকেশন ব্যর্থ হতে শুরু করবে বা হোস্ট অস্থিতিশীল হয়ে যাবে।
একটি সাধারণ লক্ষণ: Task Manager “available RAM” দেখালেও মেশিন ধীর—কারণ constraint হচ্ছে commit, খালি RAM নয়।
একটি হ্যান্ডেল হল OS অবজেক্টের রেফারেন্স (ফাইল, রেজিস্ট্রি কী, ইভেন্ট, সেকশন ইত্যাদি)। যদি একটি সার্ভিস হ্যান্ডেল লিক করে, তা ঘণ্টা বা দিন চলতে পারে, তারপর বিচিত্র ত্রুটি নিয়ে শুরু করবে (ফাইল খোলা যায় না, থ্রেড তৈরি করা যায় না, সংযোগ গ্রহণ করা যায় না) কারণ পার-প্রসেস হ্যান্ডেল কাউন্ট বাড়ছে।
Process Explorer-এ হ্যান্ডেল কাউন্ট ট্রেন্ড দেখুন। ধীর কিন্তু ধারাবাহিক বৃদ্ধি হলে এটি শক্তিশালী ক্লু যে সার্ভিসটি কিছু বন্ধ করতে ভুল করছে।
স্টোরেজ সমস্যা সবসময় উচ্চ থ্রুপুট হিসাবে দেখা যায় না; সেগুলো প্রায়ই উচ্চ লেটেনসি এবং রিট্রাই হিসেবে দেখা যায়। Process Monitor-এ দেখুন:
এছাড়াও ফিল্টার ড্রাইভার (AV, ব্যাকআপ, DLP) লক্ষ্য রাখুন—ওরা ফাইল I/O পথে নিজেকে ঢুকিয়ে বিলম্ব বা ব্যর্থতা যোগ করতে পারে, অ্যাপ্লিকেশন কিছু “ভুল” না করেও।
একটি একক হট প্রসেস সরাসরি চিনে নেওয়া যায়: এক্সিকিউটেবলটা CPU ঝরাচ্ছে।
সিস্টেম-ওয়াইড কণ্টেনশন জটিল: CPU উচ্চ কারণ অনেক থ্রেড runnable এবং লক, ডিস্ক, বা মেমরির উপর লড়াই করছে। ইন্টার্নালস চিন্তা আপনাকে জিজ্ঞাসা করতে বলে: “CPU কার্যকর কাজ করছে নাকি অন্য কোথাও ব্লক থেকে স্পিন করছে?”
টাইমআউট হলে প্রসেস → কানেকশন ম্যাপ করুন TCPView বা Process Explorer ব্যবহার করে। ভুল প্রসেস যদি সকেটের মালিক হয়, আপনি একটি নির্দিষ্ট কুকুর পেয়েছেন। যদি সঠিক প্রসেস মালিক হয়, তাহলে প্যাটার্ন দেখুন: SYN রিট্রাই, দীর্ঘস্থায়ী কানেকশন যা idle, বা ছোট-অবধি আউটবাউন্ড প্রচেষ্টার বিস্ফোরণ—যা DNS/firewall/proxy সমস্যার ইঙ্গিত দেয় না কি “অ্যাপ ডাউন”।
নির্ভরযোগ্যতা কাজ সহজ হয় যখন প্রতিটি ইনসিডেন্ট একই পথে চলে। লক্ষ্যটি "আরও টুল চালানো" নয়—বরং ধারাবাহিক প্রমাণ দিয়ে ভাল সিদ্ধান্ত নেওয়া।
“খারাপ” কেমন—এক বাক্যে লিখুন: “বড় ফাইল সেভ করার সময় অ্যাপ 30–60 সেকেন্ডের জন্য ফ্রিজ করে” অথবা “প্রতি 10 মিনিটে CPU 100% এ উঠে যায়।” যদি পুনরুত্পাদন সম্ভব হয়, প্রয়াস করুন; না হলে ট্রিগার সংজ্ঞায়িত করুন (টাইম উইন্ডো, ওয়ার্কলোড, ব্যবহারকারী ক্রিয়া)।
ভারী ডেটা ক্যাপচার করার আগে লক্ষণ ও স্কোপ নিশ্চিত করুন:
এখানে দ্রুত চেক (Task Manager, Process Explorer, বেসিক কাউন্টার) আপনাকে পরবর্তী ধাপ বেছে নিতে সাহায্য করবে।
বিশ্বাস করুন আপনি এই কেসটি যে টিমকে দেবেন তারা অগ্রহণযোগ্য—তারা সেখানে উপস্থিত ছিলেন না। একটি ভাল কেস ফাইলে সাধারণত থাকবে:
ক্যাপচারগুলো সংক্ষিপ্ত ও লক্ষ্যভিত্তিক রাখুন। একটি 60-সেকেন্ড ট্রেস যা ব্যর্থতা উইন্ডো কভার করে এমন 6-ঘণ্টার ক্যাপচারের থেকে ভাল।
আপনি যা সংগ্রহ করেছেন তা সরল গল্পে অনুবাদ করুন:
আপনি যদি সহজভাবে ব্যাখ্যা না করতে পারেন, সম্ভবত একটি পরিষ্কার ক্যাপচার বা আরো সংকীর্ণ হাইপোথিসিসের প্রয়োজন।
সবচেয়ে ছোট নিরাপদ ফিক্স প্রয়োগ করুন, তারপর একই পুনরুত্পাদন ধাপ ও “আগে বনাম পরে” ক্যাপচারের সাথে নিশ্চিত করুন।
MTTR কমাতে, প্লেবুক স্ট্যান্ডার্ড করুন এবং বিরক্তিকর কাজগুলো অটোমেট করুন:
সমাধানের পরে প্রশ্ন করুন: “কোন সিগন্যাল থাকলে এটা আগেই সহজতর হত?” সেই সিগন্যাল যোগ করুন—Sysmon ইভেন্ট, ETW প্রোভাইডার, একটি পারফরম্যান্স কাউন্টার, বা একটি হাল্কা হেলথ চেক—যাতে পরবর্তী ইনসিডেন্ট ছোট ও শান্ত হয়।
উইন্ডোজ ইন্টার্নালস কাজের উদ্দেশ্য ডিবাগ সেশনে জেতা নয়—এটি যা আপনি দেখলেন সেটা পরিবর্তনে রূপান্তর করে যাতে ইনসিডেন্ট ফিরে না আসে।
Internals টুলগুলো সাধারণত একটি সমস্যা ছোট সেট লিভারে সংকুচিত করে। অনুবাদটি স্পষ্ট রাখুন:
“কারণ লিখে রাখুন”: “আমরা X পরিবর্তন করেছি কারণ Process Monitor / ETW / ডাম্পে Y দেখা গেছে।” এই বাক্যটি ট্রাইবাল কনসেন্সকে প্রতিরোধ করবে।
আপনার পরিবর্তন প্রভাবের সাথে মেলান:
যদিও মূল কারণ নির্দিষ্ট, টেকসইতায় পুনরায় ব্যবহারযোগ্য প্যাটার্নগুলি প্রয়োগ করা যায়:
আপনি যা দরকার, সেটুকুই রাখুন; যা না রাখা উচিত তা রক্ষা করুন।
Procmon ফিল্টারটি সন্দেহভাজন প্রসেসে সীমাবদ্ধ রাখুন, শেয়ার করার আগে পাথ/ইউজারনেম স্ক্রাব করুন, ETW/Sysmon ডেটার রিটেনশন সীমা নির্ধারণ করুন, এবং প্রয়োজন ছাড়া পে-লোড-ভারি নেটওয়ার্ক ক্যাপচার এড়ান।
একবার আপনার একটি পুনরাবৃত্তিযোগ্য ওয়ার্কফ্লো থাকলে, পরের ধাপ হলো এটাকে "প্যাকেজ করা" যাতে অন্যরাও ধারাবাহিকভাবে চালাতে পারে। এখানে Koder.ai-এর মত প্ল্যাটফর্ম সহায়ক হতে পারে: আপনি আপনার ইনসিডেন্ট চেকলিস্টকে একটি ছোট অভ্যন্তরীণ ওয়েব অ্যাপে (React UI, Go ব্যাকএন্ড সাথে PostgreSQL) পরিণত করতে পারেন যা রেসপন্ডারদের “observe → capture → explain” গাইড করে, টাইমস্ট্যাম্প ও আর্টিফ্যাক্ট সংরক্ষণ করে, এবং নামকরণ ও কেস-ফাইল স্ট্যান্ডার্ড করে।
Koder.ai-তে চ্যাট ব্যবহার করে এপ তৈরি করা যায়, তাই টিমগুলো দ্রুত ইটারেট করতে পারে—"start ETW session" বোতাম, Procmon ফিল্টার টেমপ্লেট লাইব্রেরি, স্ন্যাপশট/রোলব্যাক বাটন, বা এক্সপোর্টেবল রানবুক জেনারেটর যোগ করা সহজ। যদি আপনি অভ্যন্তরীণ নির্ভরযোগ্যতা অনুশীলন শেয়ার করেন, Koder.ai সোর্স-কোড এক্সপোর্ট ও ফ্রিতে থেকে এন্টারপ্রাইজ পর্যায় পর্যন্ত সমর্থন করে, তাই ছোট থেকে governance পর্যন্ত ধাপে বাড়ানো যায়।
সপ্তাহে একবার একটি টুল এবং একটি 15-মিনিট অনুশীলন বেছে নিন: Procmon দিয়ে একটি স্লো অ্যাপ স্টার্ট ট্রেস করা, Process Explorer-এ একটি সার্ভিস ট্রি পর্যালোচনা, Sysmon ইভেন্ট ভলিউম চেক করা, বা একটি ক্র্যাশ ডাম্প নিয়ে ফেল রুকি করা এবং ব্যর্থ মডিউল শনাক্ত করা। ছোট রিপগুলি মসেল মেমোরি গড়ে তোলে যা প্রকৃত ইনসিডেন্টকে দ্রুত ও নিরাপদ করে তোলে।
মার্ক রাসিনোভিচ উইন্ডোজ ট্রাবলশুটিং-এ একটি প্রমাণ-প্রথম (evidence-first) মনোভাব জনপ্রিয় করেছেন এবং এমন টুল/ওয়ার্কফ্লোগুলো শৈল্পিকভাবে ছেড়েছেন যা OS-কে ব্যবহারযোগ্যভাবে পর্যবেক্ষণযোগ্য করে তোলে।
আপনি যদি কখনই Windows Internals না পড়েও থাকেন, তাহলে সম্ভবত Sysinternals, ETW, এবং ডাম্প বিশ্লেষণের দ্বারা গঠিত ওয়ার্কফ্লোগুলোর ওপর নির্ভর করছেন—এগুলো ঘটনার সময় কমাতে এবং ফিক্সগুলো পুনরায় অনুসরণযোগ্য করতে সাহায্য করে।
পর্যবেক্ষণযোগ্যতা (observability) হল সিস্টেমের প্রযোজিত সিগন্যাল থেকে “এখন কী ঘটছে?” উত্তর দেয়ার ক্ষমতা।
উইন্ডোজে এটা সাধারণত মানে:
ইন্টার্নালস জ্ঞান আপনাকে অস্পষ্ট লক্ষণগুলোকে পরীক্ষাযোগ্য হাইপোথিসিসে পরিণত করতে সাহায্য করে।
উদাহরণস্বরূপ, “সার্ভার ধীর” হওয়া CPU contention, paging pressure, I/O latency বা ড্রাইভার/ফিল্টার ওভারহেড—এসবের একটি ছোট সেট হিসেবে ব্যাখ্যা করা যায়। এভাবে দ্রুত ট্রায়াজ হয় এবং সঠিক প্রমাণ সংগ্রহ করা যায়, ফলে MTTR কমে।
Process Explorer ব্যবহার করুন যখন আপনি জানতে চান কে দায়ী:
Process Monitor (Procmon) ব্যবহার করুন যখন আপনাকে ফাইল, রেজিস্ট্রি এবং প্রসেস/থ্রেড ক্রিয়াকলাপের অ্যাকটিভিটি ট্রেইল জানতে হবে।
প্র্যাকটিক্যাল উদাহরণ:
কঠোরভাবে ফিল্টার করুন এবং শুধু ব্যর্থতা উইন্ডোই ক্যাপচার করুন।
শ্রেষ্ঠ শুরুয়াতি ওয়ার্কফ্লো:
একটি ছোট ট্রেস যা আপনারা খুলে বিশ্লেষণ করতে পারেন তা অনেক বড় অপ্রচলিত ক্যাপচারের থেকে ভাল।
Autoruns উত্তর দেয় “স্বয়ংক্রিয়ভাবে কি কি চালু হয়?”—সার্ভিস, শিডিউল টাস্ক, শেল এক্সটেনশন, ড্রাইভার ইত্যাদি।
এটি বিশেষভাবে কার্যকর:
প্রথমে এমন এন্ট্রিগুলোর দিকে মনোযোগ দিন যা , , বা হচ্ছে—এবং সন্দেহজনক আইটেম একবারে একটিভ করে নোট রাখুন।
ETW (Event Tracing for Windows) হলো উইন্ডোজের বিল্ট-ইন উচ্চ-ভলিউম স্ট্রাকচার্ড ট্রেসার।
লগ ও মেট্রিকস আপনাকে কি ভুল হচ্ছে সেটা বললেও, ETW বলে দেয় কেন—উদাহরণ: কোন I/O ব্লক করছে, কোন ড্রাইভার সময়সীমা ঘটাচ্ছে, কোন কল-পাথে বিলম্ব হচ্ছে।
ইতিবাচক অনুশীলন: সবকিছু অন করেই রাখবেন না—একটি ছোট সবসময়-চলমান বেসলাইন রাখুন (কী লগ + কোর মেট্রিকস) এবং ইনসিডেন্টের সময় টার্গেটেড ETW ক্যাপচার নিন।
Sysmon উচ্চ-কনটেক্সট টেলিমেট্রি যোগ করে (parent/child, command lines, হ্যাশ, ড্রাইভার লোড) যা “কি বদলেছে?” জানতে সাহায্য করে।
বিশেষত নির্ভরযোগ্যতার জন্য এটি কার্যকর:
প্রাথমিকভাবে একটি ন্যারো কনফিগ দিয়ে শুরু করুন এবং ইনক্লুড/এক্সক্লুড নিয়ম দিয়ে ভলিউম নিয়ন্ত্রণ করুন।
ডাম্প সাধারনত ক্র্যাশ ও হ্যাং-এর জন্য সবচেয়ে মূল্যবান আর্টিফ্যাক্ট কারণ এগুলো সময়ের মুহূর্তে এক্সিকিউশন স্টেট ক্যাপচার করে।
WinDbg ডাম্পকে একটি গল্পে পরিণত করে, কিন্তু সঠিক সিম্বল ছাড়া স্ট্যাকগুলো অর্থহীন হতে পারে।
