Windows میں واقعی کتنی میموری آزاد کی جا سکتی ہے

مختصر جواب

حقیقت میں اتنے میموری آزاد کی جا سکتی ہے جتنا “میموری آپٹیمائزر” وعدہ کرتے ہیں اس سے کم۔ اس تجربے میں پس منظر کے اجزاء کو بند کرنے سے 1,0–1,5 GB دستیاب میموری آزاد ہوئی اور سیریز 2 میں commit کا حجم 52 % کم ہوا۔ لیکن مقبول تیز طریقے کام نہیں کرتے: شیل کے پروسیسز کو ختم کرنا — Windows انہیں خود تقریباً 20 سیکنڈ میں دوبارہ شروع کر دیتا ہے؛ working set کی صفائی — خارج شدہ صفحات RAM میں بطور کیش رہتے ہیں؛ میموری مینیجر کے رجسٹری پیرامیٹرز — کوئی تصدیق شدہ فائدہ نہیں۔ پہلے سے آپٹیمائزڈ سسٹم کے اوپر نقطہ وار بندشوں نے ایماندارانہ +22–30 MB دیے۔ standby فہرست میں موجود میموری ایک کیش ہے جو پہلے ہی “دستیاب” میں شمار ہے۔

حالت: حتمی اعداد 8 GB RAM والی Windows 11 (26H2, build 26300.9457) کی ورچوئل مشین میں حاصل کیے گئے۔ سمتوں کی تصدیق Microsoft کی دستاویزات اور ہمارے کنٹرول شدہ تجربات سے ہوئی؛ مطلق اقدار کسی دوسری کنفیگریشن پر مختلف ہوں گی۔

قابلِ تصدیق دعوے

ہم نے چار دعووں کی جانچ کی:

1. “غیر ضروری” پس منظر کے پروسیسز کو ختم کرنا میموری آزاد کرتا ہے۔
2. working set یا standby فہرست کی صفائی (“RAM آپٹیمائزر” کی میکانیات) میموری آزاد کرتی ہے۔
3. میموری مینیجر کے رجسٹری پیرامیٹرز نمایاں طور پر میموری آزاد کرتے ہیں۔
4. پس منظر کے اجزاء کو بند کرنا بڑی مقدار میں میموری آزاد کرتا ہے۔

تحقیق کا دائرہ

• Windows 11 Pro, build 26300.9457 (26H2)؛ ورچوئل مشین، 8 GB RAM؛
• ایک ہی انسٹالیشن کی دو حالتیں: اصل (“پہلے”) اور BoosterX آپٹیمائزیشن پروفائل لاگو کرنے کے بعد — پیمائش دو آزاد سیریز میں کی گئی (تفصیلی پروٹوکول اور باقی میٹرکس — «خاموش بیکاری: آپٹیمائزیشن سے پہلے اور بعد میں Windows کا پس منظر» میں)؛
• “بعد” کی حالت کے اوپر — پس منظر کے ذرائع کی نقطہ وار بندشوں کا پیکج (تشخیصی ETW آٹو لاگرز، اطلاعات، شیڈو کاپی اور اپڈیٹ آرکسٹریٹر کی سروسز)؛
• میٹرکس: دستیاب اور مصروف میموری، commit کا حجم، nonpaged/paged pool، فی پروسیس working set اور private bytes، صفحہ کی غلطیاں (hard faults)۔

شامل نہیں کیا: فزیکل ہارڈویئر، مختلف RAM حجم والے سسٹمز، pagefile بند کرنے کے تجربات اور تیسرے فریق کے “میموری آپٹیمائزیشن” ٹولز۔

طریقہ کار

• میموری کی انوینٹری مستحکم بیکاری میں لی گئی: سسٹم کاؤنٹرز (دستیاب، مصروف، commit، پولز) اور working set اور private bytes کے ساتھ پروسیسز کی فہرست۔
• کنٹرول شدہ تجربہ “شیل پروسیسز ختم کریں”: انٹرفیس کے دو پروسیسز (SearchHost.exe اور StartMenuExperienceHost) روکے گئے، حالت 20 اور 40 سیکنڈ بعد جانچی گئی؛ commit پہلے اور بعد میں ریکارڈ کیا گیا۔
• نقطہ وار بندشوں کا پیکج “بعد” کی حالت پر لاگو کیا گیا، پھر ری بوٹ اور اسی حالت کے چار کنٹرول بوٹس کے ساتھ موازنہ کیا گیا جن میں پیکج نہیں تھا؛ بوٹ ٹیسٹس نے کارکردگی میں کمی کی عدم موجودگی کی جانچ کی۔
• پیمائشی پرت (ٹریسنگ، کاؤنٹرز، جمع آوری کے اسکرپٹس) خود میموری لیتی ہے — الگ الگ پیمائشوں میں سو اور اس سے زیادہ MB working set تک؛ یہ حدود میں بیان کیا گیا ہے۔

