windows - 1053 त्रुटि: सेवा ने प्रारंभिक नियंत्रण में समय या नियंत्रण अनुरोध पर प्रतिक्रिया नहीं दी




error-handling windows-services (20)

मैंने हाल ही में कुछ ऐसे अनुप्रयोगों को विरासत में मिला है जो विंडो सेवाओं के रूप में चलती हैं, और मुझे दोनों के साथ एक GUI (सिस्टम ट्रे में एक संदर्भ मेनू से सुलभ) प्रदान करने में समस्या हो रही है

कारण है कि हमें खिड़कियों की सेवा के लिए एक GUI की ज़रूरत है ताकि खिड़कियों सेवा को रोकने / फिर से शुरू करने के बिना पुन: कॉन्फ़िगर किया जा सके।

मेरा कोड डीबग मोड में ठीक काम करता है, और मुझे प्रसंग मेनू आते हैं, और सब कुछ सही तरीके से व्यवहार करता है।

जब मैं किसी नामित खाते का उपयोग करके "installutil" सेवा स्थापित करता हूं (यानी, स्थानीय सिस्टम खाता नहीं), सेवा ठीक चलती है, लेकिन सिस्टम ट्रे में आइकन प्रदर्शित नहीं करता (मुझे पता है कि यह सामान्य व्यवहार है क्योंकि मैं नहीं "डेस्कटॉप के साथ बातचीत" विकल्प है)।

यहां समस्या है - जब मैं "लोकलसिस्टम एसीसी" विकल्प चुनता हूं, और "डेस्कटॉप के साथ इंटरैक्ट" विकल्प की जांच करता हूं, तो सेवा को बिना किसी स्पष्ट कारण के लिए शुरू करने के लिए AGES लगती है, और मैं बस चल रहा हूं

स्थानीय कंप्यूटर पर सेवा ... शुरू नहीं किया जा सका।

1053 त्रुटि: सेवा ने प्रारंभिक नियंत्रण में समय या नियंत्रण अनुरोध पर प्रतिक्रिया नहीं दी।

