2009-02-14 5 views
11

अपने स्वचालित दुर्घटना संग्रह MaxTo के लिए मैं निम्नलिखित क्रैश रिपोर्ट मिल गया के माध्यम से:Win32Exception नहीं भंडारण इस आदेश पर कार्रवाई करने के लिए उपलब्ध है

V8.12.0.0 - System.ComponentModel.Win32Exception - :Void UpdateLayered():0 
Version: MaxTo8.12.0.0 
Exception: System.ComponentModel.Win32Exception 
Error message: Not enough storage is available to process this command 
Stack trace: 
    at System.Windows.Forms.Form.UpdateLayered() 
    at System.Windows.Forms.Form.OnHandleCreated(EventArgs e) 
    at System.Windows.Forms.Control.WmCreate(Message& m) 
    at System.Windows.Forms.Control.WndProc(Message& m) 
    at System.Windows.Forms.ScrollableControl.WndProc(Message& m) 
    at System.Windows.Forms.ContainerControl.WndProc(Message& m) 
    at System.Windows.Forms.Form.WmCreate(Message& m) 
    at System.Windows.Forms.Form.WndProc(Message& m) 
    at MaxTo.MainForm.WndProc(Message& m) 
    at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) 
    at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) 
    at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) 

एक और स्टैकट्रेस: ​​

Version: MaxTo2009.9.0.0 
Exception: System.ComponentModel.Win32Exception 
Error message: Not enough storage is available to process this command 
Stack trace: 
    at System.Windows.Forms.Form.UpdateLayered() 
    at System.Windows.Forms.Form.OnHandleCreated(EventArgs e) 
    at System.Windows.Forms.Control.WmCreate(Message& m) 
    at System.Windows.Forms.Control.WndProc(Message& m) 
    at System.Windows.Forms.ScrollableControl.WndProc(Message& m) 
    at System.Windows.Forms.ContainerControl.WndProc(Message& m) 
    at System.Windows.Forms.Form.WmCreate(Message& m) 
    at System.Windows.Forms.Form.WndProc(Message& m) 
    at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) 
    at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) 
    at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) 

इस नवीनतम स्टैक ट्रेस में मैक्सटो का बिल्कुल कोई संदर्भ नहीं है, और मुझे प्राप्त होने वाले 9 0% क्रैश उपरोक्त के समान स्टैक निशान के साथ हैं।

नेट पर चारों ओर पढ़ना मुझे लगता है कि यदि आप चर को रिलीज़ या डिस्प्ले करना भूल जाते हैं तो यह त्रुटि सामान्य होती है। मेरे WndProc के माध्यम से देखकर, जो कभी-कभी समस्या से गुजरती है, मुझे किसी भी वस्तु के संदर्भ में लटका हुआ एक भी स्थान नहीं मिल रहा है। सभी वैरिएबल में से एक वैंडप्रोक के लिए स्थानीय हैं, और इसलिए विधि समाप्त होने पर कचरा इकट्ठा किया जाना चाहिए।

protected override void WndProc(ref Message m) 
{ 
    base.WndProc(ref m); // I'm assuming the first trace can be caught here 
    IntPtr hwnd = m.WParam; 
    // Our hook tells us something got maximized 
    if (Win32Import.UWM_MAXIMIZE == (UInt32)m.Msg) 
    { 
     // Figure out if we are temporarily disabled or using alternative profiles 
     KeyStateInfo keyState = KeyboardInfo.GetKeyState(Settings.AlternativeProfileKey); 
     Rectangle r = FindRectangle(MousePosition, (Settings.EnableAlternativeProfile && keyState.IsPressed ? AlternativeRegions : Regions)); 
     // Did we find a rectangle to place it in? 
     if (r != Rectangle.Empty) 
     { 
      Rectangle position = Win32Import.GetWindowRectangle(hwnd); 
      Rectangle previousPos = GetLocation(hwnd); 
      if (position == r && previousPos != Rectangle.Empty) 
      { 
       // We are restoring the original position 
       Win32Import.SetWindowPos(hwnd, IntPtr.Zero, previousPos.X, previousPos.Y, previousPos.Width, previousPos.Height, Win32Import.SWP_NOZORDER | Win32Import.SWP_NOSENDCHANGING); 
      } 
      else 
      { 
       // We are maximizing to a region 
       Win32Import.ShowWindow(hwnd, Win32Import.WindowShowStyle.Restore); 
       Win32Import.SetWindowPos(hwnd, IntPtr.Zero, r.X, r.Y, r.Width, r.Height, Win32Import.SWP_NOZORDER | Win32Import.SWP_NOSENDCHANGING); 
       // Make sure we remember this location 
       RememberLocation(hwnd, position); 
      } 
     } 
    } 
    else if (MaxTo64WindowHandleMessage == m.Msg) 
    { 
     // Store the window handle of our 64-bit subprocess 
     SubProcess64WindowHandle = m.WParam; 
    } 
} 

