Event Viewer در ویندوز؛ خواندن لاگ سیستم مثل یک توسعه‌دهنده

وقتی نصب‌کننده فقط می‌گوید failed، سرویس Start می‌شود و فوری می‌خوابد، یا کرش زیرساختی بدون لاگ مفید در کنسول دارید، Event Viewer همان جایی است که سیستم‌عامل حرف می‌زند. نادیده گرفتنش یعنی نصف شواهد را دور انداختن.

این مقاله لاگ‌های مهم برای توسعه‌دهنده، فیلتر کردن نویز، کار با Get-WinEvent، و پیوند به سرویس و فرایند را پوشش می‌دهد. معادل ذهنی لینوکسی‌اش نزدیک journalctl است، با قراردادها و ابزار ویندوزی.

پاسخ کوتاه

Event Viewer واسط خواندن Windows Event Log است. برای کار روزمرهٔ توسعه معمولاً Application و System کافی‌اند؛ Security بیشتر برای حسابرسی است. با فیلتر سطح Error و Critical و بازهٔ زمانی شروع کنید، Event ID و Source را یادداشت کنید، و برای اسکریپت از Get-WinEvent استفاده کنید.

اول زمان و سطح را تنگ کنید؛ بعد در متن غرق شوید.

لاگ‌های اصلی که باید بشناسید

اپ شما اگر درست نوشته شده باشد می‌تواند به Application بنویسد. اگر هیچی نمی‌نویسد، مشکل را فقط در لاگ خود اپ دنبال کنید؛ Event Viewer معجزه نمی‌کند.

UI: فیلتر سریع

Event Viewer را باز کنید، لاگ را انتخاب کنید، Filter Current Log را بزنید. سطح Error و Critical، و زمان «Last 12 hours» نقطهٔ شروع خوب است. روی رویداد دوبار کلیک کنید تا جزئیات و XML را ببینید. Copy کردن Event ID برای جستجو حیاتی است.

Custom View برای فیلترهای تکراری تیم مفید است؛ همان را می‌توانید ذخیره و به اشتراک بگذارید.

Get-WinEvent؛ مسیر اسکریپت‌پذیر

powershell

Get-WinEvent -LogName Application -MaxEvents 5 Get-WinEvent -FilterHashtable @{LogName='System'; Level=2; StartTime=(Get-Date).AddHours(-6)} -MaxEvents 20

Level=2 معمولاً Error است؛ مقادیر دقیق را در مستند و مثال‌های Help ببینید. FilterHashtable برای بازهٔ زمانی و سطح خیلی خواناتر از XPath خام است، هرچند XPath قدرت بیشتری دارد.

powershell

Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='Application Error'; StartTime=(Get-Date).AddDays(-1)} -MaxEvents 10 | Select-Object TimeCreated,Id,LevelDisplayName,Message

مستند Get-WinEvent در Microsoft Learn پارامترها و تفاوت با Get-EventLog قدیمی را توضیح می‌دهد؛ در نسخه‌های جدید روی Get-WinEvent سرمایه‌گذاری کنید.

پیوند با سرویس و نصب

وقتی سرویس Start نمی‌شود، زمان رویداد را با زمان فرمان خودتان هم‌تراز کنید. Source مربوط به همان سرویس یا Service Control Manager را پیدا کنید. اگر نصب‌کننده fail شد، هم Application و هم گاهی MSI یا منبع نصب‌کننده را ببینید.

برای کرش اپ، «Application Error» یا «Windows Error Reporting» سرنخ می‌دهد؛ فایل dump جداگانه است ولی Event نقطهٔ شروع زمان‌بندی است.

نویز، عملکرد و مجوز

بعضی لاگ‌ها حجیم‌اند. کشیدن کل تاریخچه بدون فیلتر ترمینال را قفل می‌کند. MaxEvents و StartTime را عادت کنید. روی لاگ Security ممکن است مجوز لازم باشد؛ نبود نتیجه همیشه یعنی نبود رویداد نیست.

در محیط دامنه، سیاست‌ها تعیین می‌کنند چه چیزی audit شود. فقدان رویداد Security لزوماً یعنی «اتفاقی نیفتاده» نیست.

چطور یک رویداد را «بفهمیم»؟

1. زمان را با اقدام خودتان قفل کنید.
2. Level و Source و Event ID را جدا کنید.
3. Message را بخوانید ولی به ID بیشتر اعتماد کنید.
4. همان ID را در مستند فروشنده یا Learn جستجو کنید.
5. اگر الگو تکرار می‌شود، Custom View یا اسکریپت Get-WinEvent بسازید.

ترجمهٔ ماشینی متن پیام گاهی گمراه‌کننده است؛ فیلدهای ساخت‌یافته و ID پایدارترند.

مقایسهٔ کوتاه با journalctl

