سطح: متوسط | مناسب برای: مدیران ویندوز سرور، کاربران VPS ویندوز، مدیران هاست ویندوز، توسعهدهندگان سرویسهای Windows و افرادی که هنگام Start کردن یک سرویس با Error 1053 مواجه شدهاند
خطای Error 1053: The Service did not respond to the start or control request in a timely fashion یکی از خطاهای رایج در ویندوز سرور است. این خطا معمولاً زمانی دیده میشود که میخواهید یک سرویس Windows را از بخش Services یا با دستور خط فرمان Start کنید، اما سرویس در زمان مورد انتظار به Service Control Manager پاسخ نمیدهد.
در ظاهر، خطای 1053 فقط میگوید سرویس در زمان مناسب پاسخ نداده است؛ اما علت واقعی میتواند متفاوت باشد: کند بودن شروع سرویس، مشکل در فایلهای DLL یا dependencyها، نبود دسترسی کافی، خراب بودن فایلهای سیستمی، مشکل در .NET Runtime، تنظیم نبودن مسیر اجرایی سرویس، timeout کوتاه Service Control Manager یا حتی خطا در کد سرویسهای اختصاصی.
در این آموزش، مرحلهبهمرحله بررسی میکنیم خطای 1053 در ویندوز سرور یعنی چه، چطور علت اصلی آن را از Event Viewer و لاگها پیدا کنیم، چه سرویسها و وابستگیهایی را بررسی کنیم، چطور فایلهای سیستمی ویندوز را تعمیر کنیم، چه زمانی باید مقدار ServicesPipeTimeout را تغییر دهیم و چه نکاتی را برای جلوگیری از تکرار این خطا رعایت کنیم.
اگر این خطا را روی سرور مجازی ویندوز تجربه میکنید، پیشنهاد میکنیم مقاله سرور مجازی چیست؟ را هم بخوانید. همچنین اگر برای اجرای سرویسهای ویندوزی، IIS یا پروژههای ASP.NET به زیرساخت پایدار نیاز دارید، صفحه سرور مجازی و اختصاصی پویاسازان و صفحه سرور مجازی آلمان میتوانند برای انتخاب سرویس مناسب مفید باشند.
فهرست مطالب
- خطای 1053 در ویندوز سرور چیست؟
- چرا خطای Error 1053 رخ میدهد؟
- قبل از شروع عیبیابی چه کار کنیم؟
- مرحله ۱: بررسی Event Viewer و Service Control Manager
- مرحله ۲: ریستارت سرویس یا سرور
- مرحله ۳: بررسی سرویسهای وابسته یا Dependencies
- مرحله ۴: بررسی دسترسی کاربر سرویس
- مرحله ۵: بررسی مسیر فایل اجرایی و فایلهای موردنیاز سرویس
- مرحله ۶: بررسی .NET Framework یا Runtimeهای موردنیاز
- مرحله ۷: تعمیر فایلهای سیستمی با SFC و DISM
- مرحله ۸: افزایش زمان Timeout سرویس با ServicesPipeTimeout
- مرحله ۹: بررسی آپدیتهای ویندوز سرور
- اگر سرویس اختصاصی یا برنامهنویسیشده دارید
- سناریوهای رایج خطای 1053
- چکلیست سریع رفع خطای 1053
- سوالات متداول
خطای 1053 در ویندوز سرور چیست؟
خطای 1053 معمولاً با این پیام نمایش داده میشود:
Error 1053: The service did not respond to the start or control request in a timely fashion.این پیام یعنی Windows Service موردنظر هنگام Start شدن یا دریافت یک درخواست کنترلی، در بازه زمانی مورد انتظار پاسخ مناسب به Service Control Manager نداده است. نتیجه این است که ویندوز فرض میکند سرویس بهدرستی Start نشده و عملیات را با خطا متوقف میکند.
این خطا میتواند برای سرویسهای مختلف رخ دهد؛ از سرویسهای داخلی Windows گرفته تا سرویسهای مربوط به نرمافزارهای نصبشده، سرویسهای SQL Server، سرویسهای مانیتورینگ، سرویسهای بکاپ، سرویسهای ASP.NET/Windows Service یا نرمافزارهای اختصاصی شرکتها.
چرا خطای Error 1053 رخ میدهد؟
خطای 1053 فقط یک علت ندارد. این خطا بیشتر یک علامت است؛ یعنی سرویس نتوانسته در زمان مناسب پاسخ دهد. علت اصلی باید از لاگها، تنظیمات سرویس و وضعیت سیستم پیدا شود.
دلایل رایج خطای 1053:
- سرویس برای Start شدن به زمان بیشتری نیاز دارد.
- یکی از dependencyهای سرویس Start نشده است.
- کاربر سرویس دسترسی لازم به فایلها، رجیستری یا شبکه را ندارد.
- فایل اجرایی سرویس یا DLLهای لازم حذف، خراب یا جابهجا شدهاند.
- نسخه .NET Framework یا Runtime موردنیاز نصب نیست.
- فایلهای سیستمی ویندوز خراب شدهاند.
- Windows Update ناقص یا مشکلدار بوده است.
- سرویس اختصاصی در متد Start دچار خطای برنامهنویسی یا deadlock میشود.
- آنتیویروس یا نرمافزار امنیتی مانع اجرای سرویس میشود.
- منابع سرور مثل CPU، RAM یا Disk I/O تحت فشار شدید است.
اگر این مشکل روی سرور ویندوزی پرترافیک یا سرویس حساس رخ میدهد، بهتر است قبل از تغییرات گسترده، لاگها را ذخیره و از تنظیمات سرویس بکاپ بگیرید.
قبل از شروع عیبیابی چه کار کنیم؟
قبل از اینکه تنظیمات رجیستری یا فایلهای سیستمی را تغییر دهید، این کارهای ساده را انجام دهید:
- نام دقیق سرویس خطادار را یادداشت کنید.
- زمان رخداد خطا را ثبت کنید.
- بررسی کنید خطا بعد از نصب نرمافزار، آپدیت ویندوز یا تغییر تنظیمات شروع شده یا نه.
- اگر سرویس مربوط به نرمافزار خاصی است، نسخه و لاگهای همان نرمافزار را بررسی کنید.
- از رجیستری و تنظیمات مهم سرور بکاپ داشته باشید.
- اگر سرور production است، تغییرات را در زمان کمترافیک انجام دهید.
در سرورهای مهم، تغییراتی مثل ویرایش رجیستری یا reinstall کردن سرویس باید با برنامه بازگشت انجام شود. اگر سرویس مربوط به سایت یا اپلیکیشن تحت وب است، وضعیت IIS، Application Pool و لاگهای برنامه را هم بررسی کنید. مقاله آموزش ایجاد وبسایت به صورت دستی در IIS هم برای بررسی ساختار IIS مفید است.
مرحله ۱: بررسی Event Viewer و Service Control Manager
اولین و مهمترین مرحله، بررسی Event Viewer است. در بسیاری از موارد، Event Viewer اطلاعات دقیقتری نسبت به پنجره خطای Services نمایش میدهد.
برای بررسی لاگها:
- کلیدهای
Win + Rرا بزنید. - دستور زیر را وارد کنید:
eventvwr.msc- به مسیر زیر بروید:
Windows Logs > System- در سمت راست روی Filter Current Log کلیک کنید.
- در بخش Event sources، گزینه Service Control Manager را انتخاب کنید.
- رویدادهای نزدیک به زمان خطا را بررسی کنید.
Event IDهایی مثل 7000، 7009، 7011 یا 7034 میتوانند به خطاهای مربوط به Start شدن یا timeout سرویسها اشاره داشته باشند. متن کامل Event را بخوانید؛ معمولاً نام سرویس، نوع خطا و گاهی مسیر یا dependency مشکلدار مشخص میشود.
مرحله ۲: ریستارت سرویس یا سرور
اگر مشکل برای اولین بار رخ داده و سرویس قبلاً بدون مشکل کار میکرده، ابتدا سرویس را یکبار Restart کنید. از بخش Services:
services.mscسرویس موردنظر را پیدا کنید، روی آن راستکلیک کنید و گزینه Restart یا Start را انتخاب کنید.
از Command Prompt با دسترسی Administrator هم میتوانید استفاده کنید:
net stop "ServiceName"
net start "ServiceName"یا با PowerShell:
Restart-Service -Name "ServiceName"اگر چند سرویس وابسته یا منابع سیستم قفل شدهاند، گاهی ریستارت کامل سرور مشکل را موقتاً حل میکند. اما اگر خطا تکرار شود، باید علت اصلی را پیدا کنید.
مرحله ۳: بررسی سرویسهای وابسته یا Dependencies
بعضی سرویسها برای Start شدن به سرویسهای دیگر وابستهاند. اگر یکی از dependencyها اجرا نشده باشد، سرویس اصلی هم ممکن است با خطای 1053 یا خطاهای مشابه Start نشود.
برای بررسی Dependencies:
- وارد
services.mscشوید. - روی سرویس موردنظر دوبار کلیک کنید.
- به تب Dependencies بروید.
- سرویسهای وابسته را بررسی کنید.
- مطمئن شوید سرویسهای موردنیاز Start شدهاند.
اگر سرویس وابسته غیرفعال یا متوقف است، ابتدا آن را Start کنید و سپس سرویس اصلی را دوباره اجرا کنید.
مرحله ۴: بررسی دسترسی کاربر سرویس
هر سرویس ویندوزی با یک حساب کاربری اجرا میشود. این حساب میتواند Local System، Network Service، Local Service یا یک کاربر اختصاصی باشد. اگر کاربر سرویس دسترسی لازم نداشته باشد، سرویس ممکن است Start نشود یا در زمان شروع متوقف شود.
برای بررسی حساب سرویس:
- در
services.mscروی سرویس دوبار کلیک کنید. - به تب Log On بروید.
- حساب کاربری سرویس را بررسی کنید.
- اگر از کاربر اختصاصی استفاده میشود، رمز آن را تست و در صورت تغییر، بهروزرسانی کنید.
موارد مهم:
- کاربر سرویس باید به مسیر نصب برنامه دسترسی داشته باشد.
- اگر سرویس به شبکه یا دیتابیس متصل میشود، دسترسیهای لازم باید وجود داشته باشد.
- اگر رمز کاربر تغییر کرده باشد، سرویس دیگر نمیتواند با همان حساب اجرا شود.
- برای سرویسهای حساس، دسترسی بیش از حد ندهید؛ فقط حداقل دسترسی لازم را تنظیم کنید.
مرحله ۵: بررسی مسیر فایل اجرایی و فایلهای موردنیاز سرویس
اگر فایل اجرایی سرویس یا فایلهای وابسته مثل DLLها حذف، جابهجا یا خراب شده باشند، سرویس ممکن است با خطای 1053 Start نشود.
برای بررسی مسیر اجرایی سرویس:
- در
services.mscروی سرویس دوبار کلیک کنید. - در تب General مقدار Path to executable را ببینید.
- مطمئن شوید فایل در همان مسیر وجود دارد.
- اگر مسیر شامل فاصله است، مطمئن شوید در تنظیمات سرویس درست ثبت شده است.
با دستور زیر هم میتوانید اطلاعات سرویس را ببینید:
sc qc "ServiceName"در خروجی، مقدار BINARY_PATH_NAME را بررسی کنید.
اگر سرویس مربوط به نرمافزار خاصی است، نصب مجدد یا Repair همان نرمافزار ممکن است فایلهای خراب یا حذفشده را برگرداند.
مرحله ۶: بررسی .NET Framework یا Runtimeهای موردنیاز
بسیاری از سرویسهای ویندوزی با .NET Framework، .NET Core یا .NET جدید توسعه داده شدهاند. اگر Runtime موردنیاز نصب نباشد یا نسخه اشتباه نصب شده باشد، سرویس ممکن است Start نشود.
مواردی که باید بررسی کنید:
- سرویس با چه نسخهای از .NET ساخته شده است؟
- آیا .NET Framework لازم روی سرور نصب است؟
- اگر سرویس ASP.NET Core یا Worker Service است، آیا Hosting Bundle یا Runtime مناسب نصب شده؟
- آیا بعد از آپدیت برنامه، نسخه Runtime تغییر کرده است؟
برای سرویسهای اختصاصی، توسعهدهنده باید لاگ داخلی برنامه را هم بررسی کند. خطای 1053 گاهی فقط پوششی برای یک exception داخل برنامه است که در Event Viewer یا لاگ نرمافزار دیده میشود.
مرحله ۷: تعمیر فایلهای سیستمی با SFC و DISM
اگر احتمال میدهید فایلهای سیستمی ویندوز آسیب دیدهاند، میتوانید از ابزارهای SFC و DISM استفاده کنید. Command Prompt را با دسترسی Administrator باز کنید و ابتدا دستور زیر را اجرا کنید:
sfc /scannowاین دستور فایلهای سیستمی ویندوز را بررسی و در صورت امکان تعمیر میکند.
در نسخههای جدید ویندوز سرور، میتوانید DISM را هم اجرا کنید:
DISM /Online /Cleanup-Image /RestoreHealthبعد از پایان عملیات، سرور را ریستارت کنید و دوباره سرویس را Start کنید.
مرحله ۸: افزایش زمان Timeout سرویس با ServicesPipeTimeout
اگر سرویس واقعاً برای Start شدن به زمان بیشتری نیاز دارد، میتوانید زمان انتظار Service Control Manager را افزایش دهید. این کار از طریق رجیستری و مقدار ServicesPipeTimeout انجام میشود.
هشدار: این روش علت اصلی کندی سرویس را حل نمیکند؛ فقط به سرویس زمان بیشتری برای Start شدن میدهد. اگر سرویس بهخاطر خطای داخلی، فایل خراب یا dependency مشکلدار Start نمیشود، افزایش timeout کافی نیست.
برای تنظیم ServicesPipeTimeout:
- کلیدهای
Win + Rرا بزنید. - دستور زیر را وارد کنید:
regedit- به مسیر زیر بروید:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control- در سمت راست، مقدار
ServicesPipeTimeoutرا بررسی کنید. - اگر وجود ندارد، یک مقدار جدید از نوع DWORD (32-bit) Value بسازید.
- نام آن را دقیقاً بگذارید:
ServicesPipeTimeout- روی آن دوبار کلیک کنید.
- گزینه Decimal را انتخاب کنید.
- مقدار را مثلاً روی 60000 قرار دهید.
مقدار 60000 یعنی ۶۰ ثانیه. اگر سرویس شما به زمان بیشتری نیاز دارد، ممکن است مقدار بالاتری مثل 120000 هم استفاده شود. بعد از تغییر این مقدار، سرور را ریستارت کنید.
این روش مخصوصاً زمانی کاربرد دارد که Event Viewer نشان میدهد سرویس بهدلیل timeout Start نشده، اما سرویس از نظر فایلها، دسترسیها و dependencyها سالم است.
مرحله ۹: بررسی آپدیتهای ویندوز سرور
گاهی مشکل Start شدن سرویسها بعد از آپدیت ناقص ویندوز یا نصب نشدن بهروزرسانیهای مهم رخ میدهد. از طرف دیگر، بعضی باگها هم با نصب آخرین آپدیتهای پایدار برطرف میشوند.
برای بررسی آپدیتها:
Settings > Update & Security > Windows Updateدر ویندوز سرور، بسته به نسخه سیستمعامل، ممکن است مسیر کمی متفاوت باشد. بعد از نصب آپدیتهای مهم، سرور را ریستارت کنید و سرویس را دوباره تست کنید.
اگر خطا دقیقاً بعد از یک آپدیت خاص شروع شده، Event Viewer و Update History را بررسی کنید. در برخی موارد، rollback یا uninstall کردن آپدیت مشکلدار ممکن است لازم شود؛ اما این کار باید با احتیاط و پس از بررسی اثرات امنیتی انجام شود.
اگر سرویس اختصاصی یا برنامهنویسیشده دارید
اگر سرویس توسط تیم شما یا یک نرمافزار اختصاصی نوشته شده، خطای 1053 میتواند به ساختار برنامه هم مربوط باشد. برای Windows Serviceهای اختصاصی، متد Start نباید کارهای طولانی و blocking را مستقیم انجام دهد.
نکات مهم برای توسعهدهندگان:
- در زمان Start سرویس، کارهای طولانی را در Thread یا Task جدا اجرا کنید.
- لاگگیری را از اولین خط Start فعال کنید.
- Exceptionها را catch و در Event Log یا فایل لاگ ثبت کنید.
- مسیر فایلهای config، connection string و دسترسیها را بررسی کنید.
- سرویس را یکبار بهصورت console/debug اجرا کنید تا خطا واضحتر دیده شود.
- اگر سرویس به دیتابیس یا API متصل میشود، timeout خارجی را هم بررسی کنید.
در بسیاری از پروژههای اختصاصی، مشکل اصلی داخل برنامه است، اما ویندوز فقط Error 1053 را نمایش میدهد. بنابراین لاگگیری درست در سرویس اهمیت زیادی دارد.
سناریوهای رایج خطای 1053
| سناریو | علت احتمالی | راهکار پیشنهادی |
|---|---|---|
| سرویس قبلاً کار میکرده و ناگهان Start نمیشود | آپدیت، تغییر رمز کاربر سرویس، خرابی فایل یا dependency | Event Viewer، Log On account، مسیر فایلها و Update History را بررسی کنید |
| سرویس اختصاصی تازه نصب شده Start نمیشود | Runtime نصب نیست، مسیر فایل اشتباه است یا کد سرویس مشکل دارد | .NET Runtime، فایل config، لاگ برنامه و اجرای debug را بررسی کنید |
| سرویس دیر Start میشود و timeout میخورد | Service Control Manager زمان کافی نمیدهد | پس از بررسی علت کندی، ServicesPipeTimeout را افزایش دهید |
| بعد از تغییر سرور یا مهاجرت خطا رخ داده | مسیرها، دسترسیها یا dependencyها تغییر کردهاند | Path، permission، runtime و connectionها را بررسی کنید |
| سرویس مربوط به IIS یا وباپلیکیشن مشکل دارد | Application Pool، Runtime، web.config یا دسترسی فایلها | IIS Logs، Event Viewer و تنظیمات App Pool را بررسی کنید |
چکلیست سریع رفع خطای 1053
| مرحله | اقدام |
|---|---|
| ۱ | نام سرویس و زمان دقیق خطا را ثبت کنید |
| ۲ | Event Viewer را بررسی کنید |
| ۳ | Dependencyهای سرویس را کنترل کنید |
| ۴ | حساب کاربری سرویس و رمز آن را بررسی کنید |
| ۵ | مسیر فایل اجرایی و DLLها را کنترل کنید |
| ۶ | .NET Framework یا Runtime موردنیاز را نصب یا اصلاح کنید |
| ۷ | sfc /scannow و در صورت نیاز DISM را اجرا کنید |
| ۸ | اگر سرویس کند است، ServicesPipeTimeout را تنظیم کنید |
| ۹ | سرور را ریستارت و سرویس را دوباره تست کنید |
| ۱۰ | اگر سرویس اختصاصی است، لاگ و کد Start را بررسی کنید |
برای مدیریت بهتر سرویسهای ویندوزی، مطالب دسته ویندوز و مدیریت سرور ویندوز را دنبال کنید. اگر خطا به منابع یا پایداری سرور مربوط است، انتخاب زیرساخت مناسب هم اهمیت دارد؛ در این زمینه مقاله سرور مجازی چیست؟ و صفحه سرور مجازی ایران میتوانند نقطه شروع خوبی باشند.
جمعبندی
خطای 1053 در ویندوز سرور یعنی یک سرویس در زمان مورد انتظار به درخواست Start یا Control پاسخ نداده است. این خطا ممکن است به timeout سرویس، dependencyهای متوقف، دسترسی نامناسب کاربر سرویس، فایلهای خراب، Runtime ناقص، مشکل در کد سرویس یا خرابی فایلهای سیستمی مربوط باشد.
بهترین روش رفع این خطا این است که از Event Viewer شروع کنید، سپس dependencyها، حساب سرویس، مسیر فایل اجرایی، Runtimeها و فایلهای سیستمی را بررسی کنید. اگر همه چیز سالم است اما سرویس واقعاً برای Start شدن زمان بیشتری نیاز دارد، میتوانید مقدار ServicesPipeTimeout را در رجیستری افزایش دهید.
در نهایت، اگر سرویس اختصاصی است، مشکل را فقط از سمت ویندوز نبینید. بسیاری از خطاهای 1053 در واقع به exception، deadlock یا عملیات طولانی داخل خود برنامه مربوط میشوند. لاگگیری درست و تست سرویس در حالت debug میتواند علت اصلی را سریعتر مشخص کند.
سوالات متداول
خطای 1053 در ویندوز سرور یعنی چه؟
یعنی سرویس موردنظر هنگام Start شدن یا دریافت درخواست کنترلی، در زمان مورد انتظار به Service Control Manager پاسخ نداده است.
آیا خطای 1053 همیشه به timeout مربوط است؟
ظاهر خطا به timeout اشاره دارد، اما علت اصلی میتواند dependency، دسترسی، فایل خراب، Runtime ناقص، خطای برنامه یا مشکل رجیستری باشد.
از کجا بفهمم علت اصلی Error 1053 چیست؟
اول Event Viewer را بررسی کنید. در مسیر Windows Logs > System و با Event source مربوط به Service Control Manager معمولاً اطلاعات دقیقتری وجود دارد.
ServicesPipeTimeout چیست؟
یک مقدار رجیستری است که مشخص میکند Service Control Manager چه مدت منتظر Start شدن سرویس بماند. افزایش آن فقط زمانی مفید است که سرویس واقعاً به زمان بیشتری برای شروع نیاز داشته باشد.
مسیر ServicesPipeTimeout در رجیستری کجاست؟
مسیر آن این است: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control. اگر مقدار وجود ندارد، میتوان آن را بهصورت DWORD ساخت.
چه مقداری برای ServicesPipeTimeout مناسب است؟
برای شروع میتوان مقدار 60000 میلیثانیه، یعنی ۶۰ ثانیه، را تست کرد. در سرویسهای سنگینتر ممکن است مقدار بیشتری لازم باشد، اما بهتر است علت کندی سرویس هم بررسی شود.
آیا بعد از تغییر ServicesPipeTimeout باید سرور ریستارت شود؟
بله. برای اعمال این تغییر معمولاً باید ویندوز سرور را ریستارت کنید.
آیا SFC میتواند خطای 1053 را رفع کند؟
اگر خطا به خرابی فایلهای سیستمی مربوط باشد، اجرای sfc /scannow و در صورت نیاز DISM میتواند کمک کند؛ اما برای همه موارد کافی نیست.
اگر سرویس اختصاصی خودمان خطای 1053 میدهد چه کنیم؟
لاگ داخلی سرویس را بررسی کنید، متد Start را سبکتر کنید، کارهای طولانی را در Thread یا Task جدا اجرا کنید و Exceptionها را ثبت کنید.
آیا کمبود منابع سرور میتواند باعث خطای 1053 شود؟
بله. اگر CPU، RAM یا Disk I/O تحت فشار شدید باشد، سرویس ممکن است دیر پاسخ دهد و با timeout مواجه شود.
