سرویس‌های ویندوز چیست و چطور مدیریت‌شان کنیم؟

وقتی SQL Server محلی بعد از ریبوت نیست، یا IIS پاسخ نمی‌دهد، یا ابزار بکاپ فقط با حساب SYSTEM کار می‌کند، با Windows Service طرفید نه فقط یک exe که دوبار کلیک شده باشد. سرویس توسط Service Control Manager چرخهٔ عمر دارد: شروع، توقف، بازیابی، وابستگی و نوع راه‌اندازی.

این مقاله مدل سرویس را از فرایند معمولی جدا می‌کند، ابزار UI و PowerShell را نشان می‌دهد، و مرزهای امن برای توسعه‌دهنده را می‌کشد. Event Viewer برای شکست‌های شروع سرویس در ۱۹۰ تکمیل می‌شود.

پاسخ کوتاه

Windows Service برنامه‌ای است که معمولاً در پس‌زمینه، اغلب بدون ورود تعاملی کاربر، و تحت کنترل Service Control Manager اجرا می‌شود. با Get-Service وضعیت را می‌بینید، با Start-Service و Stop-Service و Restart-Service چرخهٔ عمر را عوض می‌کنید، و با Startup Type مشخص می‌کنید بعد از بوت چه شود. کشتن خام فرایند سرویس ممکن است توسط سیاست بازیابی خنثی شود یا وابسته‌ها را بشکند.

سرویس را مثل systemd unit ببینید نه مثل notepad؛ ابزار مدیریتش جداست.

سرویس چه مشکلی را حل می‌کند؟

اپ دسکتاپ با لاگین کاربر زنده است. سرویس برای کارهایی است که باید مستقل از جلسهٔ کاربر باشند: پایگاه‌داده، وب‌سرور، عامل مانیتورینگ، صف پیام. هویت اجرا می‌تواند حساب ویژه باشد تا مجوز فایل و شبکه جدا از کاربر روزمره تعریف شود.

برای توسعه‌دهنده، سرویس محلی یعنی وابستگی زیرساختی قابل‌تکرار بعد از ریبوت. بدون فهم Startup Type، هر صبح با «چرا دیتابیس نیست؟» شروع می‌کنید.

مشاهده با UI و PowerShell

services.msc دید کلاسیک است: نام، وضعیت، Startup Type. برای اسکریپت و تکرار:

powershell

Get-Service | Sort-Object Status,Name | Select-Object -First 15 Get-Service -Name w3svc -ErrorAction SilentlyContinue Get-Service | Where-Object Status -eq 'Stopped' | Select-Object -First 10 Name,StartType

نام سرویس (Name) با DisplayName فرق دارد. در فرمان‌ها معمولاً Name مهم است. مستند Get-Service در Microsoft Learn پارامترها و محدودیت مجوز را شرح می‌دهد.

Start، Stop، Restart

powershell

Start-Service -Name 'MyService' Stop-Service -Name 'MyService' Restart-Service -Name 'MyService' -Force

اگر وابسته‌ها مانع توقف شوند، گاهی Force لازم است؛ ولی بفهمید چه چیزی قطع می‌شود. برای سرویس‌های ناشناس ابتدا فقط Get-Service و مستند را بخوانید نه Restart کور.

معادل کلاسیک sc.exe و net start/stop هنوز در اسکریپت‌های قدیمی دیده می‌شوند. در کار جدید PowerShell خواناتر است، ولی runbook سازمانی را بی‌دلیل نشکنید.

cmd

sc.exe query type= service state= all | more

Startup Type

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

powershell

# مشاهده StartType در نسخه‌های جدیدتر شیء سرویس: Get-Service -Name spoooler | Format-List *

وابستگی‌ها و ترتیب شروع

یک سرویس ممکن است به شبکه، به یک دیتابیس، یا به سرویس دیگری وابسته باشد. اگر وابسته زودتر fail کند، سرویس شما هم بالا نمی‌آید و پیام مبهم می‌دهد. در UI تب Dependencies و در ابزارهای پیشرفته‌تر روابط را ببینید. عیب‌یابی را از ریشهٔ زنجیره شروع کنید نه از آخرین نام در خطا.

در توسعه، اگر اپ شما سرویس است و به SQL نیاز دارد، وابستگی را صریح کنید یا در مستند شروع دستی ترتیب را بنویسید. Race در بوت یکی از منابع flaky test محلی است.

هویت اجرا و مجوز

سرویس با چه حسابی اجرا می‌شود؟ Local System قدرت بالاست و خطرناک. حساب مجازی یا اختصاصی با حداقل مجوز الگوی بهتر است. اگر سرویس به مسیر شبکه یا گواهی دسترسی ندارد، اول هویت را چک کنید نه کد اپ را.

تغییر پسورد حساب سرویس بدون به‌روز کردن تنظیم سرویس، بعد از ریبوت شکست می‌سازد. در محیط دامنه با IT هماهنگ کنید.

سرویس در برابر فرایند و نصب توسعه