روی لینوکس journalctl -u و فیلتر اولویت دارید. روی ویندوز LogName و Provider و FilterHashtable همان نقش را بازی می‌کنند. مفهوم یکی است: لاگ ساخت‌یافته سیستم‌عامل. ابزار و نام‌ها فرق دارد؛ مدل ذهنی را منتقل کنید نه نحو را.

اشتباه‌های رایج

• اسکرول بی‌فیلتر در صدها Information.
• نادیده گرفتن اختلاف ساعت و منطقهٔ زمانی هنگام تطبیق با لاگ اپ.
• فرض اینکه نبود رویداد یعنی سلامت کامل.
• پاک کردن لاگ برای «تمیز کردن» قبل از برداشتن شاهد.
• جستجوی فقط متن فارسی پیام به‌جای Event ID.

سوالات متداول

آیا باید هر روز Event Viewer را چک کنم؟

نه. وقتی علامت دارید یا بعد از تغییر سیستمی مهم. برای سلامت مداوم، مانیتورینگ متمرکز بهتر از نگاه دستی روزانه است.

Get-EventLog هنوز؟

در مسیرهای قدیمی هست؛ برای کار جدید Get-WinEvent را ترجیح دهید مگر محدودیت محیط.

می‌توان لاگ را export کرد؟

بله، از UI یا با فرمان‌ها برای ارسال به پشتیبانی. قبل از پاک‌سازی، export را عادت کنید.

تمرین سی‌دقیقه‌ای

یک خطای ساختگی کوچک بسازید یا سرویس بی‌خطر را Restart کنید، سپس با فیلتر زمانی همان بازه رویداد مرتبط را پیدا کنید. همان کار را با Get-WinEvent تکرار کنید و خروجی را به CSV بدهید. وقتی هر دو مسیر را لمس کنید، در تیکت واقعی سریع‌ترید.

اگر تیم دارید، یک Custom View مشترک برای Errorهای Application و System آخرین ۲۴ ساعت تعریف کنید و لینکش را در runbook بگذارید.

قبل از بستن تیکت: نشست جدید را تست کنید، سرویس یا لاگ را دوباره تأیید کنید، و علت ریشه‌ای را یک خط بنویسید تا تکرار نشود.

سیاست دامنه، آنتی‌ویروس مرکزی و بعضی سرویس‌های سیستمی خارج از اختیار شماست. لایهٔ قابل‌کنترل را درست کنید و برای بقیه تیکت شفاف با شاهد بسازید.

مرز مسئولیت توسعه‌دهنده و IT

اگر Force لازم شد، بعداً علت شکست توقف ملایم را پیدا کنید. Force بدون یادگیری همان حادثه را تکرار می‌کند.

در هر مرحله شاهد بنویسید: وضعیت سرویس، Event ID، یا خروجی پورت. شاهد بهتر از توصیف احساسی است؛ مخصوصاً در تیم دورکار.

فرض کنید بعد از ریبوت API محلی بالا نمی‌آید. اول Get-Service برای وابسته‌ها، بعد پورت، بعد Event Log روی زمان بوت، بعد env نشست. این ترتیب از پراکنده‌کاری جلوگیری می‌کند.

سناریوی ترکیبی پایان‌تا‌پایان

نسخه‌بندی اسکریپت‌های Get-Service و Get-WinEvent تیم را از دانش شفاهی بی‌نیاز می‌کند.

مستند رسمی را نخواندن، Elevated دائمی، و تغییر انبوه سرویس‌ها طبق چک‌لیست اینترنتی سه الگوی پرهزینه‌اند. هزینه معمولاً وقتی معلوم می‌شود که محیط همکار یا بیلد می‌شکند.

اشتباه‌های سطح بالاتر

در پایان، Startup Type را اگر تغییر دادید برگردانید و یادداشت یک‌خطی علت و فرمان را ذخیره کنید. پاک‌سازی بخشی از حرفه‌ای‌گری است.

وضعیت چند سرویس مرتبط با استک خود را بخوانید، یکی را در زمان امن Restart کنید، سپس بلافاصله Event Viewer را روی همان بازه فیلتر کنید. PID و پورت را هم اگر سرویس گوش می‌دهد تطبیق دهید.

تمرین پیشنهادی سی‌دقیقه‌ای

اگر از لینوکس آمده‌اید، سرویس ویندوز را با unitهای systemd و Event Viewer را با journalctl متناظر کنید، ولی نحو و هویت اجرا را عیناً ترجمه نکنید.

سرویس را با فرایند، پورت، env و Event Log به‌صورت حلقه ببینید. تیکت واقعی معمولاً بیش از یک حلقه را درگیر می‌کند. اگر فقط services.msc را بلد باشید ولی نتوانید رویداد شکست را بخوانید، نصف راه را آمده‌اید.

ارتباط با بقیهٔ سری ویندوز

تفاوت محیط خانگی و لپ‌تاپ سازمانی را دست‌کم نگیرید. آنتی‌ویروس، پروکسی و سیاست دامنه رفتار سرویس و لاگ را عوض می‌کنند.

