Hi Richard, Thanks for the reply. The reason is not the one which is seen at upper level.(Object not set to an instance of an object) This is caused due to Application.ThreadContext.OnThreadException. Here I am not able to get the reason for Application.ThreadContext.OnThreadException. If you see the detailed log, there we can ,after NativeWindow.Callback this exception is raised inside System.Windows.Forms.dll. Why the dll has raised an exception? My point of view, This can not be becasue of third party tool. Reason : Again we can look into the StackTrace where the exception is raised by System.Windows.forms.dll and third party tool is just passing comand to WM_ExitSizeMove and leaving the handle to windows. I need to know Why this exception is raised.

Hi all, I am developing a winform application.This application has several (approx. 45) windows with custom rendering on it. I am also using a third party tool for docking and undocking these windows. When I play with all these windows (like docking undocking and moving them from thier location etc) very rarely I face this issue of an 'Application.OnThreadException'. The custom rendering of all windows is heavy process. Following A) is Exception and B) is the Stack trace I got once the exception has occured. This issue is very hard to reproduce but it is there for sure. Could you please guide me regarding any possible reason for the same? Thanks in advance! A) ---Exception Message --- Object reference not set to an instance of an object. B) ----Stack Trace--- System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.OnThreadException(System.Exception t) + 0x8b bytes System.Windows.Forms.dll!System.Windows.Forms.Control.WndProcException(System.Exception e) + 0x16 bytes System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.OnThreadException(System.Exception e) + 0xc bytes System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.Callback(System.IntPtr hWnd, int msg = 562, System.IntPtr wparam, System.IntPtr lparam) + 0x72 bytes System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DefWndProc(ref System.Windows.Forms.Message m = {msg=0x232 (WM_EXITSIZEMOVE) hwnd=0xa0cbc wparam=0x0 lparam=0x0 result=0x0}) + 0x130 bytes System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.WndProc(ref System.Windows.Forms.Message m) + 0x5 bytes Syncfusion.Tools.Windows.dll!Syncfusion.Windows.Forms.Tools.NotifyNativeWindow.WndProc(ref System.Windows.Forms.Message m = {msg=0x232 (WM_EXITSIZEMOVE) hwnd=0xa0cbc wparam=0x0 lparam=0x0 result=0x0}) + 0xb3 bytes System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DebuggableCallback(System.IntPtr hWnd, int msg = 562, System.IntPtr wparam, System.IntPtr lparam) + 0x57 bytes [Native to Managed Transition] System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DefWndProc(ref System.Windows.Forms.Message m = {msg=0x112 (WM_SYSCOMMAND) hwnd=0xa0cbc wparam=0xf012 lparam=0x10f0494 result=0x0}) + 0x93 bytes System.Windows.Forms.dll!System.Windows.Forms.Form.DefWndProc(ref System.Windows.Forms.Message m) + 0x89 bytes System.Windows.Forms.dll!System.Windows.Forms.Control.WndProc(ref System.Windows.Forms.Message m) + 0x40a bytes System.Windows.Forms.dll!System.Windows.Forms.

Regarding Geneneric list as return type : If you send/return the generic list outside, your collection can be very easily changed from outside of your class without your permission and you lose total control on the same. that is why , one should not expose or return generic list and use ReadOnlyCollection instead. Dot net does not force you to do so but generally its not good programming practice! Regarding point 2 : Here also, A ReadOnlyCollection is recommanded. Regarding point 3 : You can create your customDictionary in which you can maintain and return the colelction of keys and/or collection of values as per request.