We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy.
Unfortunately, activation email could not send to your email. Please try again.

LocalDataStoreSlot exception using XPMenus

Thread ID:





13700 May 6,2004 02:07 PM Mar 7,2005 06:46 PM Windows Forms 10
Tags: Tools
Administrator [Syncfusion]
Asked On May 6, 2004 02:07 PM

Hi. I''m having problems with my app crashing on exit most (but not all) of the time. Usually, I get an unhandled exception of type "System.InvalidOperationException" in mscorlib.dll, with "LocalDataStoreSlot storage has been freed." Occasionally, I instead get "The exception unknown software exception (0xc0020001) occurred in the application at location 0x7xxxxxxx. The caption of the message box is ".NET-BroadcastEventWindow.1.0.5000.0.20: MyApp.exe - Application Error". It dies inside my MainForm''s overriden Dispose(), when it calls components.Dispose(). (which is boilerplate code). Everything worked fine until I switched from normal menus to XPMenus. (I switched partly because I''d read in this forum that normal menus and docking windows didn''t mix too well - the designer wouldn''t work properly with the latter.) Once I switched, the designer started working properly, but the strange crashes started happening. I''m using version of the Suite, targeting version 1.1 of the framework. I''ve got a MainFrameBarManager, a OneLookTabbedMDIManager, a DockingManager with one docked GridControl, and a client MDI window containing a GridDataBoundGrid. It''s all managed code. At the moment, I''m just prototyping, so it''s entirely possible the problem will go away by itself. But if you know of a workaround... Thanks!

Administrator [Syncfusion]
Replied On May 7, 2004 01:31 PM

Hi TJ, Generally this might happen when the application is run for the very first time. This is because the framework does not find the appropriate file in the isolated storage (which is logical) and throws an exception (which is bad and unnecessary) but then it goes ahead and creates the appropriate file. The subsequent runs of the application will not have this problem. Also, this should happen only in Release mode. A good way to test this is to clear the isolated storage folder in the directory (C:\Documents and Settings\{user name}\Local Settings\Application Data\IsolatedStorage), then run the application in debug mode. I think you will see the exception, which you can safely ignore. If you clear the isolated storage and run the application in release mode, you should not see this problem. Please try this and let me know how it goes. We appreciate your cooperation, and thanks for considering Syncfusion products. Regards, Guru Patwal Syncfusion, Inc.

Administrator [Syncfusion]
Replied On May 7, 2004 02:36 PM

Hi. Unfortunately, it now crashes for me almost 100% of the time, and I''ve been running it many, many times in Debug mode. I tried Release mode as you suggested (after deleting the isolated storage folder), and I still get the crashes on exiting. That''s every time in Release mode, and every time pretty much in Debug mode too. It seems to successfully recreate the isolated storage file after I delete it, and the persistence feature seems to work just fine. In Debug mode, I usually get the .NET exception (which I''ve tried to catch and muffle, without success). If I say "continue", it proceeds into the hard exception I mentioned in the original post. In Release mode, it just goes directly to the hard exception - every time. Yikes. Thanks, Tom

Administrator [Syncfusion]
Replied On May 10, 2004 02:50 PM

Hi TJ, Please provide us with the following information : 1. Is it possible to recreate this crash using any of our samples shipped along with Essential Suite ? If not, could you please put together a sample that can recreate this crash consistently and send it to us so that we could further investigate this issue ? 2. The OS which you are using. We appreciate your cooperation. Regards, Guru Patwal Syncfusion, Inc.

Administrator [Syncfusion]
Replied On May 10, 2004 03:31 PM

Hmm. It seems to be related to System.Data.DataSet.ReadXml and/or attaching the resulting DataSet to the GDBG somehow. (This is something I''m doing for prototyping only, and won''t do in the final product). The last couple of days, I haven''t seen the problem at all, EXCEPT after feeding it invalid XML - at which point the system XML code throws an exception. If I let it continue after that, it gives me the now-familiar LocalDataStoreSlot exception. In other words, I''m no longer inclined to worry about it. But I''ll keep my eyes open for clues that would help me track it down further, and will let you know if I find anything. Cheers, Tom

