intermittent NullReferenceException: Object reference not set

[Guest]

hello,

I have an application that somethimes throws this exception in different
windows forms, if I rerun the application all is 'ok' and the error
disappears.
the stack trace is the same on different windows forms.
any ideas ?
thank's

this is the exception:
NullReferenceException: Object reference not set to an instance of an object
with this stack trace:
at System.Windows.Forms.UnsafeNativeMethods.CallWindowProc(IntPtr
wndProc, IntPtr hWnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at System.Windows.Forms.NativeWindow.DefWndProc(Message& m)
at System.Windows.Forms.Control.DefWndProc(Message& m)
at System.Windows.Forms.Control.WmUpdateUIState(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.ParkingWindow.WndProc(Message& m)
at System.Windows.Forms.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg,
IntPtr wparam, IntPtr lparam)

 

[Stoitcho Goutsev \(100\)]

Hi,

Even though there is no code that probably you have written in this stack
trace I believe the problems is in the code you wrote rather than in the
framework. Unless you create a simple compilable sample that demonstrates
the problem I don't think anyone will be able to help.

 

[Clive Dixon]

The name "ParkingWindow" in the stack trace rings alaram bells to me. Are
you using framework 1.1 or 2.0?

======================
Clive Dixon
Digita Ltd. (www.digita.com)

 

[Clive Dixon]

I'll add to my previous post now as I'm going to be on holiday for the next
10 days.

A couple of years ago I discovered a bug in framework 1.1. In certain
circumstances, where a child control is created before the parent window's
handle has been created, the child control is given a temporary parent
called the "parking window", of which there is at most one instance per
application domain. In theory the child window should be subsequently
re-parented when the parent does get created and everything should be fine
and dandy thereafter. However there are certain circumstances where it
doesn't work correctly. The particular circumstance I found involved
owner-draw controls and showing message boxes. Setting certain properties on
child owner draw controls in InitializeComponent caused the controls'
handles to be created, before the parent control handle had been created.
The message routing didn't get corrected with the re-parenting and ends up
still trying to go through the parking window. On top of this, showing a
message box blows away the parking window. Result - after a message box,
next time the owner draw control tries to process an owner draw message,
bang!

If you are running 1.1, the presence of ParkingWindow in the windows message
routing in your stack trace suggests to me that you might possibly have a
similar problem. I give below a link which includes my posting on the
subject a couple of years back, and my workaround for the problem. Hope it's
useful.

The problem (or at least the particular circumstance I found) has been fixed
in 2.0, though this may still be an area worth investigating if you are
running 2.0.

http://groups.google.co.uk/group/mi...public.dotnet.*&rnum=1&hl=en#f9b737171aca1a48

======================
Clive Dixon
Digita Ltd. (www.digita.com)