هر راه‌حل موقتی را به یک فرمان قابل‌کپی در یادداشت تیم تبدیل کنید. هفتهٔ بعد همان را از حافظه نمی‌نویسید؛ از runbook می‌آورید.

در کار واقعی، مشکل‌ها ترکیبی‌اند: سرویس متوقف، پورت اشغال، PATH کهنه و رویداد Error هم‌زمان ظاهر می‌شوند. یک فرض را آزمایش کنید، شاهد بگیرید، بعد به فرض بعدی بروید. تغییر همزمان همه چیز تشخیص علت ریشه‌ای را غیرممکن می‌کند.

عمق عملی بیشتر برای کار روزانه

به یاد داشته باشید Security log برای بیشتر عیب‌یابی اپ روزمره نقطهٔ اول نیست؛ اول Application و System را تمام کنید مگر نشانهٔ صریح دسترسی و سیاست داشته باشید.

Get-WinEvent را با یک FilterHashtable آماده در فایل ps1 شخصی ذخیره کنید تا در فشار تیکت نحو را از نو به خاطر نیاورید. همین فایل کوچک گاهی ۱۵ دقیقه را به ۹۰ ثانیه تبدیل می‌کند.

اگر فقط یک عادت از این دو مقاله ببرید، این است: قبل از ریبوت، شاهد ساخت‌یافته بگیرید. ریبوت شاهد را پاک می‌کند و یادگیری را می‌کشد.

با رسیدن به سرویس و Event Log، بلوک ویندوز سری ۳ از انگیزه و ترمینال تا مشاهده‌پذیری سیستم کامل می‌شود. مرحلهٔ بعد در سری می‌تواند زمان‌بند، فایل‌ها با PowerShell، و WSL باشد تا محیط توسعه کامل‌تر شود.

جمع‌بندی مهارتی این بلوک

وقتی خطای تکراری با Event ID ثابت می‌بینید، به‌جای پاک کردن لاگ، برایش فیلتر ذخیره بسازید و بپرسید آیا به‌روزرسانی یا پیکربندی غلط علت است.

نام سرویس‌های استک خود را با Name و DisplayName در README بنویسید. تفاوت این دو منبع اشتباه فرمان است.

یک کانال یا سند مشترک برای فرمان‌های استاندارد Get-Service و Get-WinEvent تیم بسازید. عضو جدید نباید هر بار از صفر جستجو کند. استاندارد کوچک، زمان onboarding را کم می‌کند.

الگوی کار تیمی روی ویندوز

برای Event Viewer، یک export کوتاه از رویدادهای کلیدی بهتر از اسکرین‌شات تار است. فایل export را به تیکت بچسبانید تا پشتیبانی بیرونی هم بتواند همان ID را ببیند.

اگر تغییر شما روی Startup Type یا حساب سرویس بود، همان را در سند تغییر ثبت کنید. فردا خودتان هم فراموش می‌کنید چرا Manual شده است.

آیا سرویس بعد از ریبوت هم در وضعیت مطلوب است یا فقط تا قبل از ریبوت درست بود؟ آیا کاربر بدون ارتفاع می‌تواند کار روزمره‌اش را انجام دهد؟ آیا Event Log در بازهٔ تست خطای تازه ندارد؟ این سه سؤال جلوی بسته‌شدن زودهنگام تیکت را می‌گیرند.

چک‌لیست عملی قبل از اعلام رفع مشکل

در پایان، یک‌بار مسیر کامل را روی ماشین خودتان بدون عجله طی کنید: فیلتر UI، کپی Event ID، جستجوی همان ID، و معادل Get-WinEvent با خروجی Select-Object. این تکرار کوتاه همان چیزی است که در روز حادثه دستتان را می‌لرزاند یا محکم می‌کند و تفاوت تازه‌کار و حرفه‌ای را در عیب‌یابی ویندوز رقم می‌زند.

این عادت کوچک را همین امروز قفل کنید.

خلاصه

Event Viewer و Get-WinEvent چشم شما به لایهٔ سیستم‌عامل‌اند. با فیلتر سطح و زمان شروع کنید، Event ID را جدی بگیرید، و رویداد را به سرویس و نصب و کرش وصل کنید. بدون شاهد لاگ، عیب‌یابی ویندوز نصفه است.

منابع و مراجع

• Microsoft Learn — Get-WinEvent — https://learn.microsoft.com/powershell/module/microsoft.powershell.diagnostics/get-winevent
• Microsoft Learn — about_EventLogs — https://learn.microsoft.com/powershell/module/microsoft.powershell.core/about/about_eventlogs
• Microsoft Learn — Windows Event Log overview — https://learn.microsoft.com/windows/win32/eventlog/event-logging
• Microsoft Support — Use Event Viewer — https://support.microsoft.com/windows