نتائج

پس منظر کتنی جگہ لیتا ہے

بیکاری میں انوینٹری کا اسنیپ شاٹ (سیریز 1):

	پہلے	بعد	تبدیلی
کل working set، MB	3 841	1 868	−51 %
کل private bytes، MB	1 524	660	−57 %
دستیاب میموری، MB	5 490	6 518	+1 028

سیریز 2: مصروف میموری 3 017 → 1 538 MB، دستیاب 5 174 → 6 653 MB، commit کا حجم 2 617 → 1 249 MB۔ سمت دونوں سیریز میں یکساں ہے: پس منظر کے اجزاء اس پروفائل کی مصروف میموری کا تقریباً نصف رکھتے ہیں۔

مصروف میموری کی ساخت

“بعد” کی حالت میں میموری اس طرح تقسیم تھی (کل working set، سیریز 1):

• شیل (فائل ایکسپلورر، DWM، Start مینو میں تلاش، سیشن ہوسٹ) — تقریباً 640 MB؛
• پس منظر کی سروسز — تقریباً 640 MB (39 ہوسٹ پروسیسز میں 57 سروسز)؛
• تلاش کا ویب جزو — تقریباً 320 MB؛
• کرنل پولز — تقریباً 167 MB، جن میں سے تقریباً 76 MB رجسٹری پولز لیتے ہیں۔

پروسیس کا working set آزاد ہونے والی میموری کے برابر نہیں: اس میں مشترکہ صفحات (سسٹم لائبریریوں کا کوڈ، مشترکہ ڈیٹا) شامل ہوتے ہیں جو ہر پروسیس میں بیک وقت شمار ہوتے ہیں۔ سیریز 1 کی “بعد” حالت میں 75 پروسیسز کے working set کا مجموعہ 1 868 MB تھا، اور private bytes کا مجموعہ — 660 MB؛ نقطہ وار بندشوں کے تجربے کے کنٹرول بوٹس میں کل working set 2 036 MB تھا۔ سب سے بڑے انٹرفیس پروسیسز (سیریز 2):

پروسیس	Working set، MB	Private، MB
SearchHost.exe (تلاش)	187	80
explorer.exe (فائل ایکسپلورر)	167	36
StartMenuExperienceHost	107	24
dwm.exe (DWM)	73	34

“بعد” کی حالت میں standby فہرست 711 MB تھی۔ یہ گم شدہ میموری نہیں بلکہ کیش ہے: standby پہلے ہی “دستیاب” میں شمار ہے، اور Windows ان صفحات کو فوراً دوبارہ استعمال کرتا ہے جب کوئی ایپلیکیشن میموری مانگتی ہے۔

تجربہ: شیل پروسیسز کو ختم کرنا

SearchHost.exe اور StartMenuExperienceHost روکنے کے بعد (سیریز 2):

• دونوں پروسیسز تقریباً 20 سیکنڈ میں نئے شناخت کنندگان کے ساتھ خودکار طور پر دوبارہ شروع ہو گئے؛ 40 سیکنڈ بعد وہ اب بھی چل رہے تھے؛
• commit کا حجم کم نہیں ہوا بلکہ 12,6 MB بڑھ گیا (1 386,9 سے 1 399,5 MB تک) — شیل پروسیسز کا دوبارہ آغاز خود نیا کام پیدا کرتا ہے؛
• “دستیاب” میموری میں 93 MB کا عارضی اضافہ بچت نہیں ہے: ہدف پروسیسز واپس آ گئے، commit بڑھ گیا۔

