विंडो के पुनरारंभ होने के बाद स्वचालित सेवाएँ स्वचालित रूप से प्रारंभ नहीं होती हैं

Question

मेरे पास विंडोज़ 10 है जो सभी अपडेट के साथ 1511 में बनाया गया है।

आज मैंने कुछ अजीब व्यवहार देखा है:

जब मैं एक सिस्टम रीस्टार्ट करता हूं, उसके बाद, स्टार्टअप प्रकार स्वचालित के साथ कुछ सेवाएं स्वचालित रूप से शुरू नहीं होती हैं।

लेकिन मैं उन्हें मैन्युअल रूप से शुरू कर सकता हूं, और उसके बाद सब कुछ ठीक है। लेकिन अगर मैं सिस्टम रीस्टार्ट करता हूं, तो समस्या फिर से दिखाई देती है।

यदि मैं मैन्युअल रूप से सेवा शुरू करता हूं, और मैं शटडाउन करने के बाद, पीसी को फिर से चालू करने पर सब कुछ ठीक है। तो सेवाओं को स्वचालित रूप से शुरू किया जाना चाहिए जैसा कि होना चाहिए। समस्या केवल तब दिखाई देती है जब मैं Windows को पुनरारंभ करता हूं। पुनरारंभ करने के बाद, ये सेवाएँ स्वचालित रूप से प्रारंभ नहीं होती हैं।

यह समस्या केवल कुछ सेवाओं के लिए दिखाई देती है जो अनुप्रयोगों से जुड़ी होती हैं (न कि वे जो सिस्टम सेवाएँ हैं)। ये सेवाएँ किसी अन्य सेवा पर निर्भर नहीं करती हैं।

मैं क्या कर सकता हूँ ?

धन्यवाद !

Comments

शायद आप ऐसी सेवाओं के कुछ उदाहरण दे सकते हैं जो शुरू करने में विफल हैं। यह अनुमान लगाना कठिन है कि समस्या बिना किसी विवरण के क्या हो सकती है।

— dxiv

यदि यह आपको कोई बेहतर महसूस कराता है, तो आप अकेले नहीं हैं। मेरा ठीक यही मुद्दा है। सेवाएँ 32 बिट हैं। कुछ समय पहले कस्टम सॉफ़्टवेयर स्थापित किया गया था। तो WOW64 सेटिंग है, चालू है। मैं सेवाओं को मैन्युअल रूप से शुरू कर सकता हूं, लेकिन कभी भी विंडोज 7 से विंडोज 10 में अपग्रेड करने के बाद, ओएस सेवाओं को शुरू करने का कोई प्रयास नहीं करता है। उनकी ट्रेस फ़ाइलें कुछ भी नहीं दिखाती हैं, और ईवेंट लॉग उन्हें शुरू करने का कोई प्रयास नहीं दिखाता है, और न ही उनके साथ कोई समस्या। बहुत निराशा होती है। स्वचालित देरी एक घटिया विकल्प है, लेकिन मुझे लगता है कि यह अभी के लिए है ...

— ब्रायन बी

यहां भी देखें: stackoverflow.com/questions/33238665/…

— RenniePet

मेरे लिए यह समस्या होने पर, "MySomain \" [e-mail] "से" MyDomain \ MyUser "फ़ॉर्म में नेटवर्क नाम के लिए, सेवा में" गुण> लॉग ऑन "में" इस खाते "को बदलते हुए, समस्या को हल किया गया।" हालांकि मेरे पास कोई स्पष्टीकरण नहीं है।

— एमबी वाइज

Answer 1

एकमात्र समाधान जो फिलहाल काम करता है, वह है इन सेवाओं के स्टार्टअप प्रकार को स्वचालित से स्वचालित विलंब में बदलना। मुझे नहीं पता कि यह सबसे अच्छा समाधान है, लेकिन अभी के लिए केवल यही काम करता है।

Comments

यदि आप regedit के साथ सहज हैं, तो मुझे पता चला कि जब तक सेवा में प्रमुख DelayedAutostart (DWORD) है, यह शुरू हो जाएगा। इसलिए मैंने इसे जोड़ा, लेकिन मान 0 पर सेट कर दिया, क्योंकि मैं नहीं चाहता था कि इसमें देरी हो। उदाहरण: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ <yourServiceName> \ DelayedAutostart