Administrator [Syncfusion]
Replied On May 11, 2004 07:07 AM

Hi Tom, Thanks for the update. Please do let us know if you need any other information. We appreciate your continued interest in Syncfusion products. Regards, Guru Patwal Syncfusion, Inc.

Replied On May 25, 2004 09:41 AM

Hi, Guru. The problem is back (as described in my original post), but this time - since I''m now using the debug version of the libraries - I have a stack trace: [] BarItem.Dispose(bool disposing = true) Line 1601 ParentBarItem.Dispose(bool disposing = true) Line 3711 [] BarManager.Dispose(bool disposing = true) Line 3305 + 0x40 bytes MainFrameBarManager.Dispose(bool disposing = true) Line 443 [] MyApp.exe!MainForm.Dispose(bool disposing = false) Line 403 C# I no longer think the problem has anything to do with XML, as I''d indicated earlier. It seems to be triggered by various random events, and it doesn''t seem to be going away as my app evolves. I''m tempted to work around this by overriding MainFrameBarManager.Dispose and have the overridden version simply do nothing. However, as soon as I do that (as soon as I override ANY Designer-created class), the Designer no longer works with the class. Do you know of a workaround for THAT issue, perhaps? Let me know if you''d like me to send a stripped-down version of my app. Thanks again, Tom

Administrator [Syncfusion]
Replied On May 25, 2004 03:57 PM

Hi TJ, Thanks for the update and also for the stack trace. A sample that can recreate this issue consistently would be of great help here. I would appreciate if you could create an incident in DirectTrac in this regard, and send us a very basic (higly stripped down) version of your application showing this problem. We will then look into your code and update you with our inputs. We appreciate your cooperation, and thanks for choosing Syncfusion. Regards, Guru Patwal Syncfusion, Inc.

Administrator [Syncfusion]
Replied On December 3, 2004 12:06 AM

Hi I also get this Exception (0xc0020001) thrown at me nearly each time I exit my app. I can''t exactly pinpoint when this behaviour started, it really seems random. I load UserControls using reflection from assemblies on starting the app and found that if I load a lot of these controls (around 15) it seems to happen more then when I only load and use a single one. However, it also happens (after loading only a single one) when I fiddle a bit with with the XP Command Bars. Then exit app and bang! I also tried to trap this exception but without success. Any help or ideas much appreciated ! Marcel

Administrator [Syncfusion]
Replied On December 21, 2004 01:04 PM

Here''s the solution that worked for me - this is Guru''s response that I pulled out or Direc-Trac. Hi Tom, Thanks for the sample application. I have tested this here and could see the crash when the sample was closed. This was being caused by improper disposal of the Docking Manager and its associated controls. To workaround this add the following code snippet in the Closing event handler to explicitly dispose the Docking Manager and its associated controls : IEnumerator ienum = m_oDockingManager.Controls; ArrayList dockedctrls = new ArrayList(); while(ienum.MoveNext()) dockedctrls.Add(ienum.Current); foreach(Control ctrl in dockedctrls) { m_oDockingManager.SetEnableDocking(ctrl, false); ctrl.Dispose(); } m_oDockingManager.Dispose(); Regards, Guru Patwal

Beau Tateyama
Replied On March 7, 2005 06:46 PM

Hi, I''m also getting the occasional error on close (dialog) with code 0xc0020001. Did the docking mgr fix work for you? It helped to make the error dialog less frequent, but debugging with the "Debugging tools for Windows" (ADPlus), shows the error happening consistently on close. -beau


This post will be permanently deleted. Are you sure you want to continue?

Sorry, An error occured while processing your request. Please try again later.

You are using an outdated version of Internet Explorer that may not display all features of this and other websites. Upgrade to Internet Explorer 8 or newer for a better experience.