संयोग से, मैंने विंडोज सर्विस टाइमआउट को डिफॉल्ट 30 सेकेंड से 2 मिनट तक एक रजिस्ट्री हैक के माध्यम से बढ़ाया ( http://support.microsoft.com/kb/824344 , अनुभाग 3 में टाइमआउट अवधि के लिए खोज), हालांकि सेवा अभी भी शुरू होती है समय पूरा हुआ।

मेरा पहला सवाल है - "स्थानीय सिस्टम खाता" लॉगिन क्यों लग सकता है SOOOOO बहुत अधिक समय जब सेवा गैर- LocalSystemAccount के साथ लॉग इन करता है, जिससे विंडो सर्विस टाइम-आउट हो सकता है? शुरूआत में इस तरह के अलग-अलग व्यवहार के कारण इन दोनों के बीच अंतर क्या हो सकता है?

दूसरे - एक कदम वापस लेना, जो सभी मैं हासिल करने की कोशिश कर रहा हूं, बस एक खिड़की सेवा है जो कॉन्फ़िगरेशन के लिए एक GUI प्रदान करती है - मुझे गैर-स्थानीय सिस्टम खाते (नामित उपयोगकर्ता / पीडब्ल्यूडी के साथ) का उपयोग करने में बहुत खुशी होगी अगर मैं डेस्कटॉप के साथ इंटरैक्ट करने के लिए सेवा प्राप्त कर सकता हूं (अर्थात, सिस्टम ट्रे से एक संदर्भ मेन्यू उपलब्ध है)। क्या यह संभव है और यदि ऐसा हो तो कैसे?

उपरोक्त प्रश्नों के लिए कोई भी संकेत सराहना होगा!


अपनी सेवा के स्टार्टअप को डिबग करने के लिए, निम्न सेवा को अपनी सेवा की OnStart() विधि के शीर्ष पर जोड़ें:

 while(!System.Diagnostics.Debugger.IsAttached) Thread.Sleep(100);

यह सेवा को रोक देगा जब तक कि आप डीबग -> प्रक्रिया में संलग्न न करें का उपयोग करके विज़ुअल स्टूडियो डीबगर मैन्युअल रूप से संलग्न करते हैं ...

नोट: सामान्य तौर पर, अगर आपको अपनी सेवा के साथ एक इंटरैक्ट करने के लिए उपयोगकर्ता की आवश्यकता होती है, तो जीयूआई घटकों को एक अलग विंडोज़ एप्लिकेशन में विभाजित करना बेहतर होता है, जो उपयोगकर्ता लॉग इन करते समय चलाता है। तब आप कुछ नामित पाइप या किसी अन्य प्रकार के आईपीसी जीयूआई ऐप और आपकी सेवा के बीच संचार स्थापित करने के लिए यह वास्तव में एकमात्र तरीका है जो Windows Vista में संभव है।


मैं यहाँ अंधा की शूटिंग कर रहा हूं, लेकिन मुझे अक्सर पता चला है कि सर्विस स्टार्टअप में लंबे समय से देरी सीधे या अप्रत्यक्ष रूप से नेटवर्क फ़ंक्शन टाइमआउट के कारण होती है, अक्सर जब कोई डोमेन नियंत्रक से संपर्क करने का प्रयास करते हैं तो खाते SIDs की तलाश करते हैं - जो अप्रत्यक्ष रूप से संभवतः माध्यम से होता है GetMachineAccountSid() क्या आप इसे महसूस करते हैं या नहीं, क्योंकि उस फ़ंक्शन को RPC सबसिस्टम द्वारा कहा जाता है

ऐसी स्थितियों में कैसे डिबग करने के लिए एक उदाहरण के लिए, मार्क रसेलोविच के ब्लॉग पर प्रक्रिया स्टार्टअप विलंब का केस देखें।


सेवा के डिबग बिल्ड को स्थापित करें और क्या हो रहा है यह देखने के लिए सेवा में डीबगर को संलग्न करें।


मुझे यह समस्या भी हुई। मैंने इसे स्थानीय सिस्टम खाते में लॉग ऑन खाते बदलकर काम करने के लिए बनाया है। मेरी परियोजना में मुझे स्थानीय सेवा खाते के रूप में चलाने के लिए सेटअप था। इसलिए जब मैंने इसे स्थापित किया था, तो डिफ़ॉल्ट रूप से यह स्थानीय सेवा का उपयोग कर रहा था। मैं .net 2.0 और वीएस 2005 का उपयोग कर रहा हूं। तो .net 1.1 SP1 इंस्टॉल करने से मदद नहीं मिली।


यदि आप अपनी सेवा को सीधे उपयोगकर्ता के डेस्कटॉप से ​​इंटरैक्ट करने की कोशिश कर रहे हैं, तो आप खो देंगे: यहां तक ​​कि सबसे अच्छी परिस्थितियों में (अर्थात "विस्टा के पहले"), यह बेहद मुश्किल है।

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

आपकी सेवा स्टार्टअप पर लटकाए जाने की सबसे अधिक संभावना है, क्योंकि यह एक निरर्थक डेस्कटॉप (या एक्सप्लोरर मानता है कि सिस्टम उपयोगकर्ता सत्र में चल रहा है, जो भी मामला नहीं है) के साथ बातचीत करने की कोशिश कर रहा है, या एक अदृश्य डेस्कटॉप से ​​इनपुट का इंतजार कर रहा है ।

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

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

यह UI और सेवा कोड के बीच इस जुदाई को हासिल करने के लिए कुछ प्रयास करेगा: हालांकि, चीजों को मज़बूती से काम करने का एकमात्र तरीका है, और भविष्य में आपकी अच्छी सेवा करेगा।

एडेंडम, अप्रैल 2010: चूंकि यह सवाल काफी लोकप्रिय रहा है, इसलिए यहां एक और सामान्य परिदृश्य को ठीक करने का एक तरीका है, जिसके कारण "सेवा का जवाब नहीं दिया गया ..." त्रुटियाँ, जो कि नेटवर्क्स से जुड़ी तरह की कोई भी मज़ेदार चीजों का प्रयास न करें। , लेकिन Authenticode पर हस्ताक्षर किए विधानसभाओं का उपयोग करें: अपने .exe.config फ़ाइल में निम्न तत्व जोड़कर प्रकाशक सबूत बनाने के लिए लोड समय पर प्रामाणिकोड हस्ताक्षर का सत्यापन अक्षम करें :

<configuration>
    <runtime>
        <generatePublisherEvidence enabled="false"/>
    </runtime>
</configuration>

प्रकाशक सबूत एक छोटे से इस्तेमाल किया कोड एक्सेस सुरक्षा (सीएएस) सुविधा है: केवल ऐसी संभावना की घटना में जो आपकी सेवा वास्तव में PublisherMembershipCondition पर निर्भर करती है, इसे समस्याओं के कारण अक्षम कर देगा। अन्य सभी मामलों में, यह स्थायी या आंतरायिक स्टार्टअप असफलताओं को दूर कर देगा, बिना आवर्ती प्रमाण पत्र की जांच करने के लिए रनटाइम की आवश्यकता की आवश्यकता है (निरस्तीकरण सूची देखने के साथ)।


मेरे मामले में, मुझे एक वास्तविक त्रुटि के कारण इस परेशानी हुई थी। सर्विस कन्स्ट्रक्टर को कहा जाने से पहले, सदस्य चर का एक स्थिर कन्स्ट्रक्टर असफल रहा था:

    private static OracleCommand cmd;

    static SchedTasks()
    {
        try
        {
            cmd = new OracleCommand("select * from change_notification");
        }
        catch (Exception e)
        {
            Log(e.Message); 
            // "The provider is not compatible with the version of Oracle client"
        }
    }

कोशिश-कैल ब्लॉक जोड़कर मुझे पता चला कि ओएकल संस्करण गलत होने के कारण अपवाद उत्पन्न हो रहा था। सही डेटाबेस स्थापित करने से समस्या हल हुई


दिनों के लिए यह संदेश लड़ने के बाद, एक मित्र ने मुझे बताया कि आपको रिलीज़ बिल्ड का उपयोग करना होगा। जब मैं डीबग बिल्ड स्थापित करता है, तो यह संदेश देता है। रिलीज़ बिल्ड ठीक शुरू होता है


मुझे यह समस्या थी और उसने मुझे दो दिन के लिए पागल कर दिया ... अगर आपकी समस्या मेरा समान है:

मेरी खिड़कियों की सेवा में मेरे पास सेटिंग्स "उपयोगकर्ता सेटिंग्स" हैं, इसलिए सर्विस सर्विस को रोकने और शुरू करने के बिना स्वयं-रखरखाव कर सकती है। खैर, समस्या "उपयोगकर्ता सेटिंग्स" के साथ होती है, जहां इन सेटिंग्स के लिए कॉन्फ़िग फाइल को उपयोगकर्ता के उपयोगकर्ता-प्रोफ़ाइल के तहत एक फ़ोल्डर में सहेजा जाता है जो सेवा- exe फ़ाइल संस्करण के तहत विंडोज़ सेवा चल रहा है।

किसी कारण के लिए यह फ़ोल्डर दूषित था मैंने फ़ोल्डर को हटा दिया और सेवा हमेशा की तरह वापस फिर से काम करना शुरू कर रहा है ...


मुझे भी इसी तरह की समस्या का सामना करना पड़ा और पाया गया कि विधानसभा को लोड करने में समस्या थी। सेवा शुरू करने का प्रयास करते समय मुझे यह त्रुटि तुरंत मिली थी।

इस समस्या को तुरंत डिबग करने के लिए, प्रोकंप http://technet.microsoft.com/en-us/sysinternals/dd996900 का उपयोग करके कमांड प्रॉम्प्ट के द्वारा सेवा निष्पादन योग्य चलाने का प्रयास करें। यह सटीक त्रुटि के बारे में पर्याप्त संकेत प्रदान करेगा।

http://bytes.com/topic/net/answers/637227-1053-error-trying-start-my-net-windows- सेवा ने मुझे काफी थोड़ी मदद की।


"होस्ट्स" फ़ाइल में 127.0.0.1 क्रेल। माइक्रोसॉफ्ट को जोड़कर हमारी समस्या हल हो गई है।


मेरी सेवा चलाने वाले बॉक्स पर लापता ढांचे के कारण मुझे इस समस्या का सामना करना पड़ा बॉक्स में .NET 4.0 था और सेवा .NET 4.5 के शीर्ष पर लिखा गया था।

मैं बॉक्स पर निम्नलिखित डाउनलोड स्थापित किया, पुनरारंभ किया, और सेवा ठीक शुरू हुई: http://www.microsoft.com/en-us/download/details.aspx?id=30653


मुझे इस समस्या थी, इसे ठीक करने के लिए लगभग एक दिन लग गया। मेरे लिए समस्या यह थी कि मेरा कोड "मुख्य सामग्री" को छोड़ दिया और प्रभावशाली रूप से कुछ पंक्तियों को समाप्त कर दिया। और यह मेरे लिए त्रुटि का कारण बना। यह एक सी # कंसोल एप्लिकेशन है जो एक विंडोज सर्विस स्थापित करता है, जैसे ही इसे सर्विस कंट्रोलर (sc.Run ()) के साथ चलाने की कोशिश करता है तो यह मेरे लिए यह त्रुटि देगा

मुख्य कोड पर जाने के लिए कोड को तय करने के बाद, यह इच्छित कोड चलाएगा:

ServiceBase.Run(new ServiceHost());

फिर इसे दिखाना बंद कर दिया

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

कोशिश करें और अपने कोड को sc.Run () का उपयोग किए बिना चलने के लिए प्राप्त करें (यानी कोड रन करें जो sc.Run () निष्पादित होता है)।


यदि आप नीचे दी गई डीबग कोड को आपकी सेवा में उपयोग कर रहे हैं तो समस्या उत्पन्न हो सकती है

#if(!DEBUG)
ServiceBase[] ServicesToRun;
ServicesToRun = new ServiceBase[]
{
new EmailService()
};
ServiceBase.Run(ServicesToRun);
#else
//direct call function what you need to run
#endif

इसे ठीक करने के लिए, जब आप अपनी खिड़कियों की सेवा का निर्माण करते हैं तो #if को हटा दें क्योंकि यह काम नहीं कर रहा है जैसा कि यह है।

कृपया नीचे के रूप में डीबग मोड के लिए तर्क का उपयोग करें।

if (args != null && args.Length > 0)
{
_isDebug = args[0].ToLower().Contains("debug");
}

मेरे मामले में समस्या को .net framework संस्करण गुम नहीं था।

मेरी सेवा का इस्तेमाल किया

<startup>
  <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>

लेकिन सर्वर का .net Framework संस्करण 4 था, इसलिए 4.5 से 4 की समस्या को तय करके तय किया गया था:

<startup>
  <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0" />
</startup>

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


हमारे पास Login4Net को डेटाबेस तालिका में लॉग इन करने के लिए कॉन्फ़िगर किया गया है। तालिका इतनी बड़ी हो गई थी कि सेवा संदेशों को लॉग इन करने की कोशिश कर रही थी।


  1. रिलीज़ मोड में प्रोजेक्ट बनाएं
  2. सभी रिलीज़ फ़ोल्डर फ़ाइलों को स्रोत पथ पर कॉपी करें।
  3. कमांड प्रॉम्प्ट विंडो का उपयोग प्रशासनिक पहुंच में विंडो सेवा निष्पादित करें।
  4. स्रोत पथ से कभी भी फ़ाइलें हटाना नहीं

पट्टे पर यह मेरे लिए काम करता है


एक बार अपनी exe फ़ाइल को चलाने का प्रयास करें मुझे एक ही समस्या थी, लेकिन जब मैं इसे सीईई फ़ाइल पर डबल क्लिक करके प्रत्यक्ष चला गया, तो मुझे नेट फ्रेमवर्क वर्जन के बारे में एक संदेश मिला, क्योंकि मुझे एक ऐसे ढांचे के साथ सेवा प्रोजेक्ट जारी कर दिया गया था जो इसे लक्ष्य मशीन पर स्थापित नहीं किया गया था।


मुझे घंटों में ले लिया, क्या ईवेंट व्यूअर get_AppSettings () को देखना चाहिए था

ऐप कॉन्फ़िग में एक बदलाव ने समस्या का कारण बना दिया।


मेरी समस्या Windows सेवा कॉन्फ़िग में उल्लिखित ढांचे को लक्षित करने की वजह थी

<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6"/>
 </startup>

और मेरे सर्वर में जिसमें मैंने विंडोज़ सेवा स्थापित करने की कोशिश की थी, इस नेट संस्करण के लिए समर्थित नहीं था।

बदलते हुए, मैं इस मुद्दे को हल करने में सक्षम हो सकता था।





timeout