— ब्रायन बी

मुझे Microsoft तकनीकी पर एक धागा भी मिला ।

— रेनीपेट

Answer 2

मेरे पिछले उत्तर ने हमारी समस्या को ठीक नहीं किया। अंत में, हमने सेवाओं के बाहर के समय को उच्च मूल्य पर सेट करके इसे ठीक किया। इस समाधान का प्रयास करें:

Start> Run> पर जाएं और regedit टाइप करें

नेविगेट करें: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control

नियंत्रण फ़ोल्डर चयनित के साथ, दाईं ओर फलक में राइट क्लिक करें और नए DWORD मान का चयन करें

नए DWORD का नाम दें: ServicesPipeTimeout

राइट-क्लिक करें ServicesPipeTimeout पर राइट-क्लिक करें, और उसके बादसंशोधित करें

दशमलव पर क्लिक करें, '180000' टाइप करें, और उसके बाद ठीक पर क्लिक करें

कंप्यूटर को पुनरारंभ

कारण:

Microsoft Windows सेवा नियंत्रण प्रबंधक सभी स्थापित Windows सेवाओं की स्थिति (यानी, प्रारंभ, रोका, रोका गया, आदि) को नियंत्रित करता है। डिफ़ॉल्ट रूप से, सेवा नियंत्रण प्रबंधक जवाब देने के लिए एक सेवा के लिए 30,000 मिलीसेकंड (30 सेकंड) का इंतजार करेगा। हालाँकि, कुछ कॉन्फ़िगरेशन, तकनीकी प्रतिबंध या प्रदर्शन समस्याओं के परिणामस्वरूप सेवा में 30 सेकंड से अधिक समय लग सकता है और सेवा नियंत्रण प्रबंधक के लिए तैयार रिपोर्ट कर सकते हैं।

ServicesPipeTimeout DWORD मान का संपादन या निर्माण करके, सेवा नियंत्रण प्रबंधक टाइमआउट अवधि को ओवरराइड किया जा सकता है, जिससे सेवा शुरू होने और सेवा के लिए तैयार रिपोर्ट करने के लिए अधिक समय मिल सकता है।

संदर्भ मामला:

रिपोर्टिंग सर्वर त्रुटि 1053: सेवा ने समय पर फैशन में शुरुआत या नियंत्रण अनुरोध का जवाब नहीं दिया

https://social.technet.microsoft.com/Forums/windows/en-US/b57ee42d-42ef-44a4-9670-be9088dbf9d4/reporting-server-error-1053-the-service-did-not-respond-to- शुरू या नियंत्रण अनुरोध में एक-समय पर? मंच = sqlreportingservices

सौभाग्य यह फिक्स का स्रोत है

Answer 3

आप स्टार्टअप को "स्वचालित ट्रिगर" से "स्वचालित" तक कमांड द्वारा संशोधित कर सकते हैं: sc triginfo w32time डिलीट

अब, रिबूट के बाद सेवा स्वचालित रूप से शुरू हो सकती है

Comments

समझने की कोशिश कर रहा है: क्या यह नया आइडियल "फीचर" विंडोज का है, या यह बहुत पहले से मौजूद था? पता चला कि मेरे व्यवसायिक क्रिटिकल सर्वर ntp सर्वर के कारण सिंक नहीं कर रहे थे, क्योंकि विंडोज टाइम सेवा ने अचानक अपने स्टार्ट टाइप को ऑटोमैटिक से ऑटोमैटिक (ट्रिगर स्टार्ट) में बदल दिया है और निश्चित रूप से समय को सिंक्रनाइज़ करने के लिए एक निर्धारित कार्य का कोई भी प्रयास विफल हो रहा था।

— अनातोली अलेक्सेव

Answer 4

ठीक है, विंडोज इन सेवाओं को रोक सकता है अगर उन्हें ज़रूरत नहीं है या यदि कुछ भी हो रहा है तो सेवा को रोकने का निर्देश है। कुछ सेवाएं अन्य सेवाओं पर निर्भर करती हैं और वे केवल तभी शुरू होंगी जब पहली बार उन्हें कॉल किया जाएगा।

