Null Reference Exception after Forms.TabPageCollection.Remove() ca

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I am developing a Windows Forms based application using VS 2003 in C#. An
exception is being hit very rarely during acceptance testing.

Is this a known defect?
Is there a workaround?
Is it corrected in .NET 2.0?

Problem: Very intermittent Null Reference Exception deep in Windows code
after calling 'Forms.TabPageCollection.Remove' method

Details:
- Always occurs with stack frames mentioning "ParkingWindow" on the
backtrace (see following).
- Has been seen originating with Controls.Clear() method as well.
- The same code path gets executed a great number of times without
problems. Only very rarely does an exception get thrown. Given the
difficulting in repeating the problem not much more is known about the
circumstances.

Stack Backtrace:
Additional Info: System.NullReferenceException: Object reference not set to
an instance of an object.
at System.Windows.Forms.WndProc.Invoke(IntPtr hWnd, Int32 msg, IntPtr
wParam, IntPtr lParam)
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)
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.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)
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.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.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)
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.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.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)
at System.Windows.Forms.UnsafeNativeMethods.SendMessage(HandleRef hWnd,
Int32 msg, Int32 wParam, Int32 lParam)
at System.Windows.Forms.Control.SendMessage(Int32 msg, Int32 wparam,
Int32 lparam)
at System.Windows.Forms.Control.WmCreate(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.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)
at System.Windows.Forms.UnsafeNativeMethods.IntCreateWindowEx(Int32
dwExStyle, String lpszClassName, String lpszWindowName, Int32 style, Int32 x,
Int32 y, Int32 width, Int32 height, HandleRef hWndParent, HandleRef hMenu,
HandleRef hInst, Object pvParam)
at System.Windows.Forms.UnsafeNativeMethods.CreateWindowEx(Int32
dwExStyle, String lpszClassName, String lpszWindowName, Int32 style, Int32 x,
Int32 y, Int32 width, Int32 height, HandleRef hWndParent, HandleRef hMenu,
HandleRef hInst, Object pvParam)
at System.Windows.Forms.NativeWindow.CreateHandle(CreateParams cp)
at System.Windows.Forms.Control.CreateHandle()
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl()
at System.Windows.Forms.Control.OnVisibleChanged(EventArgs e)
at System.Windows.Forms.ScrollableControl.OnVisibleChanged(EventArgs e)
at System.Windows.Forms.Control.OnParentVisibleChanged(EventArgs e)
at System.Windows.Forms.Control.OnVisibleChanged(EventArgs e)
at System.Windows.Forms.ScrollableControl.OnVisibleChanged(EventArgs e)
at System.Windows.Forms.Control.OnParentVisibleChanged(EventArgs e)
at System.Windows.Forms.Control.OnVisibleChanged(EventArgs e)
at System.Windows.Forms.ScrollableControl.OnVisibleChanged(EventArgs e)
at System.Windows.Forms.Control.AssignParent(Control value)
at System.Windows.Forms.TabPage.AssignParent(Control value)
at System.Windows.Forms.ControlCollection.Remove(Control value)
at System.Windows.Forms.ControlCollection.Remove(Control value)
at System.Windows.Forms.TabPageCollection.Remove(TabPage value)
at <our application code>

Possible reference found in Google search:
- Webpage "Derived combo box controls in forms - MessageBox.Show breaks
the control's message routing" indicates that derived ComboBox controls might
be involved - that is possible in our situation. See
http://www.tech-archive.net/Archive...otnet.languages.vb.controls/2004-05/0170.html

Thanks in advance for your assistance,
Dave
 
Hi Dave,

I am sorry that I may not understand your scenario exactly. I have several
questions here.

1. I know that your program is written in VS.NET 2003 wih C#. But you have
mentioned a reference you found in Google search, which talks about using
C# form in an MFC application. Is your program related to MFC?

2. You have mentioned the exception is raised after the call to
'System.Windows.Forms.TabPageCollection.Remove(TabPage value)'. Does the
form has a TabControl on it? Could you please tell me what controls reside
on the form and what operations you perform on the form before you
encounter the exception?

3. Since the exception is very intermittent, is it possible that the
exception is caused by other reasons, instead of the operation of deleting
a tab page from the TabControl? For example, when the user deletes a tab
page from the TabControl, the application receives a message and tries to
access the controls on the deleted tab page.


Sincerely,
Linda Liu
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Dave,

