Here's the scenario - You have a form (StartForm) which has a sub-form (subForm) that contains a WebBrowser control. When the sub-form is disposed (not just dismissed), your startform also shuts down. This is a bug !

This occurs because the Web browser control does a PostQuitMessage() upon receiving a WM_CLOSE message. Now the tricky bit over here is that a PostQuitMessage is not a real message that is inserted into the thread's message queue. Its a virtual message that will be presented to whoever cares once all messages in the queue are processed. What this means to us is that since the control is calling PostQuitMessage, we do not have a deterministic point to handle this message.

However, the workaround options are

1. Don't shut the sub-form: In the code below, if you can eliminate "suForm.Dispose()" , then you don't have an issue. However, your application design may not allow this workaround.in which case, do option
2. Handle the message pump in the StartForm by creating a message loop that exits on seeing the WM_QUIT event.

Lazy pseudo code -

SubForm subForm = new SubForm();
subForm.ShowDialog();
subForm.Dispose();  //this is the line that causes the WebBrowser to PostQuitMessage

PostQuitMessage(0); // This is to handle the future where the quit message may not be posted by the native control

//message loop that will stop once WM_QUIT (0) is presented to it

MSG msg;// Native structure coredll.dll
while (GetMessage(out msg, new IntPtr(0), 0, 0) != 0)
{
TranslateMessage(ref msg); // Native function coredll.dll
DispatchMessage(ref msg);// Native function coredll.dll
}