एक त्रुटि के कारण सेवा समय से पहले बंद हो सकती है। आप ईवेंट लॉगर पर जा सकते हैं और देख सकते हैं कि क्या इन सेवाओं से संबंधित त्रुटियाँ हैं। यदि इसके बाद "(ट्रिगर शुरुआत)" होती है, तो इन सेवाओं की आमतौर पर आवश्यकता नहीं होती है या वे केवल तब शुरू होती हैं जब इसकी आवश्यकता होती है, उदाहरण के लिए, बॉयोमीट्रिक सेवाएं।

आप इस बारे में और जानकारी भी प्राप्त कर सकते हैं कि यहाँ सेवाएं कैसे काम करती हैं ।

जब तक आप अपने पीसी को देख नहीं रहे हैं तब तक ठीक से काम नहीं कर रहा है, यह वास्तव में एक समस्या नहीं होनी चाहिए।

Comments

क्षमा करें मित्र, लेकिन शायद आप समझ नहीं पाए हैं कि मैं क्या कह रहा हूं। इन सेवाओं में स्वचालित स्टार्टअप प्रकार है, और सिस्टम सेवाएँ नहीं हैं। वे कुछ एप्लिकेशन की स्थापना के बाद स्थापित होते हैं। बहुत अच्छा काम कर रहे हैं। अगर मैं खिड़कियां बंद करता हूं, और चालू करता हूं, तो ये सेवाएं अपने आप शुरू हो जाती हैं और सब कुछ ठीक चलता है। लेकिन समस्या दिखाई देती है अगर मैं विंडोज़ को पुनरारंभ करता हूं। पुनरारंभ करने के बाद ये सेवाएँ अपने आप शुरू नहीं होती हैं, और उनसे संबंधित एप्लिकेशन काम नहीं करता है। मैं मैन्युअल रूप से शुरू कर सकता हूं और जब तक मैं एक और पुनरारंभ नहीं करता हूं तब तक सब कुछ ठीक रहता है और समस्या फिर से दिखाई देती है।

— एलेक्स

हम्म, मुझे लगता है कि आपको वास्तव में इवेंट लॉगर पर एक नज़र डालनी चाहिए, ताकि यह देखा जा सके कि सेवाएं किसी प्रकार की त्रुटि उत्पन्न करती हैं या नहीं। तो आप इसे खोल सकते हैं और अपने पीसी को पुनः आरंभ करने वाले समय सीमा के पास संदेशों की तलाश कर सकते हैं। यदि वे किसी त्रुटि के कारण समय से पहले रुक रहे हैं, तो उस त्रुटि का विवरण या कोड वहां मिल सकता है और हमें इस बात का बेहतर अंदाजा हो सकता है कि वास्तविक समस्या क्या है।

— axys93

नहीं, इवेंट लॉगर में कोई त्रुटि नहीं है। कोई लॉग नहीं है जो समय से पहले रुकने का वर्णन करता है। सेवा अभी शुरू नहीं हुई है। ऐसा लगता है कि अगर मैं विंडोज़ 10 को पुनरारंभ करता हूं, तो सिस्टम इन सेवाओं के स्वचालित स्टार्टअप प्रकार को अनदेखा करता है।

— एलेक्स

@alex आपका लिंक तकनीकी पर एक चर्चा सूत्र का संदर्भ देता है , जहाँ यह ध्यान दिया जाता है कि घटना लॉग में एक प्रविष्टि है जो यह दर्शाता है कि सेवा शुरू करने में विफल रही है ( "The SQL Server (MSSQLSERVER) service failed to start ..".)। यह आपके दावे से काफी अलग है The service doesn't fail to start। दोहराने के जोखिम पर, आपका प्रश्न बिना किसी विवरण के अब जैसा है, वैसा ही अचूक है।

— dxiv

@alex यह मेरी कड़ी नहीं है । क्या आपने अपने द्वारा पोस्ट की गई लिंक को भी पढ़ा है? दूसरा पैराग्राफ कहता The issue is reported on below MSDN thread https://social.technet.microsoft.com/Forums/sqlserver/en-US/bb5f2199-f283-4249-a029-53978d637148/sql-service-stops-working-after-windows-10-upgrade?forum=sqldatabaseengineहै कि मैं कहाँ से उद्धृत किया गया था। वैसे भी, इस बिंदु पर मैं इसे दूसरे को छोड़ दूंगा कि आपके हिस्से से किसी भी सहायता के बिना समस्या क्या हो सकती है।