मैं कई दिनों में प्रोग्राम चलाने के दौरान भी त्रुटि को पुन: उत्पन्न करने में सक्षम नहीं हूं।

मेरी धारणा यह है कि सिस्टम या तो अपरिवर्तित स्मृति या जीडीआई हैंडल पर कम है, लेकिन मैं इसे कहीं भी पुष्टि नहीं कर सकता। इस त्रुटि पर कोई अच्छा प्रलेखन प्रतीत नहीं होता है।

कोई विचार यह और क्या हो सकता है? क्या मैं इस त्रुटि को रोकने के लिए कुछ भी कर सकता हूं?

अद्यतन: सवाल एक सभ्य समाधान की कमी की वजह से, अधिक स्टैक ट्रेस के साथ फिर से खोला गया। बस इसे अनदेखा करना समस्या को हल नहीं करता है।

+0

प्रश्न से संबंधित नहीं है लेकिन आप क्रैश रिपोर्ट कैसे एकत्र करते हैं? – Giorgi

+0

Fogbugz BugzScout (Google इसे) का उपयोग करना, और प्रोग्राम में एक कस्टम लिखित वैश्विक त्रुटि हैंडलर का उपयोग करना। यह बहुत मुश्किल नहीं है। –

+0

त्रुटि के समय Windows अनुप्रयोग इवेंट लॉग में कुछ भी रिपोर्ट किया गया है? –

उत्तर

11

कई जीडीआई वस्तुओं/हैंडल को लीक या उपयोग करना। वे संसाधन ढेर की कमी का कारण बन सकते हैं। हो सकता है कि आप पुन: उत्पन्न करने में सक्षम न हों क्योंकि आपके उपयोगकर्ताओं के पास अन्य जीडीआई संसाधन भारी कार्यक्रम चल सकते हैं या टर्मिनल सर्वर का उपयोग कर सकते हैं, इस मामले में उन्हें अन्य उपयोगकर्ताओं के साथ कुछ ढेर साझा करना होगा। System Error. Code: 8. Not enough storage is available to process this command

Here डेस्कटॉप डेस्कटॉप ढेर समस्याओं का निदान करने के लिए आप डेस्कटॉप हीप मॉनीटर टूल के बारे में पढ़ सकते हैं।

Here और here और here GDI रिसाव का पता लगाना उपकरण हैं।

+0

यह होना चाहिए। मुझे लगता है कि यह दुर्घटना जीडीआई हैंडल लीक करने वाले अन्य कार्यक्रमों के कारण हुई थी। मेरे कार्यक्रम की निगरानी से पता चला कि वहां कोई रिसाव नहीं है। –

+0

क्या आपने डेस्कटॉप ढेर को बढ़ाने की कोशिश की है? मेरा प्रयोग यह है कि यह त्रुटि टर्मिनल सर्वर सिस्टम पर अक्सर होती है जहां डेस्कटॉप ढेर के कुछ हिस्सों को उपयोगकर्ताओं के बीच साझा किया जाता है। यह समझा सकता है कि यह त्रुटि उन मामलों में अधिक बार क्यों खुश होती है। –

+0

