Application that uses WebBrowser control crashes after installing IE9

Question

I've installed IE 9 last week and since, my c# .net application crashes about 20% of times. The debugger is unable to show something useful besides stopping at Program.cs Application.Run(new MyMainForm()); , btw the main form was already shown, so it's not that it's something in construction on main form.

I have Windows7.

The exception thrown is: "An unhandled exception of type 'System.ArgumentException' occurred in System.Windows.Forms.dll  Additional information: Value does not fall within the expected range. 

Screen shot of callstack -> http://img861.imageshack.us/f/ie9v.png/

When running outside of debugger, this info is shown:

Problem signature:   Problem Event Name:   APPCRASH   Application Name: myexe.exe   Application Version:  6.7.6.0   Application Timestamp:    4d7fdffd   Fault Module Name:    mshtml.dll   Fault Module Version: 9.0.8112.16421   Fault Module Timestamp:   4d76266c   Exception Code:   c0000005   Exception Offset: 0012c848   OS Version:   6.1.7600.2.0.0.256.48   Locale ID:    1037  And sometimes instead of mshtml.dll it says StackHash_f09d  Problem Event Name: APPCRASH   Application Name: myexe.exe   Application Version:  6.7.6.0   Application Timestamp:    4d7fdffd   Fault Module Name:    StackHash_f09d   Fault Module Version: 0.0.0.0   Fault Module Timestamp:   00000000   Exception Code:   c0000005   Exception Offset: 00000000   OS Version:   6.1.7600.2.0.0.256.48   Locale ID:    1037 

Thanks in advance

Edited:

That's what I see in windbg, with symbols:

0:000> kb ChildEBP RetAddr  Args to Child               0020eda4 64d54f83 0566c988 00001012 00000000 mshtml!CDoc::ReduceMemoryPressureTask+0x1a 0020edb4 64d54f2c c6b991e4 0020ee78 00000113 mshtml!GWYieldToMsgOnCurrentThread+0x17b 0020edfc 770086ef 00192392 00000012 0000201b mshtml!GlobalWndProc+0x1f2 0020ee28 77008876 64d54afe 00192392 00000113 USER32!InternalCallWinProc+0x23 0020eea0 770089b5 00000000 64d54afe 00192392 USER32!UserCallWinProcCheckWow+0x14b 0020ef00 77008e9c 64d54afe 00000000 0020ef2c USER32!DispatchMessageWorker+0x35e 0020ef10 03b54726 0020ef9c fa69a961 00000000 USER32!DispatchMessageW+0xf *** WARNING: Unable to verify checksum for C:\Windows\assembly\NativeImages_v2.0.50727_32\System.Windows.Forms\f92c882fd4e7005c005e208daa04c28d\System.Windows.Forms.ni.dll WARNING: Frame IP not in any known module. Following frames may be wrong. 0020ef2c 5af78aee 01b743e4 00000001 01ac95cc 0x3b54726 0020efe0 5af78757 00000000 ffffffff 00000000 System_Windows_Forms_ni+0x208aee 0020f038 5af785a1 01b6c610 1f3a000e 00000000 System_Windows_Forms_ni+0x208757 0020f068 5af35911 01bb7d84 0020f10c 003b73d8 System_Windows_Forms_ni+0x2085a1 0020f0e0 6f221b5c 015b1141 00000001 0020f170 System_Windows_Forms_ni+0x1c5911 0020f0f0 6f232209 0020f1c0 00000000 0020f190 mscorwks!CallDescrWorker+0x33 0020f170 6f246511 0020f1c0 00000000 0020f190 mscorwks!CallDescrWorkerWithHandler+0xa3 0020f2b4 6f246544 0032c040 0020f380 0020f34c mscorwks!MethodDesc::CallDescr+0x19c 0020f2d0 6f246562 0032c040 0020f380 0020f34c mscorwks!MethodDesc::CallTargetWorker+0x1f 0020f2e8 6f2b0c45 0020f34c d847bc11 00000000 mscorwks!MethodDescCallSite::CallWithValueTypes+0x1a 0020f44c 6f2b0b65 003239c0 00000001 0020f488 mscorwks!ClassLoader::RunMain+0x223 0020f6b4 6f2b10b5 00000000 d847b3d9 00000001 mscorwks!Assembly::ExecuteMainMethod+0xa6 0020fb84 6f2b129f 013a0000 00000000 d847b389 mscorwks!SystemDomain::ExecuteMainMethod+0x456 

=====UPDATE(I'm not sure, if I'm supposed to post it as "Answer your question")============ Thanks to everyone trying to help, I appreciate it.

Being desperate, I started to remove pieces of code to understand which part of my code affects it(we use webrowser control in many forms). After removing call to LoginForm which also uses webrowser control, the problem disappeared.

The login form hosts webrowser control, it navigates to certain url, for example /login.php and if user is already logged-in, method UserLoggedIn inside form is invoked from html using ObjectForScripting. When UserLoggedIn was called, we were calling Close() to close form if the LoginForm was shown. Even though LoginForm was doing all this, we weren't always showing it. We were, showing it only if after X seconds UserLoggedIn() was not called(i.e user needs to login). For some reason, and thanks to MS for making us able to debug into .net sources, when we were calling Close, and the form was not Visible it was actually disposing the form and all it's children because IsHandleCreated was false. Now, the Close was called from UserLoggedIn(), which is an event fired by the browser control(the callstack shows ieframe.dll, mshtml.dll etc) , so the webbrowser object was being destoyed while being called from. The hacky way to resolve this, was to call Close, only if form was Visible. BTW, I don't know, why IsHandleCreated is false, if we don't show the form. I tried to reproduce it, by writing a sample that creates a form, which is not shown, but it's IsHandleCreated is true.

---- from Forms.cs -----

        public void Close()          {           if (GetState(STATE_CREATINGHANDLE))              throw new InvalidOperationException(SR.GetString(SR.ClosingWhileCreatingHandle, "Close"));          if (IsHandleCreated) {             closeReason = CloseReason.UserClosing;              SendMessage(NativeMethods.WM_CLOSE, 0, 0);         }          else{              // MSDN: When a form is closed, all resources created within the object are closed and the form is disposed.             // For MDI child: MdiChildren collection gets updated (VSWhidbey# 368642 & 93550)              Dispose(); // THIS WAS CALLED WHEN FORM WAS NOT VISIBLE         }     } 

Answer 1

Educated speculation to get you started- timers use thread pool threads, which are MTA. If I had to guess I'd say that it could be related to that, since activex controls can only be safely instantiated from STA threads. Perhaps try creating a thread manually rather than using the timer thread?