الگ پیمائش (سیریز 1) میں فائل ایکسپلورر کو ختم کرنے سے بھی آزاد میموری میں مستحکم اضافہ نہیں ہوا: اس ونڈو میں آزاد میموری حتیٰ کہ 97 MB کم ہوئی جبکہ standby 13 MB بڑھی — خارج شدہ صفحات سسٹم میں بطور کیش رہتے ہیں، اور شیل اور متعلقہ پروسیسز کام جاری رکھتے ہیں۔

تجربے کا نتیجہ: سسٹم پروسیسز کو زبردستی ختم کرنا میموری آزاد نہیں کرتا۔ Windows شیل کے اجزاء خودکار طور پر دوبارہ شروع کرتا ہے، اور بچت کے بجائے آپ کو اضافی بوجھ ملتا ہے۔

working set اور standby فہرست کی صفائی

میکانیات Microsoft کی دستاویز شدہ ہیں۔ working set سے صفحات کا اخراج (مثلاً EmptyWorkingSet فنکشن یا “خالی” سائز کے ساتھ SetProcessWorkingSetSize سے — بالکل یہی “RAM آپٹیمائزر” استعمال کرتے ہیں) صفحات کو عبوری حالت میں منتقل کرتا ہے: وہ RAM میں کیش شدہ رہتے ہیں جب تک دوبارہ ضرورت نہ ہو یا دوبارہ استعمال نہ ہوں۔ ایسے صفحے تک پروسیس کی اگلی رسائی — نرم صفحہ کی غلطی اور working set میں واپسی ہے۔

اسی لیے working set کی صفائی کاؤنٹرز میں “خالی” کا ہندسہ بدلتی ہے لیکن جسمانی طور پر دستیاب میموری پیدا نہیں کرتی: صفحات کہیں غائب نہیں ہوتے، اور ان تک دوبارہ رسائی مہنگی ہو جاتی ہے۔ standby فہرست کی صفائی بھی اسی وجہ سے بے معنی ہے: standby پہلے ہی سسٹم کے لیے دستیاب میموری ہے۔ ہماری پیمائشوں میں دونوں حالتوں میں میموری پر pressure موجود نہیں تھا (hard faults کم رہے)، اس لیے اضافی اخراج کچھ بہتر نہیں کرتا۔

اس تجربے سے ہمارا معیار: “میموری آزاد کرنے” کے نتیجے کو commit، صفحہ کی غلطیوں اور میموری کے دوبارہ استعمال میں تاخیر سے جانچنا چاہیے، نہ کہ “خالی” لائن کے عارضی اضافے سے۔

نقطہ وار بندشیں: ایماندارانہ اضافہ

“بعد” کی حالت کے اوپر ہم نے نو تشخیصی ETW آٹو لاگرز اور چار پس منظر سروسز (اطلاعات، شیڈو کاپی، اپڈیٹ آرکسٹریٹر) بند کیں اور نتیجے کا چار کنٹرول بوٹس سے موازنہ کیا:

میٹرک	کنٹرول بوٹس	پیکج کے ساتھ	فرق
آزاد میموری، MB	6 664–6 674	6 696	+22…+30
Nonpaged pool، MB	69,8–71,8	58,7	−11…−13
کل working set، MB	2 036	1 959	−77
ٹیسٹ کی کارکردگی	بغیر تبدیلی	بغیر تبدیلی	—

صرف آٹو لاگرز نے −13,2 MB nonpaged pool دیا (الگ سے ماپا گیا)۔ اہم: انوینٹری کے مطابق بند کیے گئے اجزاء کے working set کا مجموعہ تقریباً 78 MB تھا، جبکہ آزاد میموری میں حقیقی اضافہ +22–30 MB تھا۔ فرق اس لیے پیدا ہوتا ہے کہ “بند” کیے گئے حصے کا ایک حصہ ویسے بھی نہیں چل رہا تھا۔ یہی سسٹم کے اجزاء کو حذف کیے بغیر نقطہ وار بندشوں کی ایماندار حد ہے؛ ضمنی طور پر اسی پیکج نے بیکاری کی پس منظر کی سرگرمی مزید 24 % کم کی۔