समस्या यह है कि यह कभी भी मेरे किसी भी कंप्यूटर पर पुन: उत्पन्न नहीं हुआ है, इसलिए मेरे पास इसे पुन: उत्पन्न करने के लिए कुछ भी नहीं है। मैं क्रैश विश्लेषण में अधिक डेटा संग्रह जोड़ रहा हूं, लेकिन मेरे पास अधिक विस्तृत डेटा होने में कुछ समय लगेगा। –

5

आपका प्रोग्राम शायद कर्नेल संसाधनों को लीक कर रहा है। Taskmgr.exe के साथ इस समस्या का निदान करना प्रारंभ करें। देखें + कॉलम का चयन करें, उपयोगकर्ता ऑब्जेक्ट्स, जीडीआई ऑब्जेक्ट्स और हैंडल गिनती की जांच करें। अपने कार्यक्रम को चलाएं और देखें कि इनमें से कोई भी तेजी से बढ़ रहा है या नहीं। एक बार उनमें से एक 10,000 तक पहुंच जाएगा आपका कार्यक्रम मर जाएगा।

कार्रवाई में रिसाव को तुरंत देखने के तरीके के साथ, आप रिसाव कहां देखते हैं यह देखने के लिए कोड टिप्पणी करना प्रारंभ कर सकते हैं। यह शायद आपके "हुक" के साथ कुछ करने के लिए है।

1

समस्या शायद आपके डब्लूडप्रोक में झूठ नहीं बोलती है - कारण आप इसे अपने कॉल स्टैक में देखते हैं क्योंकि विंडोज़ पर जीयूआई से संबंधित सब कुछ WIN32 विंडो प्रक्रिया के माध्यम से जाता है। इसे अपने नियंत्रण में ओवरराइड करने से आपको उच्च स्तरीय .NET ढांचे की प्रक्रिया पूरी होने से पहले निम्न स्तर की सामग्री को संसाधित करने के लिए एक हुक पॉइंट देता है।

यह अंधेरे में एक पूरा शॉट होने जा रहा है, लेकिन शायद this post प्रासंगिक हो सकता है? - शायद उन स्टैक निशान के साथ नहीं, हालांकि।

+0

मैं नहीं देख सकता कि यह कैसे प्रासंगिक होगा, क्योंकि मैं इस त्रुटि को उत्पन्न करने के लिए लिंक पोस्ट नहीं देख सकता हालांकि, मैक्सटो मुख्य विंडो में घोंसले पैनल होते हैं, बस 12-15 के स्तर के करीब कहीं भी गहराई नहीं है, जब तक कि उपयोगकर्ता वास्तव में उनकी सेटिंग्स के साथ अजीब नहीं हो रहा है। :) –

+0

@ वेगार्ड: स्टैक निशान शायद अलग दिखेंगे यह समस्या थी। क्या आपके पास पूर्ण Win32 स्टैक निशान प्राप्त करने का कोई तरीका नहीं है और न केवल .net ट्रेस? – snemarch

+0

मुझे इतना आसानी से नहीं लगता है। मैं अपनी मशीनों पर पुन: उत्पन्न करने में कभी सक्षम नहीं हुआ हूं। स्टैक ट्रेस बस अपवाद ऑब्जेक्ट से है, मुझे नहीं पता कि Win32 स्टैकट्रैक कैसे प्राप्त करें (और मुझे यह पता लगाने के बाद उपयोगकर्ता को एक कस्टम बिल्ड के साथ प्रदान करना होगा कि इसे .NET से कैसे प्राप्त किया जाए)। –

0

मेरे पास अपने संसाधनों के साथ कई कस्टम विंडोज नियंत्रण थे, इसलिए जब मैं कई नियंत्रण बनाता हूं तो यह त्रुटि दिखाई देती है। इस समस्या को ठीक करने के लिए मैंने अपनी लाइब्रेरी में संसाधन फ़ाइल बनाई और मेरे घटक कोड पर संसाधनों के बजाय बाहरी संसाधनों का उपयोग किया। उसके बाद मेरा अपवाद समाप्त हो गया है, पहले से ही 3 गुना अधिक खुले रूपों के साथ परीक्षण किया गया है और यह त्रुटि चली गई है। ऐसा लगता है कि यह एक समाधान है।

संबंधित मुद्दे