محتوای آموزشی وبلاگ نت‌آرام
روی Start یک سرویس ویندوز کلیک می‌کنید و پیام
Error 1067: The process terminated unexpectedly ظاهر می‌شود. این پیام می‌گوید فرایند سرویس به شکل غیرمنتظره پایان یافته است، اما علت دقیق را مشخص نمی‌کند. ممکن است فایل تنظیم برنامه اشتباه باشد، مسیر گزارش وجود نداشته باشد، حساب سرویس دسترسی کافی نداشته باشد یا پورت مورد نیاز قبلاً گرفته شده باشد.از نصب دوباره برنامه یا پاک‌کردن پوشه داده شروع نکنید. ابتدا نام سرویس و خطای اصلی آن را پیدا می‌کنیم و فقط راهکار مربوط به همان علت را اجرا می‌کنیم. مثال‌ها برای Windows Server روی سرور مجازی ایران و سرور اختصاصی ایران هستند. نام
MyService و مسیرها نمونه‌اند. روی سرور عملیاتی، پیش از هر تغییر نسخه پشتیبان تنظیمات و زمان مناسب قطع احتمالی را در نظر بگیرید.۱. نام واقعی سرویس و زمان خطا را پیدا کنید
با Remote Desktop وارد سرور شوید،
services.msc را از Start باز کنید و سرویس مشکل‌دار را پیدا کنید. در Properties، مقدار Service name را یادداشت کنید؛ این نام ممکن است با عنوان نمایشی سرویس فرق داشته باشد. زمان تلاش ناموفق را هم ثبت کنید.PowerShell را با دسترسی مدیر باز کنید و به‌جای
کد / دستورMyService نام واقعی را بگذارید:Get-Service -Name 'MyService' | Format-List Name,DisplayName,Status,StartType
sc.exe queryex MyService
sc.exe qc MyService
queryex وضعیت و در صورت وجود شناسه پردازش را نشان می‌دهد. qc مسیر اجرای ثبت‌شده، وابستگی‌ها و حساب شروع سرویس را نمایش می‌دهد. در PowerShell حتماً sc.exe را با پسوند بنویسید تا با نام مستعار دیگری اشتباه نشود. آرگومان‌های مسیر اجرا ممکن است اطلاعات حساس داشته باشند؛ خروجی کامل را عمومی منتشر نکنید. اگر پیام می‌گوید سرویس پیدا نشد، نام Service name را دوباره بررسی کنید.۲. خطای برنامه را کنار خطای Service Control Manager ببینید
در Event Viewer ← Windows Logs ابتدا بخش System و سپس Application را در بازه زمانی خطا بخوانید. پیام Service Control Manager اغلب فقط توقف را گزارش می‌کند؛ رویداد برنامه در همان چند ثانیه ممکن است فایل یا علت دقیق را نشان دهد. برای دیدن رویدادهای اخیر هر دو بخش در PowerShell:
کد / دستورGet-WinEvent -FilterHashtable @{LogName='System'; StartTime=(Get-Date).AddHours(-1)} -MaxEvents 50 |
Select-Object TimeCreated,ProviderName,Id,Message
کد / دستورGet-WinEvent -FilterHashtable @{LogName='Application'; StartTime=(Get-Date).AddHours(-1)} -MaxEvents 50 |
Select-Object TimeCreated,ProviderName,Id,Message
نام برنامه، ساعت و متن خطا را تطبیق دهید؛ این دستورها رویدادهای برنامه‌های دیگر را هم نشان می‌دهند. اگر گزارش خیلی شلوغ است از فیلتر نام منبع در Event Viewer استفاده کنید. سپس شاخه مناسب را دنبال کنید:
file not found به مسیر، access denied به هویت و مجوز، و address already in use به تداخل پورت راهنمایی می‌کند. این عبارت‌ها مثال‌اند و معنی دقیق خطای برنامه در مستندات سازنده مشخص می‌شود.۳. اگر مسیر فایل تنظیم یا گزارش اشتباه است
مسیر ثبت‌شده در
کد / دستورsc.exe qc و فایل تنظیم برنامه را با محل واقعی نصب مقایسه کنید. مثلاً برای یک فایل نمونه:Test-Path -LiteralPath 'C:\ProgramData\MyApp\config.json'
Test-Path -LiteralPath 'C:\ProgramData\MyApp\Logs' -PathType Container
True فقط وجود مسیر را در نشست فعلی تأیید می‌کند، نه دسترسی حساب سرویس را. اگر فایل پس از جابه‌جایی برنامه در محل دیگری است، مسیر صحیح را با نسخه پشتیبان تنظیمات و مستندات خود برنامه تطبیق دهید. فایل نمونه یا پوشه خالی را به‌جای داده گمشده نسازید.یک نمونه مشخص در SQL Server، رویداد
17058 همراه با پیام ناتوانی در بازکردن ERRORLOG است. در SQL Server Configuration Manager، Properties همان نمونه SQL Server را باز کنید و در Startup Parameters مسیر پارامتر -e را بخوانید. طبق راهنمای مایکروسافت، مسیر باید پوشه معتبری باشد که حساب سرویس اجازه ساخت و نوشتن گزارش در آن را دارد. اگر اشتباه تایپی دارد، مسیر درست و مجوز را تأیید و همان پارامتر را اصلاح کنید. مسیرهای -d و -l به فایل‌های پایگاه داده مربوط‌اند؛ آن‌ها را برای رفع این خطا دست‌کاری یا حذف نکنید.۴. اگر فایل هست اما دسترسی رد شده است
حساب اجرای سرویس را در Properties سرویس، زبانه Log On یا خروجی
کد / دستورsc.exe qc ببینید. برای خواندن مجوزهای مسیر گزارش نمونه:icacls 'C:\ProgramData\MyApp\Logs'
نام حساب و گروه‌ها، مجوزهای ارث‌رسیده و سیاست سازمان را با نقش برنامه مقایسه کنید. اگر رویداد دقیقاً به نوشتن لاگ اشاره می‌کند، حساب سرویس باید در پوشه درست مجوز لازم همان عملیات را داشته باشد. از Properties پوشه، تب Security و Advanced می‌توانید دسترسی همان حساب را طبق سیاست سازمان اصلاح کنید. ابتدا تنظیم قبلی را ثبت کنید؛ به همه کاربران Full Control ندهید و روی کل دیسک تغییر بازگشتی اعمال نکنید.
اگر خطا در واقع
1069 است، ویندوز از مشکل ورود حساب سرویس خبر می‌دهد و باید رمز یا سیاست حساب را جداگانه بررسی کنید. در حساب دامنه، قفل حساب نیز ممکن است دخیل باشد؛ راهنمای رفع قفل حساب ویندوز سرور برای پیدا کردن منبع تلاش ناموفق کمک می‌کند. تغییر سرویس به LocalSystem صرفاً برای دورزدن خطا می‌تواند سطح دسترسی و رفتار شبکه آن را عوض کند.۵. اگر برنامه از پورت استفاده می‌کند
اگر گزارش خود برنامه به پورت اشغال‌شده اشاره دارد، شماره واقعی آن را از تنظیمات بخوانید. برای نمونه پورت ۸۰۸۰:
کد / دستورGet-NetTCPConnection -LocalPort 8080 -State Listen |
Select-Object LocalAddress,LocalPort,OwningProcess
اگر نتیجه‌ای نبود، ممکن است در آن لحظه شنونده‌ای وجود نداشته باشد؛ دسترسی، پروتکل UDP و نسخه ویندوز را نیز در نظر بگیرید. اگر عدد
کد / دستورOwningProcess مثلاً ۴۲۴۲ بود، برای همان عدد واقعی اجرا کنید:Get-Process -Id 4242
Get-CimInstance Win32_Service | Where-Object ProcessId -eq 4242 |
Select-Object Name,DisplayName,State
شناسه پردازش می‌تواند تغییر کند. اول بفهمید سرویس موجود چه کاری انجام می‌دهد. اگر دو برنامه واقعاً به پورت و نشانی یکسان نیاز دارند، طبق تنظیم برنامه یکی را به پورت آزاد سازگار منتقل کنید و پراکسی یا کلاینت وابسته را نیز هماهنگ کنید. سرویس ناشناس را فقط برای آزادکردن پورت متوقف نکنید.
۶. نمونه عملی برای Apache روی ویندوز
اگر سرویس شما Apache HTTP Server است، نسخه و مسیر اجرایی آن را از نصب خود پیدا کنید. این نمونه فقط برای نصب در
کد / دستورC:\Apache24 و سرویس Apache2.4 است:& 'C:\Apache24\bin\httpd.exe' -n 'Apache2.4' -t
این دستور طبق راهنمای Apache پیکربندی همان سرویس را آزمون می‌کند. پیام
Syntax OK بررسی نحوی موفق را نشان می‌دهد؛ اگر خطا داد، نام فایل و شماره خط را بخوانید، از فایل نسخه پشتیبان بگیرید و همان اشتباه را اصلاح کنید. دستور آزمون، کارکرد نهایی سایت یا آزادبودن پورت را تضمین نمی‌کند. برای نرم‌افزارهای دیگر از ابزار اعتبارسنجی مخصوص خودشان استفاده کنید؛ اجرای فایل سرویس به‌صورت مستقیم همیشه روش مناسبی نیست.۷. پس از اصلاح، یک بار کنترل‌شده شروع کنید
وقتی علت مشخص و برطرف شد، با نام واقعی سرویس و در زمان مناسب یک بار آن را اجرا کنید:
کد / دستورStart-Service -Name 'MyService'
Get-Service -Name 'MyService'
اگر دوباره متوقف شد، زمان تازه را در Event Viewer و گزارش خود برنامه بخوانید؛ ممکن است پس از رفع مشکل اول، خطای دیگری آشکار شده باشد. اگر سرویس TCP دارد، پورت صحیح را از خود سرور آزمایش کنید:
کد / دستورTest-NetConnection -ComputerName '127.0.0.1' -Port 8080
عدد پورت را مطابق برنامه تغییر دهید.
TcpTestSucceeded: True فقط اتصال به پورت را تأیید می‌کند. در نهایت درخواست یا عملیات واقعی و بی‌خطر برنامه را انجام دهید و وابستگی‌هایش را ببینید. وضعیت Running به‌تنهایی اثبات نمی‌کند سایت، پایگاه داده یا خروجی برنامه سالم است.اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام