بررسي دقيق‌تر صفحات آبي ويندوز

حدود يك سال قبل كامپيوتري را كه داشتم (اينتل پنتيوم 4) به يك AMD دوهسته‌اي ارتقاء دادم و هفته‌ي اول پس از ارتقاء، روزگار من سياه شد! روزهاي اول 2 بار كرش ويندوز و مشاهده صفحه آبي و روزهاي بعد تا 7 بار اين اتفاق تكرار مي‌شد. حتي تا تعويض مادربرد جديد هم پيش رفتم ولي تاثيري نداشت. تست رم و غيره هم انجام شد، مشكلي نبود. خلاصه اينجا بود كه از سر ناچاري به اين فكر افتادم كه آيا اين پيغام‌هاي صفحه‌ي آبي ويندوز را مي‌شود تفسير كرد؟ مشكل دقيقا از كجاست؟ چون در اين موارد به هر كسي كه مراجعه كنيد بر اساس تجربه قبلي يك نسخه براي شما خواهد پيچيد. رمت خرابه! بايوست رو ارتقاء بده! (اين مورد تاثير داشت! ولي تعداد كرش‌ها صفر نشد) مادربردت مشكل داره و ...

تمام اين‌ها بر اساس تجربيات قبلي اين افراد است و ارزشمند. ولي آيا اين جواب‌ها قانع كننده هستند؟ چرا بايد رم را عوض كرد؟ از كجا فهميديد مادربرد مشكل داره؟

شركت‌هايي مثل apple براي اينكه با اين نوع مشكلات مواجه نشوند، به صورت انحصاري با توليد كنندگان سخت افزار قرار داد مي‌بندند و در نتيجه سيستم‌ عاملي هم كه توليد مي‌كنند بسيار پايدار خواهد بود چون بر اساس سخت افزاري كاملا مشخص، طراحي و تست شده است. اما در مورد ويندوز اين‌طور نيست.
ضمنا هيچ الزامي هم ندارد كه اين صفحه آبي ويندوز بدليل مشكلات سخت افزاري حاصل شود (وجود سخت افزار معيوب). ضعف برنامه نويسي و خصوصا درايورهاي مشكل دار هم مي‌توانند سبب ايجاد اين نوع صفحات آبي شوند كه مشكل من هم دقيقا همين مورد بود كه در ادامه نحوه بررسي آن‌را توضيح خواهم داد. (البته سطح اين مطلب را مقدماتي در نظر بگيريد)

در ويندوز اين امكان وجود دارد كه پس از هر بار كرش سيستم عامل و مشاهده صفحه آبي يك دامپ كرنل نيز به صورت خودكار حاصل شود. اين فايل دامپ را مي‌توان پس از راه اندازي مجدد سيستم با يك سري ابزار آناليز كرد و علت دقيق كرش ويندوز را بدست آورد.
براي اينكه اين فايل‌هاي دامپ توليد شوند بايد مراحل زير مطابق تصوير طي شوند:

اكنون بعد از هر كرش و صفحه آبي ويندوز يك فايل دامپ در دايركتوري C:\WINDOWS\Minidump تشكيل مي‌شود. براي آناليز اين فايلها به صورت زير مي‌شود عمل كرد:
ابتدا برنامه زير را دانلود كنيد:
Debugging Tools for Windows

پس از نصب، Debugging Tools for Windows را خواهيد داشت كه جهت ديباگ كردن سيستم و آناليز فايلهاي دامپ و غيره كاربرد دارد.

سپس مطالعه مقاله زير در مورد نحوه استفاده از اين ابزار بسيار مفيد است:
http://support.microsoft.com/kb/315263

به صورت خلاصه :
يك فايل bat درست كنيد با محتويات زير و دقيقا به همين شكل:

c:\windbg\kd -y srv*c:\symbols*http://msdl.microsoft.com/download/symbols -i c:\windows\i386 -z %1

در اين دستور سه مورد قابل ملاحظه است:
الف) مسير فايل kd.exe كه توسط پكيج Debugging Tools for Windows نصب مي‌شود. (مطابق سيستم خودتان آنرا اصلاح كنيد)
ب) مسير c:\windows\i386 بدين معنا است كه دايركتوري i386 سي دي ويندوز را در اين مسير كپي كرده‌ايد يا خواهيد كرد (نياز به يك ويندوز تر و تازه و نصب نشده خواهد بود).
ج) مسير c:\symbols خودبخود ايجاد خواهد شد و فايلهاي مربوطه از سايت مايكروسافت توسط برنامه kd.exe دانلود مي‌شود (بنابراين بايد دسترسي به اينترنت نيز داشت).

