| Developers > System.ComponentModel.Win32Exception: Error creating window | ||
| pljones |  posted: Wed Aug 24, 2005 11:53 pm | |
 Member since: 2005-04-02 From: London, UK Posts: 610 | Hi! Any .Net / Windows developers (Quaxi? Emily?) know what can trigger this? I've heard that debugging stuff with threads in the message loop is a nightmare... so if anyone has any ideas, I'd be very grateful! The backtrace is: Message: SimPE will shut down due to an unhadled Exception. SimPE Version: Classic (0.45.2051.1662). Exception Stack: System.ComponentModel.Win32Exception: Error creating window handle. at System.Windows.Forms.NativeWindow.CreateHandle(CreateParams cp) at System.Windows.Forms.Control.CreateHandle() at System.Windows.Forms.Control.get_Handle() at System.Windows.Forms.Control.CreateGraphicsInternal() at System.Windows.Forms.ThreadExceptionDialog..ctor(Exception t) at System.Windows.Forms.ThreadExceptionDialog..ctor(Exception t) at System.Windows.Forms.ThreadContext.OnThreadException(Exception t) at System.Windows.Forms.Control.WndProcException(Exception e) at System.Windows.Forms.ControlNativeWindow.OnThreadException(Exception e) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg) at System.Windows.Forms.ComponentManager.System.Windows.Forms.UnsafeNativeMethods+IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData) at System.Windows.Forms.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context) at System.Windows.Forms.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context) at System.Windows.Forms.Application.Run(Form mainForm) at SimPe.Form1.Main(String[] args) Source: System.Windows.Forms Execution Stack: at System.Windows.Forms.NativeWindow.CreateHandle(CreateParams cp) at System.Windows.Forms.Control.CreateHandle() at System.Windows.Forms.Control.get_Handle() at System.Windows.Forms.Control.CreateGraphicsInternal() at System.Windows.Forms.ThreadExceptionDialog..ctor(Exception t) at System.Windows.Forms.ThreadExceptionDialog..ctor(Exception t) at System.Windows.Forms.ThreadContext.OnThreadException(Exception t) at System.Windows.Forms.Control.WndProcException(Exception e) at System.Windows.Forms.ControlNativeWindow.OnThreadException(Exception e) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg) at System.Windows.Forms.ComponentManager.System.Windows.Forms.UnsafeNativeMethods+IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData) at System.Windows.Forms.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context) at System.Windows.Forms.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context) at System.Windows.Forms.Application.Run(Form mainForm) at SimPe.Form1.Main(String[] args) The only bit of SimPe is that last line, so I'm pretty stuck for leads. Inge got this when using the pjse BHAV editor and has the impression the system was still "doing stuff" in the background while she was kicking off the next action. As if the system were struggling to acquire resources... From the backtrace, it appears there was an attempt to create (two constructors, .ctor) dialog boxes following an earlier thread exception. What I can't guess is what caused the thread exception (from the Windows native runtime?) or why the subsequent dialog creation might have failed. | |
| quaxi | posted: Thu Aug 25, 2005 12:41 am | |
 Member since: 2006-04-28 Posts: 3154 | On first glance this looks like a Thread did try to send a Message to a Control in another Context. Is you Version of the BHAV Plugin using Threads? Peronaly I know this Message for the usage of the EnableVisualStyles() Method, which is quite Buggy, and as cauing similar Errors for me. But I removed all calls to it, as it was crashing the GetGUID Dialog. Do you by any chance use a call to this Method (in the Application Class). The exceptions also occurs, when the application is violating memory/resource constraints in a very bad way, causing an Exception in the inner core of the Framework. Another Problem can be the installation of .NET SP. Look slike in some cases it breaks custom Controls compiled with .NET 1.1 (without SP1). Do you use compiled .dlls as references? I know that those are quite fuzzy Hints, but maybe they can help a bit. | |
| Inge Jones | posted: Thu Aug 25, 2005 9:52 am | |
 Member since: 2005-03-06 Posts: 1899 | That's the same one that SnowStorm had in the QA thread | |
| pljones | posted: Thu Aug 25, 2005 9:53 am | |
Member since: 2005-04-02 From: London, UK Posts: 610 | Thanks for the ideas. I don't think I'm calling EnableVisualStyles() directly. The other two points I'll have to think about: I'm not intentionally doing either! | |
| Inge Jones | posted: Thu Aug 25, 2005 10:05 am | |
Member since: 2005-03-06 Posts: 1899 | I'm sure it's a memory resource thing, cos doing something when I have been working a while can cause a crash where doing the same thing when SimPe has only been open a short time will work perfectly. | |
| quaxi | posted: Thu Aug 25, 2005 3:59 pm | |
Member since: 2006-04-28 Posts: 3154 | I did some testing, and the good news is, that I was able to reproduce the Exception, by opening about 100 diffrent PluginViews in a row. So my guessat the Moment is, that the Controls do not get disposed correct, which might mean. that I have to change the Plugin Interface again. | |
| pljones | posted: Thu Aug 25, 2005 4:05 pm | |
Member since: 2005-04-02 From: London, UK Posts: 610 | Good news! I'm really glad you managed to reproduce it -- I wouldn't have liked to try..! (Just in case you missed it and it makes any difference, Inge was using the Classic UI whilst SnowStorm was using the Default UI.) | |
| quaxi | posted: Thu Aug 25, 2005 4:28 pm | |
Member since: 2006-04-28 Posts: 3154 | Yes, I noticed that, which is kind of strange. Since the classig GUI should only create one Windowhandle per wrapper. | |
| quaxi | posted: Thu Aug 25, 2005 5:31 pm | |
Member since: 2006-04-28 Posts: 3154 | I think i was able to Fix this Problem. However, the Plugin Interface was changed, so you have to recompile our Plugins. I just commited the fixed Version to the CVS Repository. Basically the only thing you have to do, is implement a public void Dispose(); Method for classes that derive from SimPe.Interfaces.Plugin.IPackedFileUI. Therein you should manually Dispose the instances to the created Forms, as the Garbage collector seems to have Problems doing this automatically. | |
| pljones | posted: Thu Aug 25, 2005 8:32 pm | |
Member since: 2005-04-02 From: London, UK Posts: 610 | The change (in PackedFileUI.cs, at least) looks like this: #region IDisposable Member public virtual void Dispose() { this.form.Dispose(); } #endregion If I've instantiated another Wrapper (say, to access a String Resource or when doing the OpCode chooser lookup), do I need to do anything extra? What about forms I've popped up (again, the OpCode chooser springs to mind)? Do they need to implement the interface, too? | |
viewthread, 0, 0, SystemComponentModelWin32Exception-Error-creating-window