HELP!!! Random exceptions

[Guest]

I get "object reference not set to an instance of an object" exception thrown
at seemingly random places in my app. This stack trace doesn't show where
this ties back to my code. Can someone point me in the right direction?
Also, what exactly is a Parking Window?

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)

 

[Tom Krueger [MSFT]]

Hello,

You will get the error message "Object reference not set to an instance of
an object" when trying to access an object that is still null. For instance
if obj is null or undefined and you try to execute obj.Method() this error
will occur. A slightly more difficult scenario to find is something like
(employee.Address.Street). Here the employee may be instantiated, however,
the Address object may not, resulting in the error.

Try out the following, this should help you at least locate the problem
areas.

Go to Debug Menu | Exceptions
Select Common Language Runtime
Choose the option Break Into Debugger
Run your application in debug mode.

Now when this exception occurs you should break at the point it occured
instead of being thrown up to the next handler. You should be able to hover
over the object variables and see that one of them is undefined. You will
then have to figure out why the object is not being instantiated. You can
also check by using if (obj != null) { do something }

(Note: if you are multi-threading make sure you are on the expected thread
when the error occurs. You can do this by printing out a line with the
threads name.)

Tom

Smart Client DevCenter - http://msdn.microsoft.com/smartclient/
Mobile DevCenter - http://msdn.microsoft.com/smartclient/

This posting is provided "as is" with no warranties and confers no rights.

 

[Guest]

Tom, thanks for the reply. The bigger problem here is that there is no
source code available when this exception is raised, so I can't identify the
offending object. Got any ideas how to trace back to something meaningful?

 

[Andrew Smith \(Infragistics\)]

If I could hazard a guess, I would suspect that you are dealing with
multiple threads either directly or indirectly (using Thread class,
System.Threading.Timer, System.Timers.Timer, BeginInvoke of a delegate
instance, etc.) and not properly marshalling calls that interact with the ui
thread (controls or any classes used by controls including any datasources,
etc. to which they are bound). Make sure that any activity that is
interacting with the ui thread is marshalling that activity to the ui thread
(using Invoke/BeginInvoke of a control on the ui thread). You can use the
InvokeRequired to test whether you're dealing with the control from a
different thread.

 

[Guest]

This does look like a threading exception, but there is only 1 thread.

 

[Guest]

To anyone experiencing excptions that they cannot explain:

I installed the .NET Framework 2.0 beta out of curiosity and I got this
completely different (but far more informative) stack trace

** Stack Trace Using .NET Framework v2.0beta **

Object reference not set to an instance of an object.
System.Windows.Forms
at System.Windows.Forms.StatusBar.UpdateTooltip(StatusBarPanel panel)
at System.Windows.Forms.StatusBarPanelCollection.RemoveAt(Int32 index)
at System.Windows.Forms.StatusBarPanel.Dispose(Boolean disposing)
at System.ComponentModel.Component.Dispose()


From this I discovered that the Tooltip for a StatusBarPanel was to blame
for the previously un-trace-able exception. Anyway, this just proves that
the Framework has more maturing to do than I had hoped