The phrase "parking window" and seeing CreateHandle in the stack gives me
some ideas which may begin to help. I had a vaguely similar sort of problem
a couple of years back which took me about 3 weeks to track down, eventually
discovering a .NET 1.1 bug. There are certain scenarios in which a control
on a form can be created with a temporary parent window called the "parking
window", and in theory it gets reparented to the form later on. However
there are certain circumstances in which it doesn't happen correctly, and
control messages are still getting routed through this parking window.
Furthermore there are some situations in which the parking window gets
destroyed (in our case it was simply invoking a message box), and then the
next time messages get sent to the control (and thus via the
no-longer-existing parking window) it goes bang. I'll bet that something
similar is going on with you. Do a search on "parking window" in
microsoft.public.dotnet.framework.windowsforms and you'll see some of my
postings on that issue and the workaround. (It's fixed in 2.0.)
 
I just noticed that the newsgroup search result you had was one of my
earlier postings on the issue before finding the cause and workaround. As I
said, if you look in the windowsforms newsgroups you should find postings on
the results of my investigations and the workaround.
 
Linda,

In answer to your questions:

1. No, we are not using MFC, just .NET 1.1, C# and VS 2003. The reference
is just one of many that can be found using a Google search on the keyword
"ParkingWindow" and "exception". Note that Clive Dixon also replied to my
post and has seen this problem as well.

2. Yes, the Form has a TabControl on it, which is why a tab page was being
removed. The tab pages are added and removed from the TabControl depending
on the user request. The tab pages contain a variety of controls. The type
of controls on the tab pages are a mix of standard Label controls and
controls derived from TextBox, ComboBox and ListView. I should also point
out that we have also seen this problem recently where the stack backtrace
does not include a reference to a TabControl.

3. Yes, it is possible, but it seems unlikely since the stack backtrace
leaves our code and enters the MS code at the Remove call and proceeds to the
point of the null reference exception.

If you would do some research you will find that this problem manifests
itself in several ways, but always seems to involve the ParkingWindow.
Several people have posted queries to different sites related to this issue.

We are attempting to find a way to reliably reproduce the problem, but I
don't hold out much hope of that given other people's experiences.

So again, is this a known problem?
Is it always related to the ParkingWindow?
Is there a work-around?
Does .NET 2.0 resolve the issue?

Thanks,
Dave
 
Hi Dave,

Thank you for your prompt response and detailed explanation.

I have searched our inner data base and found a similar case in it. This
case is solved by the hotfix 893005. You may visit the following link for
the corresponding KB article:

http://support.microsoft.com/default.aspx?scid=kb;en-us;893005

To resolve this problem immediately, contact Microsoft Product Support
Services to obtain the hotfix. For a complete list of Microsoft Product
Support Services telephone numbers and information about support costs,
visit the following Microsoft Web site:

http://support.microsoft.com/contactus/?ws=support

Hope this helps.


Sincerely,
Linda Liu
Microsoft Online Community Support
 
Linda,

The hotfix below does not apply to our situation. The hotfix deals with a
situation where a form containing either a ToolTip or ErrorProvider control
is closed and recreated. We do not use the ErrorProvider control at all and
only one form in the entire program uses the ToolTip control and it is not
closed until the program is exited.

We see the NullReference exception usually following a container control
clearing its list using the method ControlCollection.Remove() or
ControlCollection.Clear().

Is there any item in your inner data base or KB that deals with a
NullReference exception or Unhandled exception related to the combination of
clearing a ControlCollection? How about exceptions related to the occurance
of a ParkingWindow in the stack back trace?

Dave
 
Clive,

In one of your postings you said that you think this problem has been fixed
in .NET 2.0. How did you determine this? Did Microsoft acknowledge the
problem and state that it had been fixed? Was there a Knowledge Base article
produced?

Thanks for any information you can provide.

Dave
--
Dave Leach
Agilent Technologies, Inc.


Clive Dixon said:
I just noticed that the newsgroup search result you had was one of my
earlier postings on the issue before finding the cause and workaround. As I
said, if you look in the windowsforms newsgroups you should find postings on
the results of my investigations and the workaround.
Click to expand...
 
Clive,

I forgot to mention that I searched for your posting and could not find it.
However, I did find postings to other sites by using Google.

Has it aged off the MSDN newsgroup system? Maybe there is another search
method I am unaware of. Can you still find the posting and if so how?

Thanks,
Dave

--
Dave Leach
Agilent Technologies, Inc.


Clive Dixon said:
I just noticed that the newsgroup search result you had was one of my
earlier postings on the issue before finding the cause and workaround. As I
said, if you look in the windowsforms newsgroups you should find postings on
the results of my investigations and the workaround.
Click to expand...
 
Hi Dave,

Thank you for your prompt response.

Sorry that I didn't clarify in my previous reply.

The KB 893005 was addressing a case whose scenario was different from
yours, but with similar symptoms(the call stack of this case when the
exception occurs is the same as your program's).

In that case, an object which is subclassed by the ToolTip can throw an
exception if an error occurs while unsubclassing the control. The Framework
wouldn't detect this situation correctly and could free the subclass
procedure's memory while it was still set to be the control's window
procedure.

In addition, there're several cases recorded in our inner data base, whose
scenarios are different, but with the similar symptoms as your program.
They were all solved by the hotfix 893005.

Please give hotfix 893005 a try and let me know if it works.

Sincerely,
Linda Liu
Microsoft Online Community Support
 
Dave,
Have you had any success with the below mentioned hotfix? I'm seeing the
same stack trace (or at least a subset of it) resulting in either a
NullReferenceException or in at least one case, an SEHException. Likewise,
we're doing a lot of clearing of controls and think that is likely part of it.

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)

Mike Mayer,
Autonomy etalk
 
Back
Top