فرض كنيد نام اين فايل را test.bat گذاشته‌ايد.
براي آناليز فايل Mini102607-07.dmp در دايركتوري ميني دامپ ويندوز (07 در اينجا يعني هفتمين كرش روز مربوطه!) دستور زير را در خط فرمان صادر كنيد:

test.bat C:\WINDOWS\Minidump\Mini102607-07.dmp

پس از مدتي اين برنامه كار آناليز را تمام خواهد كرد و گزارشي را ارائه مي‌دهد (يك فايل log متني تشكيل خواهد شد).
نتيجه يك نمونه از اين آناليزهاي سيستم من به صورت زير بود:

BAD_POOL_CALLER (c2)
The current thread is making a bad pool request.  Typically this is at a bad IRQL level or double freeing the same allocation, etc.
Arguments:
Arg1: 00000007, Attempt to free pool which was already freed
Arg2: 00000cd4, (reserved)
Arg3: 02060008, Memory contents of the pool block
Arg4: 88b4a118, Address of the block of pool being deallocated

Debugging Details:
------------------

POOL_ADDRESS:  88b4a118

FREED_POOL_TAG:  TCPc

BUGCHECK_STR:  0xc2_7_TCPc

CUSTOMER_CRASH_COUNT:  4

DEFAULT_BUCKET_ID:  COMMON_SYSTEM_FAULT

PROCESS_NAME:  System

LAST_CONTROL_TRANSFER:  from 8054a583 to 804f9deb

STACK_TEXT:
ba4f3874 8054a583 000000c2 00000007 00000cd4 nt!KeBugCheckEx+0x1b
ba4f38c4 b043d3ff 88b4a118 00000000 ba4f390c nt!ExFreePoolWithTag+0x2a3
ba4f38d4 b043cca3 883ae760 883ae7f4 883ae7f4 tcpip!TCPClose+0x16
ba4f390c b02f3161 8a74fe20 883ae760 b02f2a6d tcpip!TCPDispatch+0x101
WARNING: Stack unwind information not available. Following frames may be wrong.
ba4f3984 b03e2046 00000001 00000000 ba4f39d8 vsdatant+0x45161
ba4f39d8 b03e921c 00000008 ba4f3aac 00000000 ipnat!NatpRedirectQueryHandler+0x250
ba4f3a70 00000000 8837d8e8 0000000d 000005ee ipnat!NatpDirectPacket+0xd2

STACK_COMMAND:  kb

FOLLOWUP_IP:
vsdatant+45161
b02f3161 ??              ???

SYMBOL_STACK_INDEX:  4

SYMBOL_NAME:  vsdatant+45161

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: vsdatant

IMAGE_NAME:  vsdatant.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  46e0766a

FAILURE_BUCKET_ID:  0xc2_7_TCPc_vsdatant+45161

BUCKET_ID:  0xc2_7_TCPc_vsdatant+45161

Followup: MachineOwner

به لاگ حاصل از دو ديدگاه مي‌توان پرداخت: الف) اگر من برنامه نويس مربوطه باشم، با trace موجود در لاگ فايل، مشخص مي‌شود كه كجاي كار مشكل داشته است ، ب) يا اينكه خير. بنده توسعه دهنده درايور نيستم. حداقل اسم دقيق درايور يا پروسه مشكل‌زا را مي‌توان از اين لاگ بدست آورد.

خوب! تا اينجا مشخص شد كه دليل كرش، درايور vsdatant.sys است. با جستجو در اينترنت مشخص شد كه اين درايور مربوط به فايروال زون آلارم است! (همين عبارت بالا يا نام درايور ذكر شده را مستقيما در گوگل جستجو كنيد)
پس از آن زون آلارم را با outpost firewall جايگزين كردم و تا الان كرشي حاصل نشده است (حتي يكبار از سال قبل تا به امروز). جدا زندگي من مختل شده بود. تصور كنيد سيستم شما روزي 7 بار كرش كند!! و چه تصورات نامربوطي را نسبت به فروشنده سخت افزار در ذهن خود مرور كرده باشيد!

خلاصه‌ي كلام:
صفحات آبي ويندوز قابل تفسير هستند. پديد آمدن آنها الزاما بدليل وجود سخت افزار معيوب نيست و به صرف اينكه شخصي به شما گفته "رمت خرابه!" اكتفا نكنيد.

پ.ن.
لاگ فوق مربوط به يك سال قبل است و احتمالا شايد زون آلارم‌هاي جديد اين مشكل را نداشته باشند.