آشنايي با ويژگي DebuggerDisplay در VS.Net

كلاس ساده زير را در نظر بگيريد:

using System.Collections.Generic;

namespace testWinForms87
{
 class CDbgDisplay
 {
     public struct Person
     {
         public string Name;
         public int Id;
     }

     public static List<Person> GetData()
     {
         List<Person> data = new List<Person>();
         for (int i = 0; i < 40; i++)
             data.Add(new Person { Name = "P" + i, Id = i });
         return data;
     }
 }

}

فرض كنيد مي‌خواهيم هنگام فراخواني متد GetData بر روي data يك break point قرار دهيم تا بتوان محتواي آن‌را در VS.Net مشاهده كرد (شكل زير).

همانطور كه مشاهده مي‌كنيد، خروجي پيش فرض آنچنان دلپذير نيست. به ازاي هر كدام از 40 موردي كه در اين ليست قرار دارد، يكبار بايد آن آيتم مورد نظر را انتخاب كرد، بر روي علامت + كنار آن كليك نمود و سپس محتواي آن‌را مشاهده كرد.
براي سفارشي سازي خروجي ديباگر ويژوال استوديو مي‌توان از ويژگي DebuggerDisplay استفاده كرد. سطر زير را به بالاي ساختار person اضافه كنيد:

[DebuggerDisplay("Name:{Name},Id={Id}")]

اكنون يكبار ديگر بر روي data يك break point قرار داده و نتيجه را ملاحظه نمائيد (شكل زير):

بهتر شد؛ نه؟!
در اينجا يك رشته را با محتواي فيلدهاي ساختار Person ايجاد كرديم و سپس خروجي پيش فرض ديباگر VS.Net را با آن جايگزين نموديم. ويژوال استوديو محتواي عبارت داخل {} را با مقدار آن فيلد جايگزين خواهد كرد.

مايكروسافت crash analysis tool خود را سورس باز كرد

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

Analyze Crashes to Find Security Vulnerabilities in Your Apps

براي نمونه از اين ابزار در طي سال‌هاي 2005 تا 2006 جهت بررسي كدهاي ويندوز ويستا بهره‌ برداري شده و توسط آن بيش از 300 باگ امنيتي پيش از سوء استفاده از آن‌ها كشف و برطرف گرديده است. اين ابزار اطلاعات حاصل از يك كرش را بررسي كرده و باگ‌هاي امنيتي ممكن آن‌را گوشزد مي‌كند.

صفحه‌ي اصلي پروژه در CodePlex
exploitable Crash Analyzer

و دمويي در مورد فلسفه‌ي وجودي و كاربردهاي اين ابزار
دريافت

آناليز نحوه‌ي عملكرد ويروس Conficker

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

An Analysis of Conficker's Logic and Rendezvous Points

Conficker C Analysis

Debugger visualizers

از VS.Net 2005 به بعد، امكانات اشكال زدايي كدها به شدت بهبود يافته و يكي از امكانات جالبي كه به آن اضافه شده است، Debugger visualizers مي‌باشد، يعني امكان مشاهده‌ي محتواي اشياء در حين ديباگ. همچنين با استفاده از SDK ويژوال استوديو، برنامه نويس‌ها مي‌توانند Debugger visualizers سفارشي خودشان را نيز تهيه كنند. در ادامه به تعدادي از اين موارد اشاره خواهد شد:

• Xml Visualizer v.2 - site
• Data Debugger Visualizer - site
• WCF Visualizers Tool - site
• IL Visualizer - site
• DB Connection Visualizer - site
• LINQ to SQL Debug Visualizer - site
• Graphics Debugger Visualizer - site
• Bitmap Debugger Visualizer - site
• PowerShell Debug Visualizer - site
• WebVisualizers - site
• Sharepoint debug visualizer - site
• WPF Tree Debugger Visualizer - site
• GUID Debugger Visualizer - site
• WindowsIdentity Debugger Visualizer - site
• ControlTree visualizer - site
• Regular Expression Visualizers - site
• Improving Visual C++ Debugging - site
  

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

حدود يك سال قبل كامپيوتري را كه داشتم (اينتل پنتيوم 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 بار كرش كند!! و چه تصورات نامربوطي را نسبت به فروشنده سخت افزار در ذهن خود مرور كرده باشيد!

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

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