LocalDataStoreSlot exception using XPMenus

[Administrator]

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 2.0.5.0 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]

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]

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]

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]

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]

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.

[TJ]

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]

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]

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]

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]

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