میموری مینیجر کے رجسٹری پیرامیٹرز (پولز کے سائز، سسٹم کیش اور مشابہ) کو اس تجربے میں فائدے کے ذریعے کے طور پر حتیٰ کہ زیر غور بھی نہیں لایا گیا: ان کی پڑھائی اور عملی افادیت «Memory Manager اور سسٹم cache» میں بیان کی گئی ہے — RAM آزاد کرنے کے لیے ان کا کوئی تصدیق شدہ فائدہ نہیں۔

کیا تصدیق ہوا

• دہرایا گیا (دو سیریز): پس منظر کے اجزاء کو بند کرنا 1,0–1,5 GB دستیاب میموری آزاد کرتا ہے؛ کل working set 51 % کم ہوا (سیریز 1)، مصروف میموری — 49 % اور commit کا حجم — 52 % (سیریز 2)۔
• ماپا گیا: روکے گئے شیل پروسیسز کا خودکار دوبارہ آغاز 20 سیکنڈ کے اندر؛ commit اس دوران کم نہیں ہوتا (ہمارے تجربے میں 12,6 MB بڑھا)۔
• ماپا گیا: فائل ایکسپلورر کو ختم کرنا آزاد میموری میں مستحکم اضافہ نہیں دیتا؛ خارج شدہ صفحات standby میں رہتے ہیں۔
• دستاویز شدہ: working set سے صفحات کا اخراج انہیں عبوری، RAM میں کیش شدہ حالت میں منتقل کرتا ہے؛ standby میموری دستیاب میں شمار ہوتی ہے۔
• ماپا گیا: آپٹیمائزڈ سسٹم کے اوپر نقطہ وار بندشیں غیر متغیر کارکردگی کے ساتھ +22–30 MB آزاد میموری دیتی ہیں؛ بند کیے گئے کا working set کا مجموعہ آزاد میں اضافے کے برابر نہیں۔

کیا تصدیق نہیں ہوا

• تیسرے فریق کے “RAM آپٹیمائزر” براہ راست ٹیسٹ نہیں کیے گئے: وہ میکانیات جانچی گئی (working set کی صفائی) جس پر وہ بنتے ہیں۔
• pagefile بند کرنا نہیں ماپا گیا؛ صرف یہ معلوم ہے کہ pagefile crash dump اور میموری commit کی حد کے لیے ضروری ہے۔
• اقدار کو مختلف RAM حجم، مختلف بلڈز اور فزیکل ہارڈویئر والی مشینوں پر منتقل کرنا۔
• طویل ونڈوز پر بچت کا استحکام: پیمائشیں مستحکم بیکاری میں کی گئیں۔

حدود

• 8 GB RAM والی ورچوئل مشین: مطلق اعداد اس کنفیگریشن سے بندھے ہیں؛ زیادہ پس منظر اجزاء والا پروفائل زیادہ آزاد کرے گا، “خاموش” سسٹم — کم۔
• پروسیسز کے حساب سے working set کا مجموعہ مشترکہ صفحات کی وجہ سے منفرد اثر کو بڑھا چڑھا کر دکھاتا ہے؛ اسی لیے ہم ساتھ private bytes دیتے ہیں۔
• پیمائشی پرت خود نمایاں میموری لیتی تھی (الگ پیمائشوں میں سینکڑوں MB working set تک) — حالت کے اعداد میں پیمائش کی موجودگی شامل ہے۔
• تجربے میں میموری کا دباؤ نہیں تھا (hard faults کم)، اس لیے ہم نے یہ نہیں جانچا کہ بچت RAM کی کمی کے حالات میں thrashing کم کرتی ہے یا نہیں۔
• بچت کا ایک حصہ Microsoft Defender کے تحفظاتی اجزاء کو بند کرنے سے متعلق ہے — یہ سیکیورٹی کے ساتھ سمجھوتہ ہے، نہ کہ مفت میں ملنے والی میموری۔

تحقیق اور استعمال شدہ ٹولز BoosterX کے ڈویلپر کی ملکیت ہیں، اور BoosterX ایک Windows آپٹیمائزر ہے، اس لیے آپٹیمائزیشن کے اثر کی پیمائش اس کا براہ راست مفاد ہے۔ طریقہ کار اور اطلاق کی حدود اوپر بیان کی گئی ہیں، اور نتائج کھلے ڈیٹا اور درج عوامی ذرائع سے جانچے جا سکتے ہیں۔ “میموری آزاد کرنے” کے مقبول طریقوں پر منفی نتائج مثبت نتائج کے برابر شائع کیے گئے ہیں۔