— dxiv

Answer 5

मुझे भी यही समस्या थी। मशीन के पुनरारंभ होने के बाद सेवाएं स्वचालित रूप से पुनरारंभ नहीं हुईं। कारण यह है कि विंडोज 10 शटडाउन बटन का मतलब (विंडोज 7 के विपरीत) एक शटडाउन नहीं है, लेकिन "पावर पॉवर बटन" कॉन्फ़िगरेशन इस प्रकार है, तो इसे स्टैंडबाय माना जा सकता है।

इस मामले में, यदि सेवाएं रोक दी गईं, तो वे बने रहें। यदि उन्हें शुरू किया गया था, तो वे बिना पुनरारंभ किए (बिना किसी आरंभ के) चलते रहते हैं। जीन-मैरी

Comments

आप इसका निष्कर्ष कैसे निकालेंगे? क्या आप कोई स्रोत प्रदान कर सकते हैं?

— मार्क

Answer 6

हमारे लिए यह तय है कि यदि आप सेवा को स्वयं निष्पादन योग्य बदल सकते हैं:

प्रोजेक्ट फ़ाइल में 32-बिट ध्वज को झूठा करने के लिए बदलें , फिर सेवा को पुनर्स्थापित करें।

CorFlags.exe के साथ अपनी सेवा की जाँच करें । 32BITREQ और 32BITPREF 0 होना चाहिए।

Version   : v4.0.30319
CLR Header: 2.5
PE        : PE32
CorFlags  : 0x1
ILONLY    : 1
32BITREQ  : 0
32BITPREF : 0
Signed    : 0

Comments

क्या आप Visual Studio 2010 में वरीयता ध्वज सेट करने का एक तरीका जानते हैं?

— नील वीचेर

नहीं, मैं नहीं, लेकिन आप अपनी csproj फ़ाइल की जाँच कर सकते हैं, यह तब जारी करने के अपने संपत्ति समूह में <Prefer32Bit> झूठी </ Prefer32Bit> होना चाहिए।

— माइकल वैन डेर होर्स्ट

Answer 7

इसके साथ प्रयास करें:

ट्रिगर इवेंट को परिभाषित करने के लिए निम्न कमांड चलाएँ जो आपके वातावरण के अनुकूल हो। इस उदाहरण में, कमांड यह निर्धारित करता है कि एक होस्ट को आईपी पता दिया जाता है या नहीं, और फिर यह सेवा शुरू या बंद हो जाती है।

sc triginfo w32time start / networkon stop / networkoff

जहाँ w32Time आपकी सेवा का नाम है

या यह कोशिश करो

https://support.microsoft.com/en-us/kb/922918

Comments

कृपया प्रश्न को फिर से ध्यान से पढ़ें। आपका उत्तर मूल प्रश्न का उत्तर नहीं देता है ।

— DavidPostill

देरी से शुरू होने वाली कुछ चीजों में दौड़ना भी उतना प्रभावी नहीं है, यह एक सुधार है, ट्रिगर जानकारी मदद करती है।

— अमृतांशु

Answer 8

नीचे दिए गए आदेश के साथ प्रयास करें:

sc config "SVCNAME" start= delayed-auto

Answer 9

यदि किसी के पास अभी भी इसके बारे में समस्या है: NSClient version 0.5डिफ़ॉल्ट सेवा राज्य से ट्रिगर का पता लगाना। हमें इसे मैन्युअल रूप से जोड़ना होगा:

*your_command* check_service -a "filter=is_trigger=0" *other_arguments* 

Answer 10

एमबी वाइज से टिप्पणी देखें:

मेरे लिए यह समस्या होने पर, "MySomain \" [e-mail] "से" MyDomain \ MyUser "फ़ॉर्म में नेटवर्क नाम के लिए, सेवा में" गुण> लॉग ऑन "में" इस खाते "को बदलते हुए, समस्या को हल किया गया।" हालांकि मेरे पास कोई स्पष्टीकरण नहीं है। - 13-26 बजे एमबी वाइज 14 '18