خیلی از استک‌های توسعه مدرن سرویس ویندوزی نیستند: docker compose، فرایند Node، یا IIS Express. وقتی چیزی بعد از بوت لازم است، یا آن را سرویس کنید یا از Task Scheduler استفاده کنید. مقالهٔ ۱۹۱ زمان‌بند را پوشش می‌دهد.

اگر فقط برای دیباگ کار می‌کنید، اجرای console گاهی بهتر از نصب سرویس است چون لاگ و attach ساده‌تر است. سرویس را برای شکل نزدیک به تولید نگه دارید.

عیب‌یابی وقتی سرویس Start نمی‌شود

1. وضعیت و StartType را با Get-Service بخوانید.
2. Event Viewer یا Get-WinEvent را روی زمان تلاش فیلتر کنید.
3. مسیر باینری و مجوز پوشه را بررسی کنید.
4. وابستگی‌ها را یکی‌یکی تأیید کنید.
5. اگر تازه نصب شده، نصب‌کننده را دوباره در حالت verbose ببینید.

پیام «started and then stopped» کلاسیک است: فرایند خارج شده. علت در لاگ اپ یا Event است نه در Restart مکرر.

sc.exe و ابزارهای کلاسیک

sc query، sc config و sc qc برای دیدن و تنظیم پیکربندی هنوز مفیدند؛ مخصوصاً در محیط‌هایی که PowerShell محدود شده. خروجی qc مسیر باینری و حساب شروع را نشان می‌دهد. مراقب فاصله بعد از = در نحو sc باشید؛ حساس است.

cmd

sc.exe qc spooler

امنیت و سطح حمله

سرویس‌های گوش‌دهنده روی شبکه سطح حمله هستند. سرویس تستی با حساب قوی روی لپ‌تاپ سازمانی بدون نیاز واقعی روشن نگذارید. اگر سرویسی لازم ندارید و مال استک شماست، Manual یا Disabled آگاهانه بهتر از Automatic فراموش‌شده است.

به‌روزرسانی سرویس‌های شخص‌ثالث را بخشی از نگهداری بدانید. باینری قدیمی با Automatic یعنی آسیب‌پذیری همیشه روشن.

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

• Restart کور سرویس ناشناس برای «درست شدن ویندوز».
• Stop-Process به‌جای Stop-Service و تعجب از بازگشت فرایند.
• Disabled کردن انبوه سرویس‌ها طبق چک‌لیست اینترنتی بدون فهم.
• فرض اینکه سرویس همان env کاربر تعاملی را دارد.
• نادیده گرفتن Event Log هنگام شکست Start.

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

هر exe را می‌توان سرویس کرد؟

نه. برنامه باید با مدل سرویس سازگار باشد یا با wrapper مناسب بسته‌بندی شود. خیلی از CLIهای تعاملی سرویس خوبی نمی‌شوند.

فرق سرویس و Task Scheduler چیست؟

سرویس برای فرایند بلندمدت و حالت همیشه آماده است. Task برای اجرای زمان‌بندی‌شده یا رویدادی است. گاهی هر دو با هم استفاده می‌شوند.

آیا Docker جایگزین سرویس محلی است؟

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

تمرین عملی پیشنهادی

یک سرویس شناخته‌شده و کم‌خطر محیط خودتان را فقط بخوانید نه تغییر مخرب: وضعیت، StartType، و رویدادهای اخیر مرتبط. سپس برای سرویس متعلق به استک خودتان Restart کنترل‌شده را در زمان امن امتحان کنید و نتیجه را در Event Log ببینید.

اگر سرویس متعلق به شماست، مستند کوتاه Start/Stop و وابستگی را در README تیم بگذارید تا همکار بدون حدس عمل کند.

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

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

مرز مسئولیت توسعه‌دهنده و 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 هم‌زمان ظاهر می‌شوند. یک فرض را آزمایش کنید، شاهد بگیرید، بعد به فرض بعدی بروید. تغییر همزمان همه چیز تشخیص علت ریشه‌ای را غیرممکن می‌کند.

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

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

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

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

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

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

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

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

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

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

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

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

خلاصه

سرویس ویندوز واحد مدیریت پس‌زمینه‌ای با هویت، Startup Type و وابستگی است. با Get-Service مشاهده کنید، با Start/Stop/Restart چرخه را عوض کنید، و شکست‌ها را در Event Log بخوانید. Force و Disabled را برای موارد فهمیده‌شده نگه دارید. قدم بعد: Event Viewer.

منابع و مراجع

• Microsoft Learn — Get-Service — https://learn.microsoft.com/powershell/module/microsoft.powershell.management/get-service
• Microsoft Learn — Start-Service — https://learn.microsoft.com/powershell/module/microsoft.powershell.management/start-service
• Microsoft Learn — Stop-Service — https://learn.microsoft.com/powershell/module/microsoft.powershell.management/stop-service
• Microsoft Learn — Restart-Service — https://learn.microsoft.com/powershell/module/microsoft.powershell.management/restart-service
• Microsoft Learn — Service Control Manager concepts — https://learn.microsoft.com/windows/win32/services/service-control-manager