عملی نتیجہ

اس تجربے کے مطابق، حقیقت میں میموری کیا آزاد کرتا ہے:

• غیر استعمال شدہ ایپلیکیشنز بند کریں — ان کے private bytes مکمل طور پر آزاد ہوتے ہیں؛
• واقعی غیر ضروری پس منظر کے اجزاء بند کریں — ماپا گیا مجموعی اثر «خاموش بیکاری» میں بیان کیا گیا ہے؛ یہ جانچے گئے طریقوں میں واحد ہے جس نے گیگابائٹس دیے، اور اس کی قیمت متعلقہ خصوصیات کا نقصان ہے؛
• نتیجے کو commit اور دستیاب میموری سے جانچیں (ٹاسک مینیجر → “کارکردگی” → “میموری”)، نہ کہ “خالی” لائن سے۔

کیا کام نہیں کرتا:

• سسٹم پروسیسز کو زبردستی ختم کرنا: Windows انہیں سیکنڈوں میں دوبارہ شروع کر دیتا ہے، commit بڑھتا ہے؛
• “RAM آپٹیمائزر” اور standby کی صفائی: خارج شدہ صفحات RAM میں بطور کیش رہتے ہیں، اور انہیں دوبارہ کام میں لانے کی قیمت نرم صفحہ کی غلطیاں ہیں؛
• میموری مینیجر کے رجسٹری پیرامیٹرز۔

standby میموری مسئلہ نہیں بلکہ کیش کا کام ہے: “دستیاب” پہلے ہی اسے شامل کرتی ہے۔ pagefile کو سسٹم کے کنٹرول میں رہنے دیں: یہ میموری commit کی حد اور کریش ڈمپس کے لیے ضروری ہے۔

حالت کی بحالی

تجربات الگ تھلگ ورچوئل مشین میں حالت کی ٹیسٹ برانچز پر کیے گئے؛ پیمائشوں کے بعد ٹیسٹ برانچز ری سیٹ کر دی گئیں، مشین اصل حالت میں واپس لائی گئی۔ مضمون سسٹم پروسیسز کو ختم کرنے یا pagefile بند کرنے کی سفارش نہیں کرتا، اس لیے صارف کے کمپیوٹر پر الگ بحالی کے عمل کی ضرورت نہیں۔

عوامی بنیادی ذرائع

• Microsoft: Working Set — working set کی ساخت، صفحات کا اخراج، RAM میں کیش شدہ عبوری صفحات، اور EmptyWorkingSet/SetProcessWorkingSetSize فنکشنز؛ جانچا گیا 2026-09-20۔
• Microsoft: EmptyWorkingSet — “میموری آپٹیمائزیشن” ٹولز کا استعمال کردہ API؛ جانچا گیا 2026-09-20۔
• Microsoft: About Memory Management — ورچوئل میموری اور مشترکہ صفحات کا ماڈل؛ جانچا گیا 2026-09-20۔
• Microsoft: Introduction to the page file — commit charge، commit کی حد اور pagefile کا کردار؛ جانچا گیا 2026-09-20۔
• Memory Manager اور سسٹم cache — میموری مینیجر کے رجسٹری پیرامیٹرز کی تحقیق۔
• خاموش بیکاری: آپٹیمائزیشن سے پہلے اور بعد میں Windows کا پس منظر — پیمائش کا پروٹوکول اور اسی تجربے کے باقی میٹرکس۔
• ہم Windows کی تحقیق کیسے کرتے ہیں — ثبوت کی سطحیں اور پیمائش کے قواعد۔

تبدیلیوں کی تاریخ

• 2026-09-20: اعداد کو سیریز کے جدولوں کے مطابق کیا گیا: سیریز 1 کی “بعد” — 1 868/660 MB، میٹرکس اور سیریز کے حساب سے فیصد کی نسبت واضح کی گئی؛ مفادات کے تصادم کا ڈس کلیمر مکمل صیغے تک مضبوط کیا گیا۔
• 2026-09-20: پہلی اشاعت — دو سیریز میں میموری کی انوینٹری، پروسیسز کو ختم کرنے اور صفائی کے منفی تجربات، نقطہ وار بندشوں کا ایماندارانہ اضافہ۔