IE9 iFrame crashing after applying KB3008923 (MS14-080)

Exact same thing is happening to us today for multiple users with IE9 and that did their updates last night/this AM.

Machines that haven’t applied the update yet, and ones running IE11, are not having this problem.

I'm not sure it's related to iFrame elements specifically as the suspect web sites our users have had open when it happens contain no iFrames (ieframe.dll =/= iFrame html element ;) ).

Found this article that mentions the problem:

http://windowsitpro.com/windows-update/tracking-decembers-updates-update-kb3008923-crashing-ie9-other-issues-reported

That article has an update that seems to claim this is related(?):

https://connect.microsoft.com/IE/Feedback/Details/1051452

Another:

https://connect.microsoft.com/IE/Feedback/Details/1052383

We too were affected by this issue. Uninstalling the KB3008923 fixed the issue.

With KB3008923 installed on our Windows 2008 R2 SP1 Remote Dektop servers with IE9, the browser will crash and quietly close for users after a period of time up to 30 minutes.

The following was presented in the application log on ther Remote Dektop servers-

Log Name:      Application
Source:        Application Error
Date:          12/12/2014 5:01:09 PM
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      nausicaa.pncs.com.au
Description:
Faulting application name: iexplore.exe, version: 9.0.8112.16599, time stamp: 0x5473964b
Faulting module name: IEFRAME.dll, version: 9.0.8112.16599, time stamp: 0x547396ec
Exception code: 0xc0000005
Fault offset: 0x001a8290
Faulting process id: 0x6f20
Faulting application start time: 0x01d015e8cd3ef159
Faulting application path: C:\Program Files (x86)\Internet Explorer\iexplore.exe
Faulting module path: C:\Windows\system32\IEFRAME.dll
Report Id: 698f2921-81dd-11e4-9db7-40f2e9242b1a

We too have this little Gem today.

I pushed it out with WSUS last night and today all hell broke loose with support tickets coming in from most users.

In the process of removing it now.

We also see this exact same error in IE9 after deploying the update to some of our users. It seems to happen a lot on specific sites we have like Sharepoint 2013 pages and som of our intranet pages. It is likely triggered by some specific content on the pages.

Anyway our event logs look like this:

Faulting application name: iexplore.exe, version: 9.0.8112.16599, time stamp: 0x5473964b

Faulting module name: IEFRAME.dll, version: 9.0.8112.16599, time stamp: 0x547396ec

Exception code: 0xc0000005

Fault offset: 0x001a8290

Faulting process id: 0x1dcc

Faulting application start time: 0x01d0186ea4aa3cf1

Faulting application path: C:\Program Files (x86)\Internet Explorer\iexplore.exe

Faulting module path: C:\Windows\system32\IEFRAME.dll

Report Id: e43bf29e-8461-11e4-9f0f-00059a3c7a00

likely triggered by some specific content on the pages.

If it is reproducible you could use the Developer Tools to try to isolate a cause.  Alternatively, have you looked at a dump for clues in the Stack Back Trace?  E.g. ieframe.dll may only be a victim, not the culprit.

BTW on the WindowsITPro page someone mentioned finding that running in 64-bit mode to be a workaround.  Does that help you too?  If so, try using Enhanced Protected Mode.

HTH

Robert Aldwinckle
---

We have not been able to reproduce the error on a specific page or site, but it does happen more frequently for users using specific sites after the update.

We have had to pull the update from our update cycle as the reports have been numerous and it is disruptive for our users. We don't want IE to crash frequently on 40k computers, then we would be overrun with complaints. Also this is the 3rd update this month that is causing us major pain, especially bad for end of year i my line of work.

Also using 64 bit is not a possibility for all our users as many internal web based applications don't work because of plugins not being 64 bit yet.

But anyway we have pulled the update and are expecting Microsoft to provide a revised update for this.

 are expecting Microsoft to provide a revised update for this.

If you haven't given them any details what would they revise?  Was the SQM enabled at least?  If so, I suppose they will have a Stack Back Trace (and more) to look at.

 

Good luck

Robert
---

If you haven't given them any details what would they revise?  Was the SQM enabled at least?  If so, I suppose they will have a Stack Back Trace (and more) to look at.

I'll bite... What's an "SQM", and how would we enable it?

I'm seeing the same thing.  IE9 crashes, uninstalled KB3008923, all back to normal.  That's well and good, but then we're without the security the patch uses.  I'm going to try 'manually' downloading and installing the patch file.  I've opened a case with SA.

Crash in IEFRAME fully reproducible: launch IE9, and Visual Studio 2010, then try to debug IE with "Attach to process" (choose the iexplore.exe process which manage the tab, not the main one)