IE 8.0.6001.18702 Unmanaged exception on MSHTML.DLL (innerHTML)

Question

• We have an unmanaged exception on MSHTML.DLL - possbly caused by changing the innerHTML property.

IMPORTANT - There is no user friendly error returned from IE8!

The crash only happens in XP and Vista using IE version 8.0.6001.18702.

It is the client IE8 browser that crashes.

We have a full system dump at point of first exception (191Mb) is this is useful?

We can also provide a complete VM machine (several Gb) showing this crash if this is useful?

We can crash consistently using our large flagship / complete system but do not have a smaller test harness / test case at this point in time.  To help us write a small test case we would need you to provide a consise list of possible test case/scenarios so we can focus efforts on creating a small test case for you.

Because this is an unmanaged crash we suspect this is the interaction with the innerHTML property of some html objects (divs mainly).  It *could* be a slightly malformed html (by slightly we mean possibly a unusual unicode character here).  It could also be a change to the innerHTML of a object when its hidden away or something.

It is also worth noting that this unmanaged crash does not happen straight away - the object can get its innerHTML changed to blank ("") several times and even get some valid html in it before finally crashing.
Jason Jackson
Friday, January 15, 2010 8:21 PM

All replies

• A full system dump is useful, a mini-dump would be easier (you should see a path to it in the expanded report a problem dialog) :), if you have an isolated repro case that can be ran without much setup that would be even better.

Also, this forum isn't an official support channel so any help is "as-is" and best effort, for official support try: https://support.microsoft.com/oas/default.aspx?ln=en-us&x=9&y=4&gprid=13418&&st=1 (for en-US).
Friday, January 15, 2010 10:43 PM
• Hi,

Is your markup validated? (probably not...)

Does your site use DOM manipulation scripts to create or remove elements like stylesheet links. These will not be picked up by the markup validators, but....

Illegal external stylesheet links within the body block are known to make IE8 browsers choke (see connect.microsoft.com for listing of known outstanding issues). An unhandled exception in mshtml indicates junk code that IE8 error detection is not correcting/detecting and exiting gracefully.

Tools>Internet Options - Advanced tab - "Automatic crash recovery" turned on? (applies LCIE error trapping, realy only applies to misbehaving Addons, but an addon may be injecting malformed illegal markup).

When debugging your markup and layout, turn off "Automatically recover from rendering errors with Compatibility View" to capture Rendering Mode fallbacks.

In Vista, Start>Control Panel>Problem Reports and Solutions gives you additional details about IE crashes.

I haven't seen an IEAddon cause a mshtml error but it would not  hurt (no you should always) test your sites in IE noAddons mode also to rule out markup injected by things like formfillers or Site Ratings addons like Site Advisor and WOT.
Rob^_^
Saturday, January 16, 2010 7:39 AM
• The problem does take place during DOM manipulation - we can repeat the problem within the web app simply looping setting inneHTML to something like '<a href="#">foo</a>' - however if we extract and run external to app it doesn't seem to fail.

Problem signature:
Problem Event Name: APPCRASH
Application Name: iexplore.exe
Application Version: 8.0.6001.18865
Application Timestamp: 4b0775a2
Fault Module Name: mshtml.dll
Fault Module Version: 8.0.6001.18865
Fault Module Timestamp: 4b078d64
Exception Code: c00000fd
Exception Offset: 0000000000170444
OS Version: 6.0.6002.2.2.0.16.7
Locale ID: 1033

And here is the top part of of stack trace and disassembly for what it is worth

> mshtml.dll!000007fef24f0444()
[Frames below may be incorrect and/or missing, no symbols loaded for mshtml.dll]
mshtml.dll!000007fef2835cff()
mshtml.dll!000007fef283ea3d()
mshtml.dll!000007fef2463deb()
mshtml.dll!000007fef2463bed()
mshtml.dll!000007fef24614e0()
mshtml.dll!000007fef23deb44()
mshtml.dll!000007fef279b07e()
mshtml.dll!000007fef26072c6()
mshtml.dll!000007fef26070c5()
mshtml.dll!000007fef24f4bf7()
mshtml.dll!000007fef2498ba8()
mshtml.dll!000007fef26071f5()
mshtml.dll!000007fef25f9b93()
mshtml.dll!000007fef279b118()
mshtml.dll!000007fef26072c6()
mshtml.dll!000007fef260738b()
mshtml.dll!000007fef26072d6()
mshtml.dll!000007fef260738b()
mshtml.dll!000007fef26072d6()

000007FEF24F041F  nop
000007FEF24F0420  mov         r11,rcx
000007FEF24F0423  mov         word ptr [rcx+3Ch],0C7h
000007FEF24F0429  mov         rax,qword ptr [rcx+20h]
000007FEF24F042D  mov         rcx,qword ptr [rcx+18h]
000007FEF24F0431  jmp         qword ptr [rax+638h]
000007FEF24F0437  and         r10w,0F000h
000007FEF24F043D  lea         r11,[r11-1000h]
> 000007FEF24F0444  mov         byte ptr [r11],0
000007FEF24F0448  cmp         r10,r11
000007FEF24F044B  je          000007FEF24C647E
000007FEF24F0451  jmp         000007FEF24F043D
000007FEF24F0453  nop
000007FEF24F0454  nop
000007FE
Saturday, January 16, 2010 8:46 AM
• Should also add that this is code that has worked for years until recent IE patch KB976325.
Saturday, January 16, 2010 8:56 AM
• According to the results from http://www.google.com/search?q=KB976325

that patch addresses a security vulnerability, details of which are undisclosed for obvious reasons.

Running your production environment in No-Addons mode is a test that you should definately undertake.

Obviously also your production and testing IE settings are different. In both cases you should be testing with the same User privelages and your IE Security Zone settings should be set to the default settings for each zone.

If you can't reproduce the issue in production when running IE in no-Addons mode then it may be one of your installed ActiveX controls that has a version issue. Compare these in your production and testing environment by loading the IE Addons Manager and selecting the Downloaded Controls view and then double clicking (on Adobe/Shockwave flash... maybe) controls to view their properties.

Assuming also that both production and testing environments have had the same (complete) Windows Update history.

If you are hosting pdf downloads from your production site then that is another avenue to persue.

Web search for PDF vulnerabilities

Regards.
Rob^_^
Saturday, January 16, 2010 9:19 AM
• The dev and production environments are the same browser - difference is that when I plug test page into app it is running inside frameset and iframes..  I got symbols downloaded today - top of which is below.

> mshtml.dll!__chkstk()  + 0x29ff4 bytes
mshtml.dll!CFrameSite::Save()  + 0xf bytes
mshtml.dll!CIFrameElement::Save()  + 0x1d bytes
mshtml.dll!CTreeSaver::SaveElement()  + 0x7b bytes
mshtml.dll!CTreeSaver::Save()  + 0x254d bytes
mshtml.dll!CElement::GetText()  + 0xe0 bytes
mshtml.dll!CElement::get_innerText()  + 0x14 bytes
mshtml.dll!CMarkup::DetachElemCtxStream()  + 0x75 bytes
mshtml.dll!CAPProcessor::Evaluate()  + 0x5c027 bytes
mshtml.dll!CDoc::SubmitForAntiPhishProcessing()  + 0x168 bytes
mshtml.dll!CMarkup::CheckCtxInfoThreshold()  + 0x65 bytes
mshtml.dll!CMarkup::DetachElemCtxStream()  + 0x75 bytes
mshtml.dll!CAPProcessor::Evaluate()  + 0x5c027 bytes
mshtml.dll!CDoc::SubmitForAntiPhishProcessing()  + 0x168 bytes
mshtml.dll!CMarkup::CheckCtxInfoThreshold()  + 0x65 bytes
mshtml.dll!CMarkup::DetachElemCtxStream()  + 0x75 bytes
mshtml.dll!CAPProcessor::Evaluate()  + 0x5c027 bytes
mshtml.dll!CDoc::SubmitForAntiPhishProcessing()  + 0x168 bytes
mshtml.dll!CMarkup::CheckCtxInfoThreshold()  + 0x65 bytes
mshtml.dll!CMarkup::DetachElemCtxStream()  + 0x75 bytes
mshtml.dll!CAPProcessor::Evaluate()  + 0x5c027 bytes
mshtml.dll!CDoc::SubmitForAntiPhishProcessing()  + 0x168 bytes
mshtml.dll!CMarkup::CheckCtxInfoThreshold()  + 0x65 bytes
mshtml.dll!CMarkup::DetachElemCtxStream()  + 0x75 bytes
mshtml.dll!CAPProcessor::Evaluate()  + 0x5c027 bytes
Sunday, January 17, 2010 10:16 PM
• We know know that the problem lies inside somewhere inside SmartScreen filter (hence the SubmitForAntiPhishProcessing  in the above stack trace) and if we disable (not the best of solutions for obvious reasons)
I will contact Microsoft support to log a bug report but at least we have a work around for now.
Sunday, January 17, 2010 11:42 PM
• Hi,

Get your developers to convert the injected link tags to vanilla html (or asp or jsp or asp.net?) on your test harness page.

I would be interested to find out if DOM manipulation code can cause the issue with the Smartscreen filter as it is very hard to detect errors in scripting that manifest itself as incorrect markup for the chosen DTD.

You do mean Smartscreen filter and not InPrivate Filtering (aka ad blocking)? Google's urchin tracker in Adsence code may be an issue if you have InPrivate Filtering enabled and blocking the urchin code.

Regards.
Rob^_^
Sunday, January 17, 2010 11:55 PM
• Hi,

There are no PDFs and in general the client machine is pretty clean.  We now have the following sample that takes out

<html>
<body>
<script>
var div_html = '<div><div>AL<br /><a href="#">Edit</a></div><div id="driver_94655776">Driver_123477056<br /><a href="#">Edit</a> | <a href="#">Assign Driver</a></div><div id="address_94655776"><a href="#">KathyTest3</a><br />1234 Omr3 Bradley Dr <br />Moberly, Missouri </div><div id="options_12355776"><a href="#">Options</a></div></div>';
var frame;
function newIFrame(){
document.body.appendChild(frame = document.createElement("iframe"));
setTimeout(changeBody,100);
}
var y = 0;
function changeBody(){
frame.contentWindow.document.body.innerHTML = y++ + div_html;
setTimeout(changeBody,1);
}
setTimeout(newIFrame,1);
</script>
</body>
</html>

On our test client this loops 1000 times then crashes - if you make div_html larger then it will most likely fail quicker.
Monday, January 18, 2010 2:52 AM
• Hi,

First up div_html is incorrectly escaped.

sb.

var div_html = '<div><div>AL<br /><a href="#">Edit<\/a><\/div><div id="driver_94655776">Driver_123477056<br /><a href="#">Edit<\/a> | <a href="#">Assign Driver<\/a><\/div><div id="address_94655776"><a href="#">KathyTest3<\/a><br />1234 Omr3 Bradley Dr <br />Moberly, Missouri <\/div><div id="options_12355776"><a href="#">Options<\/a><\/div><\/div>';

There are additional markup errors, but I would like to ask a few questions first.

I am testing on Vista x86 SP2/IE8 4Gb ram from localhost IIS 7. I have not been able to Crash(?) IE with over 14000 iterations of the timer with both your original source and the amended (above). I will try to provide you with a corrected test case, but it will take some time (which I don't have just at the moment). That I cannot crash IE, is irrelavent at the moment.... I think my current test environment is not my usual default... so just now I cannot rule out my IE settings as a factor for my inability to reproduce the error. I will also test on XP and Win7 IE8.

What exactly do you mean by Crash?

Now... your source has no DTD and renders in IE8 in Quirks mode. (All browsers for that matter).
There is no fallback DTD for Quirks pages IE8's error handling.

Now Your div_html variable contains markup errors.

I suspect what is happening is that IE8's error handling is keeping a tally of markup errors and when it reaches a threshold count it tries to recover from rendering errors with Compatibility View, but since there is no fallback DTD for Quirks mode, it crashes (freezes). Since this is not a LCIE error (IE has encountered an Error and is unable to load this web page (after two attempts), there is also no page reload attempts in order to recover the original page (as would happen if IE8 encountered an error from a loaded Addon that is injecting markup into a page or is attempting Script Data execution).

You can easily test this yourself by turning off the IE8 setting "Automatically recover from rendering errors with Compatibility View" on the Advanced tab of Internet Options and re-loading your test page in a new IE window. (close all other IE windows first).

<note to other developers>
You should always include this in your test plans for IE8.
</note>

I expect that IE8 will then happily pass the error handling threshold and continue on the settimer loop.

Now. That is not all that is wrong with your mashup.

In IE (or FX) right click on the injected iframe and select the View Source context menu (script execution will stop while you have the context menu open).

In IE you will see
<html></html>
viz. there is no body tag! body.innerHTML=y++div_html; will trip another error in IE on each timer tick.

In FX (Tidy HTML extension) you will see

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><title></title></head><body></body></html>

Rob^_^

I will go away and try to create a cross browser, validated test case for you that will use a slightly different method to build the iframe src.

I would like you to go back to your test case and try with the "Recover from rendering errors with compatibility view" switched off to confirm my suspicions.

Also post back with details of your testing environment.

I would suspect that you are using XP/SP3 with IE8 on a Tomcat/Apache localhost?

If confirmed then IE should not attempt Compatibility view recoveries if the current Browser mode is Quirks. I can raise an issue report at connect.microsoft.com but I am sure I can provide you with a cross browser solution in vanilla html as a workaround.

It will be up to your developers to understand what I am trying to explain and to translate that back into their jsp source.

Thanks very much for providing the mashup. It makes distilling an answer for you all that much easier.

Perhaps the reason for the SubmitForAntiPhishProcessing in the stack is that at that stage IE is trying to contact the MS antiphishing web site to report your site with what it may think is a malicious attack on IE.

Regards.

Monday, January 18, 2010 8:08 AM
• Ok. I see from your post title that you are indeed using IE8 on XP. Regards.
Rob^_^
Monday, January 18, 2010 8:18 AM
• We have recreated this on Vista, XP and Windows server 2008 - we have our work around of disabling phishing filter - and logged a support call with Microsoft. Hopefully they will fix and provide a patch soon.

Tuesday, January 19, 2010 8:54 AM
• Hi,

Ok.... I was mulling over this the last day and I was kinda thinking that I should have referred you to connect directly, rather than trying to offer a workaround to the design pattern that you are using.

Because you are using an injected iframe with an injected script I suspect that your request to MS support will be met with a response of "By Design"

I beleive that in the long run you should look at changing the design patterns that you are using. AJAX is a prime candidate to replace your use of iframes.

I cannot say to much here in a public forum, but I think there is more to this than just IE8 not working with code that worked in earlier IE versions. IE8 is more secure than previous versions.

The MSFT forum moderator - John Sudds will be watching this thread and may ask for details of your issue ticket that you submitted so that he can follow it up.

Regards.
Rob^_^
Tuesday, January 19, 2010 9:35 AM
• I am having exactly the same issues with IE8 and smart screen filter.
I have looked into multiple ways of rewriting the code so it doesn't use innerHTML, but it still crashes ie8.
Here is my original pot on the forum: http://social.msdn.microsoft.com/Forums/en-US/iewebdevelopment/thread/230055e4-d577-44ca-87ff-95b5d3754ec1

or have you found a work around for this?

Any suggestions would be appreciated, as I am really stumped on this one!

Many thanks

Becky
Friday, January 29, 2010 11:42 AM
• Hi Becky,

Any news on this yet from your end? I've got the same problem. I've tried the following things but no effect:

- clear innerhtml before replace the content.
- removechild and appendchild
- replacechild
- disable smartscreen filter

Thanks Mattijs.
Monday, February 15, 2010 11:42 AM
• Hmm I couldn't reproduce the crash with the example above, is there another repro available? If not can you provide the crash dump, the dmp file, the stack trace by itself doesn't have enough information to debug the issue.

Wednesday, February 17, 2010 12:56 AM
• Hi Andy,

Yesterday I found that the crash only occurs if the crashing page is loaded inside an IFRAME.

Interesting detail: if you replace iframe with OBJECT it DOESN'T crash.

frame.html:

<html>
<body>
<iframe id="i_app" src="page.html" width=800 height=800 frameborder="Yes"></iframe>
</body>
</html>

page.html:

<html>

<script language="javascript" src="http.js"></script>

<div id="s_grid" style="width: 500px; height: 500px; border: solid 1px #000000;"></div>

</body>
</html>

{
var Resp = PostRequest('default.aspx?actie=gettext', ''); // xmlhttprequest to get about 1000 characters of HTML including form-definitions, links, etc.

s_grid.innerHTML = Resp;

return false;
}

After about a hundred or so iterations the browser crashes.
Mind you: it only crashes if you load page.html from within the iframe.

Thanks Mattijs.

Wednesday, February 17, 2010 10:40 AM
• Hi,

Can we get the full path or the source for default.aspx? Oh, and the external scripts.

My guess is that it is injecting invalid markup or contains a link to an address that is triggering the smart screen filter.

Have you tried with validated markup that will force IE8 to use the Standards Mode rendering? Your code will render as a Quirks document in IE8. It probably won't be using native XMLHTTPRequest, but the Smartscreen Filter will be.
We need the js source to tell whats happening.

Regards.
Rob^_^
Wednesday, February 17, 2010 7:43 PM
• Hi Rob,

Even when I make it completely compliant it still crashes, but you're right. It's the smartscreen filter. If you disable this you won't get the sysfader / stack overflow error.

It only crashes when there's HTML that I paste in the DIV. Just text works fine.

Any thoughts?

Thanks Mattijs.
Thursday, February 18, 2010 3:16 PM
• Hi,

validate your injected markup or use FireBug lite to inspect your XMLHTTP responses. (Thats why I asked for all of the resource files for your test case.)

What about answers to my other questions. You are just pulling the chain providing half cooked test cases. Give us one that works on a publicly accessible web site.

Regards.
Rob^_^
Thursday, February 18, 2010 11:38 PM
• Hi Rob,

I had to isolate the exact problem so I could give you the right info.

The link from where you can see the problem occurring is: http://85.17.47.142/frameset.html

Mattijs.
Friday, February 19, 2010 1:49 PM
• Hi Matti,

Thanks for that... It crashes IE like a charm with the SMSF turned on.

This was from the Internet Zone and odly when I turned it on/off, I then had the alert that
"cannot check this web stie because the Microsoft service is temporialy unavailable"

There are a few markup errors that you haven't corrected...

line 6 column 315 - Warning: '<' + '/' + letter not allowed here
line 25 column 5 - Warning: <input> isn't allowed in <body> elements
line 24 column 1 - Info: <body> previously mentioned
line 25 column 5 - Warning: inserting implicit <form>
line 25 column 5 - Warning: missing </form> before <div>
line 25 column 5 - Warning: <form> lacks "action" attribute

It is just the weekend over here, so I will give it the once over this weekend.

Heres the generated Problem signature for others.

Problem Event Name: APPCRASH

Application Name: iexplore.exe

Application Version: 8.0.6001.18882

Application Timestamp: 4b3ed243

Fault Module Name: mshtml.dll

Fault Module Version: 8.0.6001.18882

Fault Module Timestamp: 4b3ee91c

Exception Code: c00000fd

Exception Offset: 0005a9c8

Rob^_^
Friday, February 19, 2010 9:01 PM
• Hi,

Heres the cleaned-up markup

http://iecustomizer.com/msmvp/scfframeset.htm

Looks to me like the problem is the incorrectly escaped </form> tag in your innerHTML

</form>
sb
<\/form>

... stange...

Neither the validated nor your original show the completed alert in FX.

Anyway try the link above yourself or validate your production markup and retest there.

Regards.
Rob^_^
Friday, February 19, 2010 9:47 PM
• Hi Rob,

I've been playing with the code a bit and the injected code doesn't seem to cause the trouble, but the fact that the button is not enclosed by form-tags is.

<form><input type="button" value="Run crashtest" onclick=
"LoadUntilCrash();"></form>
If you leave out the form-tags it crashes, otherwise not.

Actually, specifically, I know it sounds weird:

If you put the end-tag </form> on a new line, it crashes. If you keep it after the button, it works fine.

Mattijs.
Monday, February 22, 2010 12:52 PM
• Hi,

Yes, I did not persue it too far. I usually have the IE8 Phishing filter turned off as one is included with my AV program. Why IE8 should fail in the Phishing filter when there is no <form> tag is a mistory..... since the tidied code does not include an action attribute for the form. I would have thought that it would have something to do with malformed href and action values.

If you run the validated markup again through the tidy validator it will pick up additional errors that were not detected in the first round of validation including a missing form action attribute.

Anyway... if you have followed any of my posts here, you will see that my most common reply is to tell developers to validate their markup.... its only natural that us humans make mistakes or leave things out. Markup and layout aren't compiled before they are fed up to a client browser. Talk about nailing jello to a tree!

Regards.
Rob^_^
Monday, February 22, 2010 7:49 PM
• I am experiencing this issue as well. To give some background, I work for a company that runs a few applications on Facebook, we recently ported our FBML apps to an iframe version and as soon as we did so we started getting compliants from users having their IE8 tab reset / crash. We have been able to replicate it with one XP environment on an older laptop after X number of page refreshes with SmartScreen Filter turned on, we are not able to replicate it on the same setup with SmartScreen Filter disabled.

Regardless if it is validated html or not should not cause the tab to reset, would be nice to hear an official response from MS on this topic.

The apps we run are 100% ajax and we are using jquery .html() to reload elements.

Running the app outside of facebook (not in facebook through an iframe) does not cause the tab to reset / crash.

Thursday, February 25, 2010 4:05 AM
• Hi,

Facebook is problematic.......we get lots of complaints about it from IE8 users.

Go to Facebook.com and run the homepage through the Validators... it is full of errors and some downright stupid coding (see the position of the <noscript> tag in the <head> section)

If you run it through the Tidy validator you will see that in other browsers the incorrectly positioned <noscript> tag forces the browser to inject an assumed body opening tag before the <noscript>

"Running the app outside of facebook (not in facebook through an iframe) does not cause the tab to reset / crash."

Confirms that.......

Please complain to Facebook..... maybe with enough grunt we can get the pig to fly.

I would imagine your heavy use of AJAX may also be a contributing factor... particuarly within an iframe....

Open your FB homepage in FX and use Firebug to monitor the XMLHTTP requests and resposes... In IE8 the page never completes loading (it appears)... the progress bar remains at 50%.

Here is what Mozilla has to say about the limits to the number of open connections...

https://developer.mozilla.org/en/XMLHttpRequest

Regards.

Rob^_^
Thursday, February 25, 2010 5:26 AM
• Thanks for the response and info Rob, will try a couple things at work tomorrow and re-run our html through validators and see if that turns anything up and will post an update here if anything positive turns up.

To clarify, if we run our apps through a standalone page outside of facebook in an iframe we still get the same results. So we can easily conclude that Facebook may have issues but their issues are not causing the IE8 tabs to reset, the issue is running our ajax apps through an iframe on any page using IE8 with SmartScreen Filters that cause the problems. (I see that language used in my previous post may have been confusing)

Maybe because I am not too familiar with the SmartScreen and all the happenings with IE8, but regardless of invalidated html that should not cause the tab to reset/crash. Seems to me that someone at MS should be looking into testing this one out a bit to determine why SmartScreen is causing IE8 tabs to refresh for their users that interact heavily with pages in an iframe through ajax because the issue does not exist in IE7, Firefox or Chrome. Until we find a solution we will be continuing to recommend Firefox or Chrome as telling users to turn off their malware add-on in their software does not usually play well.

My google searches also turned up what I believe to be the same issue and it does not sound like MS was very responsive: http://www.reddit.com/r/programming/comments/aqtvx/microsoft_blatantly_hung_up_on_us_so_this_is_how/

For completion I logged a bug with the link provided in earlier posts but am not hopeful that I will hear anything back.

- Eric.

Thursday, February 25, 2010 7:32 AM
• Hi Eric,

Any insights yet?

Mattijs.
Monday, March 01, 2010 8:00 AM
• Hi Eric and Mateiz,

I saw a post today with an IE user having problems accessing Americangreetings.com which is also using the Facebook API....

Here is a copy of a post that I made elsewhere......

Well, we all know that FB is a FP.

Here's why
<script type="text/javascript">
//<![CDATA[
window._is_quickling_index="";CavalryLogger=false;
//]]>
</script><noscript> <meta http-equiv=refresh content="0;
URL=?_fb_noscript=1" /> </noscript>

........

(the noscript tag is incorrectly placed within the head block... In the FX
Tidy Validator it shows a warning that a body tag has been assumed before
the start of the <noscript> block..)

Test case:

default) is turned off.

IE will try reloading the page as per the refresh content directive within
the <noscript> tags and dutifully give up after two tries (as per
Compatibility error recovery)  and the page will fail to load and render.

Now..... The user does not have to have FB in their Restricted sites zone.
They could have Active Scripting turned off in the Internet zone or they
could have an Addon installed that has disabled scripting.

My recommendations.

Set your Security zones to their default. Tools>Internet Options - Security
tab, click "Reset all zones to default"
zone that accepts active scripting). However since FB has SMPT mail services
there may be risks opening mail attachments.
............

Now, Why is the Phishing Filter comming into the equation?

I suspect that if you have a site in your Trusted Sites Zone, IE will not invoke it...

Hence...perhaps another test case is to place your site in a different security zone to what you have placed FB in.
Rob^_^
Monday, March 01, 2010 9:35 AM
• As I mentioned above without a way to reproduce the issue here it's going to be very difficult for us to investigate your issue. If you get a consistent repro you should be able to generate a crash dump and with that it's something to go on. If you don't see the windows error report crash report you can install WinDbg and then launch IE (>windbg iexplore.exe) with that and you can then generate a crash dump when you hit an exception. For more info on WinDbg look at http://www.microsoft.com/whdc/devtools/debugging/installx86.Mspx
Wednesday, March 10, 2010 12:43 AM
• Hello Andy,

Have you tried reproducing it following the instructions at reddit?

Try it with XP, IE8, Smartscreen on. Depending on the computer may take a little longer to crash but it will eventually.

If you have problems I can try to make the time to capture the crash with the software mentioned above but I have never had much luck with add-ons for Internet Explorer.

- Eric.
Thursday, March 11, 2010 5:24 AM
• Hello All,

I'm having the same situation with the AJAX on our site and the Smart Screen Filter.  We turn it off, everything works fine.

I've tried to download the debugger Andy Sterland mentioned.  I'm just not sure how exactly to use it.

I do have a list of all the crashes we received.  BUT, it's not only the MSHTML.DLL file.  I can get the browser to crash anytime I want and each time I get a different one of these four files:
• kernel32.dll
• ntdll.dll
• urlmon.dll
• mshtml.dll
I've attached the problem details for an example of each.  If I can find a way to use the debugger and get more information, I will.

Thank you,
Dave

kernel32.dll
Product
Internet Explorer

Problem
Stopped working

Date
3/9/2010 2:33 PM

Status
Not Reported

Problem signature
Problem Event Name:    APPCRASH
Application Name:    iexplore.exe
Application Version:    8.0.6001.18882
Application Timestamp:    4b3ed243
Fault Module Name:    kernel32.dll
Fault Module Version:    6.0.6001.18215
Fault Module Timestamp:    49953395
Exception Code:    c0000005
Exception Offset:    000bf395
OS Version:    6.0.6001.2.1.0.256.1
Locale ID:    1033

ntdll.dll
Product
Internet Explorer

Problem
Stopped working

Date
3/11/2010 9:11 AM

Status
Solution Available

Problem signature
Problem Event Name:    APPCRASH
Application Name:    iexplore.exe
Application Version:    8.0.6001.18882
Application Timestamp:    4b3ed243
Fault Module Name:    ntdll.dll
Fault Module Version:    6.0.6001.18000
Fault Module Timestamp:    4791a7a6
Exception Code:    c00000fd
Exception Offset:    0005a192
OS Version:    6.0.6001.2.1.0.256.1
Locale ID:    1033

Bucket ID:    1670938043

urlmon.dll
Product
Internet Explorer

Problem
Stopped working

Date
3/11/2010 9:10 AM

Status
Report Sent

Problem signature
Problem Event Name:    APPCRASH
Application Name:    iexplore.exe
Application Version:    8.0.6001.18882
Application Timestamp:    4b3ed243
Fault Module Name:    urlmon.dll
Fault Module Version:    8.0.6001.18882
Fault Module Timestamp:    4b3ee9d0
Exception Code:    c00000fd
Exception Offset:    0001ab98
OS Version:    6.0.6001.2.1.0.256.1
Locale ID:    1033

Bucket ID:    1670911568

mshtml.dll
Product
Internet Explorer

Problem
Stopped working

Date
3/11/2010 9:03 AM

Status
Not Reported

Problem signature
Problem Event Name:    APPCRASH
Application Name:    iexplore.exe
Application Version:    8.0.6001.18882
Application Timestamp:    4b3ed243
Fault Module Name:    mshtml.dll
Fault Module Version:    8.0.6001.18882
Fault Module Timestamp:    4b3ee91c
Exception Code:    c00000fd
Exception Offset:    0005b14c
OS Version:    6.0.6001.2.1.0.256.1
Locale ID:    1033

Thursday, March 11, 2010 2:22 PM
• Hi Rob,

Have there been any new insights on this subject. Other users have similar problems and I have to be honest: for the browser to complete crash on a markup error seems an error to me.

Thanks Mattijs.
Monday, March 15, 2010 10:38 AM
• Hi Mattijs,

Similar problems arn't necessaryily the same problem.

I have'nt been receiving email alerts on this thread, so I have missed some of the pasts made by others.

I do note though that the sample provided in the link above is unvalidated.

There is a new thread that is related...

One of the posters is using the FB api. One is using unvalidated classic asp (a legacy IDE). Both are using injected scripts in iframes. I am awaiting responses from them after they have corrected the errors and warnings in their markup.

I came across an article on google code about browser security (I won't publicly publish the link here, but you should be able to find it) that I find as an explanation as to why some 'design patterns' are rejected outright by IE... Actually this article places IE top of the list for security...it was written by one of the Chrome developers!

I have had no problems with the sites that I write and maintain with Visual Studio 8 and 9.

Umm ... I think you should try a search of Google code and find the above...and make your own conclusions...
A public forum is not the place to openly discuss security issues. I preferr not to shoot my mouth off.

I reviewed the documentation at MSDN for IE8 the other day...
http://msdn.microsoft.com/en-us/library/cc288472(VS.85).aspx
It seems to have been completed and is up-to-date and comprehensive. I think my review gave me some understandings as the why behind the reasoning for the way IE8 is the way it is... I would suggest that you read it also for your own interest and edification.

"to be honest: for the browser to complete crash on a markup error seems an error to me."

It is better that the code fails, rather than compromising the users machine. No computer program is perfect. If the autopilot on a plane fails, it is turned off and the pilot takes over.  I know of a js snippet that will turn FX and Flock to mush! (LIterally... the whole chrome goes blank), but I don't craft it into my pages. I am not about browser bashing... my main concern is to write stable, safe and interroperatable code for my site visitors.

I don't work for MS, Mozilla or any other software vendor, so I am unbridled by brand loyalties.

I liked this post on the above reddit thread....
<quote><sanitized>
I've come to realise after more than a decade of webdesign (semi-pro) that simpler is better. always. My idea of elegant design uses zero javascript, the simplest css construction possible and only enough server-side to keep organization equally simple.

oh. and duck flash. duck it right in the assp. unless is expressly for video presentation, then i suppose i can accept it.

but yeah, sometimes you gotta use iframes. I still see it as a weak spot in the design. If the idea is to window in an element fronm within your own assets, then it could be better handled server-side. if it's to allow inclusion of third party assets then it means the content of your site is reliant on third party assets... yuk.

but then I'm old and curmudgenly.

get off my lawn!

</quote>

I also found this quote from Erik Myer on css-discuss.... ( I can't find it in my archives.... basicly.... don't go to sites that can read your data stored on another site... )

So,,, any new insights... No... I don't think there should/will be any Chicken Little (the sky is falling) reactions from the IE Team. Issue reporting for IE8 and feature requests for IE9 has closed. They are aware of the issues and the IE SDLC has moved on. (I have had the opportunity to visit the Redmond campus.. it kinda reminded me of the Engineering feats of the Manhatton project during WWII... the place oozes brains and passion).

Unfortunately they cannot dictate what developers do with their sites. If developers suddenly find that their site no-longer works in IE8, then there is a good reason why it doesn't..... security and/or excessive markup errors. (or incompatible third-party Addons even!)

I just can't say too much.... maybe you will get my pitch here...

If it looks like a duck, walks like a duck, but has no feathers how do you know it realy is a duck? You don't until you hear it quack.
Even when you hear it quack you still won't know whether it had white or black feathers.

The Idea of Browser error correction is flawed. Crafted pages will on purpose present a featherless duck. Adding feathers to the duck (viz. the browser 'guesses' the color), black or white, still won't make it a duck. Instead of a duck the user ends up being ducked. The badies win the day.

Regards.

Rob^_^
Monday, March 15, 2010 2:10 PM
• Thanks for the links Rob.

The issue we see with our apps is that if there is a security risk that is causing the app to freeze, IE8 SmartFilter lets a user do it X number of times but on the xth time it will freeze the tab, is that really secure? To me it seems like IE8 is reaching some kind of memory limit and crashing the tab because of some bug in the SmartFilter because on different machines there will be a different threshold. Apps that we run on are highly interactive and users easily get to +100 page refreshes.

As developers it seems that we always have to do something different just for IE to get the page to render properly and now we have a magical SmartFilter that we know absolutely nothing about that has been shown to freeze / reset tabs.

I never expected this to get fix, just looking for some kind of direction on what is causing it and how to avoid it, frustrating indeed.
Wednesday, March 17, 2010 7:02 PM
• Hi Eric,

I won't comment Eric until you can provide a validated publicly accessible test case. As you can see in the sub thread with Matiez, his test case issue whent away once the markup had been corrected.

Think of it like this.... IE receives some code... it looks like a duck and walks like a duck, but has no feathers (invalid markup and a scripted iframe injection).

How will IE know its not a black duck? (viz.. malware)

One way would be to guess.. fill in the blanks in the malformed markup... add an ending script block here, insert an opening body tag there... very flakey... the true black duck will turn white... the user is ducked.

So what has the IE Phishing Filter got to do with this? One can guess, thats all I will say.

The Reddif sample is not validated. Validate and correct it and the issue goes away.

I suggest you at least validate and correct your markup first and then retest..

<quote>
The issue we see with our apps is that if there is a security risk that is causing the app to freeze, IE8 SmartFilter lets a user do it X number of times but on the xth time it will freeze the tab
<quote>

IE8's error handling and correction has limits otherwise the error stack would get to the point where it would cause overflows... Good markup has no errors.... the browser does not have to spend time and resources keeping track and correcting things on different threads. Pages will load faster, both in IE and other browsers.

Are you caching the page? The error stack won't be refreshed unless the page is refreshed from the server... makes sence to me.. Just code for Standards, Safety and Speed.. and Interoperability will fall into place.

Regards.

Rob^_^
Thursday, March 18, 2010 8:44 AM
• Hi all,

Just to say, I'm having the same problem, with IE8 only and only if SmartFilter is activated. Moreover, it seems that only XP and vista are concerned (I couldnt reproduce the crash on windows seven computers).

Basically, I inject some HTML code in a simple DIV, using javascript (this has to be so, because the injected code is the reply of an AJAX request). Here is the code:

var szDIV = '<DIV ID="DIV_W' + nKeyID + '" STYLE="position: absolute; margin-top: ' + (arrListUpdate[nKeyID].nY*g_nTileSize) + '; margin-left: ' + (arrListUpdate[nKeyID].nX*g_nTileSize) + '; z-index: ' + arrListUpdate[nKeyID].nY + ';">' +
'<DIV ID="DIV_Sprite' + nKeyID + '" STYLE="position: absolute; margin-top: -6; margin-left: -4; z-index: 0;">' +
'<A HREF="user_interactions.php?user=' + URLEncode(arrListUpdate[nKeyID].szLogin) + '" onMouseOver="return ShowResume(' + nKeyID + ');" onMouseOut="HideResume();"><IMG ID="IMG_Sprite' + nKeyID + '" BORDER="0" SRC="img/sprites/' + arrListUpdate[nKeyID].szSprite + '"></A>' +
'</DIV>' +
'</DIV>';

// Add this div to the container
var DIV_WContainer = document.getElementById('DIV_WContainer');
DIV_WContainer.innerHTML += szDIV;

This code does not crash until the nth iteration (for example, I can loop this 50 times and it's ok, but on the 51th iteration, IE crashes. More precised tests showed that the crash occurs when the size of the DIV container is around 30kb).

If I remove the <A> part, it can be far much larger than 30kb and it still DOES NOT crash!!!

Monday, March 22, 2010 3:19 PM
• Hi Alex,

There is a closed ticket at connect that your observation that you are unable to reproduce the issue on Win7/IE8 machine confirms.

https://connect.microsoft.com/IE/feedback/details/416918/browser-chokes-when-fed-junk

As with the other posts made on this thread I can see immediate errors in your injected markup. You have not escaped the double quotes in your injected markup strings.

eg.

var szDIV = '<DIV ID="DIV_W' + nKeyID + '" STYLE="position:.......

sb

var szDIV = '<DIV ID=\"DIV_W\"' + nKeyID + ' STYLE=\"position:......

Now, we all make mistakes... I know you are probably thinking... It works in other browsers, It works in earlier versions of IE, why doesn't it work in IE8? It must be a bug. Why does the Phishing Filter come into play...

You can read my previous posts on this thread about why I think there is rhyme in the reason for this behavior in IE8.

But to get your code up to standards and to be browser agnostic you MUST validate it and correct the errors. This after all is what you and I do for our users.

See this article which provides a compelling argument why every deviner should take the time to validate their pages before publishing them in the wild.

http://bytes.com/topic/html-css/insights/641514-validate-your-markup-early-often

Now... my preferred tool for this is the Tidy HTML extension for FX. There is the Tidied HTML option at the W3 validator that is linked to the IE8 Developer Tool, but the FX extension is better IMHO.

Test Plan.

Install the Tidy HTML extension for FX if not already installed. You will find it at addons.mozilla.org. It is important that you keep it up-to-date as it is contiually being adjusted for its own issues and interpretation of 'the standards'

Load your web site in FX and click the Tidy HTML icon in the status bar to display its report. At the bottom lhs you will see a summary of the Errors and Warnings that it finds.

IMPORTANT - You must correct not only the Errors that it lists but also the Warnings.

If you press the Tidy my HTML button a new window will open up with the corrected markup and script which you can compare with the original.

You will notice that the Warnings have been corrected in the tidied markup also.... (if you did the same with the W3 validator those warnings would be listed as errors)

Now working on a asp platform, what you see in the browser source is completely different to what you code in your IDE.

It is up to you to transpose the tidied client markup back to your python scripts....

Fix the warnings and I can all but guarantee that you problem pages will work in ALL browsers. The Phishing filter issue will go away.

The Validators are the no. 1 tool for crafting fast, safe, browser agnostic web pages. They provide invaluable insight into the inner workings of browsers. As I said, we all make mistakes when we are coding...typos etc...

The idea that a browser should make guesses about our intent when we code junk is just a guessing game that has no end.

When you code in a compiled language, you cannot build your applications until you have corrected ALL of your syntax and lexecons.

It is just good practice and common sence to do the same with your markup and layout.

The craft of web design comes in in your choice of "Design Patterns" that you use on your web pages.

Regards.

Rob^_^
Monday, March 22, 2010 9:45 PM
• Hi Rob!

Thanks for the long and useful answer :)

I will try to correct the different error of my page using the W3C validator. I will tell you after if it helps.

Just a single question: Why do I have to escape double quotes? They are inside strings delimited by simple quotes, so what is the problem exactly?

BTW, I did the modification and it didnt change anything, I still got the same crash :(

Sincerely,

Alex

Tuesday, March 23, 2010 11:49 PM
• Hi,

I may not be correct myself, but your original snippet... mmm can't find it... I thought there was a missing leading single quote...

anyway the tidy validators will pick up any mistakes. The above article mentions the affects of newline characters in js strings -

When working with long strings in your source code, you may be tempted to break the string up into multiple lines to make it more readable. While this sounds good, placing a carriage return in the middle of quoted text string will cause a script error - which for IE browsers is "Unterminated string constant". This is because the JavaScript interpreter sees carriage returns as the end of a statement - you may as well have placed a semi colon there.

From experience now (we have had three similar posts on this thread) we know that the issue is because of unvalidated markup of js injection scripts. Correcting the warnings generated in Tidy has ALWAYS corrected the issue.

A common error I've seen in tomcat generated js scripts is an unescaped closing tag... </a> sb <\/a>

hey the above article if vg.

Developers using FX and Tidy will see no Errors and just Warnings and think... hey looks good in FX, and junk in IE.. must be IE's fault.

My personal opinion is that we must not feed our clients junk. They will become fat with error correction code that we can never hope to satisfy. The new Opera 10.5 won't display certain types of junk code. The user will see a terse Programming error message. We had better all start now validating our code.

Regards.

Rob^_^
Wednesday, March 24, 2010 1:48 AM
• Hi again Rob,

First of all thanks for you help, I really appreciate it!

Well I've corrected all errors AND warnings using Tidy HTML (0 error and warning now).

I have also replace my multiple strings with one single escaped string.

And... It still crashes... only on IE8, xp or vista, smartfiler activated.

But I have now one brand new information. This page is contained in an iframe. If I open it outside this iframe (i.e. in its own tab), it does not crash anymore...

Is there anything I should care with iframe?

Regards,

Alex

Thursday, March 25, 2010 9:43 AM
• Hi,

You should also ensure that your IE Security zone settings are set to the factory defaults.

Tools>Internet Options - Security tab, click "Reset all zones to default".

How do you initialize your iframe src attribute?

and empty string? eg. <iframe src="" ....

or a computed page.. eg..

<html>..... valid markup <head><body><script>inject script here</.....

or

do you inject the script from the top window? Like this example from Welliot..

<html>
<body>
<script>
var div_html = '<div><div>AL<br /><a href="#">Edit</a></div><div id="driver_94655776">Driver_123477056<br /><a href="#">Edit</a> | <a href="#">Assign Driver</a></div><div id="address_94655776"><a href="#">KathyTest3</a><br />1234 Omr3 Bradley Dr <br />Moberly, Missouri </div><div id="options_12355776"><a href="#">Options</a></div></div>';
var frame;
function newIFrame(){
document.body.appendChild(frame = document.createElement("iframe"));
setTimeout(changeBody,100);
}
var y = 0;
function changeBody(){
frame.contentWindow.document.body.innerHTML = y++ + div_html;
setTimeout(changeBody,1);
}
setTimeout(newIFrame,1);
</script>
</body>
</html>

The source of the target iframe will be an about blank page (<html></html>) while in other browsers the error correction adds a <head> and <body> block.

For IE browsers you have to include the <head> and <body> blocks within your injection scripts.

to get around this for all browsers you have to prime your dynamicly created iframe with a real web page that contains the skeleton page for your injected markup. eg.

You first need to give it a scr attribute value to a 'real' empty web page.

<iframe scr="empty.htm".....

file: empty.htm

<html>

<title>An empty web page</title>

<body>

<!--- your external script can append elements to the parent body element here. --->

</body>

</html>

otherwise for the about:blank page...(the default contents of an empty <iframe> is

<html>

<! --- your external script wil raise errors here as there is no parent body element... any markup that is not in the <head> or <body> blocks is invalid... the validators do not pick it up because it is computed ---->

</html>

Probably the best way to craft pages like this is to first use vanilla html (no scripts) and then once you are satisfied, transpose your markup to javascript document.writeln or DOM appends.

You choice of document.writes or DOM appends will depend upon your target browser sets. IE6 (still popular in use) won't handle the new (to IE8) DOM methods.

AJAX use is probably better at providing dynimic markup instead of an iframe.... God! I have seen some FX fans go crazy about iframes and say we should not use them. You have to make the design pattern choices.

If you can provide a public link to your pages it would help immensly. I am only guessing otherwise.

Regards.

Rob^_^
Thursday, March 25, 2010 10:25 AM
• Hi Rob,

The code is not injected from the top level window.

This top-level window defines an iframe (actually, many iframes), and set a default page inside. This page is a PHP page. Once loaded, this page constantly uses AJAX to check the database and modify itself.

Now, here is the url of my site. It's a web game. Not (that bad I hope :). But the english translation is still in progress...

http://godwarriors.com/index.php?lang=eng

I created a "warrior" for you => login : iecustom, password : iecustom

Once logged, just click on the earth icon (bottom right of the GUI).

You will see then a map, zelda style, and after a few seconds, all characters on the same map as you will appear.

...Except if you are on XP/Vista, with IE8 and the smartscreen filter activated ;) Because if it's the case, IE crash and the tab is reset.

The code of the main page and the code of the map are 100% error and warning free according to tidy.

Alex

Friday, March 26, 2010 5:32 PM
• Hi Rob,

The code is not injected from the top level window.

This top-level window defines an iframe (actually, many iframes), and set a default page inside. This page is a PHP page. Once loaded, this page constantly uses AJAX to check the database and modify itself.

Now, here is the url of my site. It's a web game. Not (that bad I hope :). But the english translation is still in progress...

http://godwarriors.com/index.php?lang=eng

I created a "warrior" for you => login : iecustom, password : iecustom

Once logged, just click on the earth icon (bottom right of the GUI).

You will see then a map, zelda style, and after a few seconds, all characters on the same map as you will appear.

...Except if you are on XP/Vista, with IE8 and the smartscreen filter activated ;) Because if it's the case, IE crash and the tab is reset.

The code of the main page and the code of the map are 100% error and warning free according to tidy.

Alex

Friday, March 26, 2010 5:32 PM
• Hi Alex,

I cannot even load it in IE8 on Vista.

I can however load that url by itself.

Now... First and formost.... You must add <noscript> tags to all your pages to inform users that they have to activate Active Scripting in browser to use the site.... this is fundamental. Users will arrive at your site, think that is not working and leave and never come back.

Ok... I got your homepage to load.... your server must be being pounded as I speak... Saturday morning my time,, Friday night your time...

Now... your site is high traffic (well you are already experiencing outages)... You can immediatly improve this situation by optimizing your site. See websiteoptimization.com

online analyzer - http://www.websiteoptimization.com/services/analyze/

Using Fiddler I see that you are pulling content from other sources....

http://img19.imageshack.us/img19/3640/diapo168120f30f215a0eb3.jpg

Copy these localy and minimize your calls to external resource to other domains. The Phishing filter (either IE's or a users Anti-virus program) will be interregatig these, taking time on the round trips).

I have not gone any further yet, but I will in the next few hours. My initial feeling that your issues is more to do with site optimization and a timeing clitch in marshalling resource back to the client while completing phishing validations.

mmm. you are using HTTP 1.1 ..... IE users will need these options enabled on the Advanced tab of Internet Options...

You are refreshing the page... caching will give you better performance...

Thats enough now... I will leave you to download fiddler (there is also a FX version included).... I think you can probably improve things by tuning your server also. (you will be amazed by the improvement in performance if you allow caching of your pages.)... You may not want to do this though on some of your games pages if they involve multi-user interaction.....

AJAX is great for these types of games applications...

Regards.

I don't envy you Alex.... you have alot of work a head of you. All the validation correction has not been in vain though... it will speed up your page loads and make your site run better in all browsers.

Cache your pages, replace those links to imageshack with copies on your server... I can see fiddler in the backgound processing the refresh requests... all 200 responses... nothings changed on your server or at imageshack... you don't need them.

Regards.

Rob^_^
Friday, March 26, 2010 9:54 PM
• Hi Alex,

I cannot even load it in IE8 on Vista.

I can however load that url by itself.

Now... First and formost.... You must add <noscript> tags to all your pages to inform users that they have to activate Active Scripting in browser to use the site.... this is fundamental. Users will arrive at your site, think that is not working and leave and never come back.

Ok... I got your homepage to load.... your server must be being pounded as I speak... Saturday morning my time,, Friday night your time...

Now... your site is high traffic (well you are already experiencing outages)... You can immediatly improve this situation by optimizing your site. See websiteoptimization.com

online analyzer - http://www.websiteoptimization.com/services/analyze/

Using Fiddler I see that you are pulling content from other sources....

http://img19.imageshack.us/img19/3640/diapo168120f30f215a0eb3.jpg

Copy these localy and minimize your calls to external resource to other domains. The Phishing filter (either IE's or a users Anti-virus program) will be interregatig these, taking time on the round trips).

I have not gone any further yet, but I will in the next few hours. My initial feeling that your issues is more to do with site optimization and a timeing clitch in marshalling resource back to the client while completing phishing validations.

mmm. you are using HTTP 1.1 ..... IE users will need these options enabled on the Advanced tab of Internet Options...

You are refreshing the page... caching will give you better performance...

Thats enough now... I will leave you to download fiddler (there is also a FX version included).... I think you can probably improve things by tuning your server also. (you will be amazed by the improvement in performance if you allow caching of your pages.)... You may not want to do this though on some of your games pages if they involve multi-user interaction.....

AJAX is great for these types of games applications...

Regards.

I don't envy you Alex.... you have alot of work a head of you. All the validation correction has not been in vain though... it will speed up your page loads and make your site run better in all browsers.

Cache your pages, replace those links to imageshack with copies on your server... I can see fiddler in the backgound processing the refresh requests... all 200 responses... nothings changed on your server or at imageshack... you don't need them.

Regards.

Rob^_^
Friday, March 26, 2010 9:54 PM
• Hi Alex,

No need for a password... I can navigate straight to http://godwarriors.com/map.php?width=1311&height=667 (probably  afer I had looged in though... yep... you have the userid and password in the cookie....)

Well this makes it easy for me ....

That page hauls back 86 images... lets see your scipts....

cf:http://stackoverflow.com/questions/561046/how-many-concurrent-ajax-xmlhttprequest-requests-are-allowed-in-popular-browser

<quote>

I believe there is a maximum number of concurrent http requests that browsers will make to the same domain, which is in the order of 4-8 requests depending on the user's settings and browser.

You could set up your requests to go to different domains, which may or may not be feasible. The Yahoo guys did a lot of research in this area, which you can read about (here). Remember that every new domain you add also requires a DNS lookup. The YSlow guys recommend between 2 and 4 domains to achieve a good compromise between parallel requests and DNS lookups, although this is focusing on the page's loading time, not subsequent AJAX requests

</quote>

(the Phishing Filter will be using XHTMLRequests... don't forget also that other installed AV software probably will have their own Phishing Filter) (window.maxConnectionsPerServer returns 6...)

I could not identify from source where this is occurring...but if I answer yes to stop the script, then no more images are downloaded and I am left with a screen with half the other players missing. So you are probably doing this with AJAX responses.,,, see who else is playing the game.... get their avatas and position them on the screen?

mmm... I don't know how you are going to solve this...

I would change the page_onload logic to

Retrieve a list of other players and download their avatars and position them on the 'canvas'.

Open the XMLHTTP connections (limit it to 5 or 4 maybe) which will be used to position other players.javascript:alert(window.maxConnectionsPerServer);

Probably nothing to do with junk code... more likely with the max number of XHTMLRequest objects

Rob^_^
Friday, March 26, 2010 11:04 PM
• Hi Alex,

c! someone had slipped in a featherless duck. I should have known.... games site = kiddie koder playground. If you had provided a site link first off we could have reduced the guessing.

PS. the latest FX has a phishing filter also as does chrome. They don't use the same data sets.

In IE8 you can use the InPrivate Filter (aka ad blocker/content filter) to only allow content from your site. You should retest with this condition and with the Phishing Filter turned on.

Oh, you can use Fiddler to do the same thing... its a very handy tool. But don't forget to sanitize your database data containing links to user Avatas... You should not allow users to add external links... allow uploads to your server, but sanitize the contents before it arrives. Be aware of links like http:\\evil.com\?file=something.jpg, the fake file extension on the end of the link.

As part of your test plans also include a run with your site in the IE Restricted Sites Zone. Hence... you need that <noscript> tag to clearly identify that active scripting is disabled.

Oh, just in case, also test from another location (IP address). They may be hiding from you.

I am not MSFT, but they will have probably been following this thread.

Regards.

Rob^_^
Saturday, March 27, 2010 7:59 AM
• Hi Rob,

Well I guess you are from Australia, or somewhere around this area, because of the 12hours-like difference. It probably explains why my site was slow. Yours, for example, is also quite slow for me.

Now, in cold Switzerland, it's saturday morning, and You gave me A LOT of information to analyse. I imagine my week end will be an interesting one ;)

I'm still a bit skeptical about my code. I know there is much place for improvement but I'm still not sure about the responsibility of the crash. (Please note that it's a hobby project, I'm working on 3D simulation projects, C++, OpenGL, shaders, etc... quite different actually)

Anyway, If I replace the <IMG> tags (in the quoted script above) with single strings, or with a <MENU><LI></MENU>, there is no crash anymore. But I dont really see what the smartscreen filter has to do with <IMG> tags...

I will post the result of your advices later today (or eventually sunday).

Many thanks again :)

Alex

Saturday, March 27, 2010 11:32 AM
• Hi Alex,

Please do not take offense... I did not mean to be uncivil.... when I said Games site=Kiddie koder playground I was referring to the possibility that your site was the victim of a user injecting their own code in your game via their Avata link.

I get comletely different results when I visit the page (with scripting enabled)... the page loads slowly and eventually I get the IE8 error message that "Scripts are running slowly... do you want to continue running scripts " message. I could not identify which script was doing this.... I did not want to go any further...and I got scared off.

Coming from a compiled language development background I am sure that you appreciate the differences between a compilied program written in C++ and an interpretative language like HTML. Leaving the client to interpret the programmers intent is prone to errors.

<img> tags can contain external scr values that can be a vector for a hacker to inject scripts into the games they are playing for example to add cheats for their advantage.

There is a security zone setting in IE to "Open files based on content, not file extension". This is why it is important to use the default security zone settings when testing IE.

<quote>

Anyway, If I replace the <IMG> tags (in the quoted script above) with single strings, or with a <MENU><LI></MENU>, there is no crash anymore. But I dont really see what the smartscreen filter has to do with <IMG> tags...

</quote>

I don't quite know what you mean by this... the <img> tag issue may be explained by my suspicions above.... I don't want to discuss security issues here.

I can only say that the Validators aren't perfect... I would have thought that they would have picked up that the <li> tag was missing a valid parent <ul> or <ol> tag, and also that it was unclosed.

The design pattern is

<ul>

<li><a href="">Text</a></li>

</ul>

I may be wrong... without referring to the specs... perhaps <menu> is a valid parent to a <li> element.

Regards.

Rob^_^
Sunday, March 28, 2010 11:51 AM
• Hi,

Sorry for the delay Rob, I tested a lot of different things the last 3 days. Forget about the <MENU><LI></MENU>, it was just an example to show that some HTML tags crash my code (<IMG>), some other not (<MENU>)!

And don't worry, I didn't take offense, because I tend to think that critics make you better at the very end ;)

In the future, I probably have to read and optimize my code once again. And I have to secure my code also. You opened my eyes. HTML coding required rigor, more than C/C++. This is something you don't really realize at the beginning...

Apart from that, I think I found a workaround to solve both performance and crash problems.

As I explained before, I have a global DIV container. When my first AJAX request is replied, I populate this container with one DIV sub-container for every player. FYI here is the code again:

var szDIV = '<DIV ID="DIV_W' + nKeyID + '" STYLE="position: absolute; margin-top: ' + (arrListUpdate[nKeyID].nY*g_nTileSize) + '; margin-left: ' + (arrListUpdate[nKeyID].nX*g_nTileSize) + '; z-index: ' + arrListUpdate[nKeyID].nY + ';">' +
'<DIV ID="DIV_Sprite' + nKeyID + '" STYLE="position: absolute; margin-top: -6; margin-left: -4; z-index: 0;">' +
'<A HREF="user_interactions.php?user=' + URLEncode(arrListUpdate[nKeyID].szLogin) + '" onMouseOver="return ShowResume(' + nKeyID + ');" onMouseOut="HideResume();"><IMG ID="IMG_Sprite' + nKeyID + '" BORDER="0" SRC="img/sprites/' + arrListUpdate[nKeyID].szSprite + '"></A>' +
'</DIV>' +
'</DIV>';

// Add this div to the container
var DIV_WContainer = document.getElementById('DIV_WContainer');
DIV_WContainer.innerHTML += szDIV;

The performance problem is easy to identify. For every player, I create a new DIV sub-container that I concatenate to the DIV main container. On high-end PCs, you just don't notice it, but on older ones, the concatenation just takes too much time. Multiply it by the number of player and you got performance problems, and your Javascript engine starts to complain. ^^

So basically what did I change?

Now, I pre-generate all DIV sub-container directly in PHP. Empty sub-container... When the first AJAX request is replied, I dont concatenate the whole DIV sub-container to the main container anymore. I just populate the DIV sub-container with the code.

It works faster, far much faster!

And the "cerise sur le gateau" as we say in french (the cherry on the cake ^^), It does not crash anymore.

Do you have any idea why the smartscreen filter is not complaining anymore? Because basically, the code is the same at the end. I just generate it differently.

Monday, March 29, 2010 5:56 PM
• Below is what was captured with windbg, starts off with 2 stack overflows and then loops forever over the Access Violation errors.

0:036> g
(fbc.ed8): Stack overflow - code c00000fd (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=046a46a0 ebx=014871b8 ecx=01483030 edx=3db0bec8 esi=04755638 edi=00000000
eip=3dafa33a esp=01483000 ebp=01483004 iopl=0         nv up ei ng nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010286
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\WINDOWS\system32\mshtml.dll -
mshtml!DllGetClassObject+0xbcf55:
3dafa33a 53              push    ebx
0:008> g
(fbc.ed8): Stack overflow - code c00000fd (!!! second chance !!!)
eax=046a46a0 ebx=014871b8 ecx=01483030 edx=3db0bec8 esi=04755638 edi=00000000
eip=3dafa33a esp=01483000 ebp=01483004 iopl=0         nv up ei ng nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000286
mshtml!DllGetClassObject+0xbcf55:
3dafa33a 53              push    ebx
0:008> g
(fbc.ed8): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=01480000 ebx=04755638 ecx=01480ba4 edx=00000000 esi=04755638 edi=01484cb8
eip=3daf6a3b esp=01484bb4 ebp=01484bbc iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010206
mshtml!DllGetClassObject+0xb9656:
3daf6a3b 8500            test    dword ptr [eax],eax  ds:0023:01480000=????????
0:008> g
(fbc.ed8): Access violation - code c0000005 (!!! second chance !!!)
eax=01480000 ebx=04755638 ecx=01480ba4 edx=00000000 esi=04755638 edi=01484cb8
eip=3daf6a3b esp=01484bb4 ebp=01484bbc iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206
mshtml!DllGetClassObject+0xb9656:
3daf6a3b 8500            test    dword ptr [eax],eax  ds:0023:01480000=????????

If you are interested in taking a closer look at one the games you can if you have a facebook account at: http://apps.facebook.com/pirateclan

These issues are captured by just clicking a page link from the menu over and over again, different pages will have different thresholds before reset. As mentioned previously can only reproduce with smart filter turned on, turned off do not get resets with the same threshold of page refreshes.

If you need more debug info you will have to provide further instructions on capturing.

I am beyond debating whether or not valid html (0 warnings / 0 errors) should cause IE8 to crash with smart filter on, any insight from someone at MS or others would be appreciated. Looking for the reason why this crashes on some computers with SmartFilter turned on but not when turned off valid Html or not, if invalid HTML is the root cause then what invalid HTML is causing this issue.

- Eric.

Thursday, April 01, 2010 4:56 AM
• Anybody willing to help out with this?

I am convinced that the problem lies with-in the smartfilter which does not like the combo of our apps HTML, jqueries .html() function and updating elements through ajax/.html() inside of an iframe. How we can tweak our code to not crash IE8 Smartfilter is what we have been trying to figure out but without knowing the specifics of the smartfilter we are kind of lost and left to just make blind/best guess changes that to date have not found a solution. Would be great to get someone from the IE8 team that has knowledge of the smartfilter to help out.

IE8 dev team, anybody?

Monday, April 05, 2010 11:41 PM
• Oh it is interesting to note that if we do not use jqueries function .html() but instead use the .append() function the IE8 tab will not reset, so it is very unlikely that removing all html warnings is the problem here since we can continue to append() the same html over and over again without IE8/Smartfilter choking but as soon as we try to empty an element and replace it with the same HTML IE8 chokes.

So it looks like it has something to do with clearing out an element, we tried to replace the .html() function with a .innerHTML='' and append() but IE8 still crashed and burned after x # of ajax calls.

Any help or suggestions would be very appreciated as this problem is driving me kind of nuts.

Monday, April 05, 2010 11:47 PM
• Eric, please post the files so i can reproduce error.

Wednesday, April 07, 2010 4:52 PM
• Same story here, IE8 (smartscreen filter on) is crashing after about 50 ajax page refreshes.  Web app using jquery and .html() to populate a div inside an iframe. Im working with Eric on this so any information above here I've already tried. Hope this crash dump provides some added info.

Here is my Windows 7 IE crash report:

Problem signature:
Problem Event Name:    APPCRASH
Application Name:    iexplore.exe
Application Version:    8.0.7600.16385
Application Timestamp:    4a5bc69e
Fault Module Name:    mshtml.dll
Fault Module Version:    8.0.7600.16535
Fault Module Timestamp:    4b83889f
Exception Code:    c0000005
Exception Offset:    003481f6
OS Version:    6.1.7600.2.0.0.256.48
Locale ID:    4105

Wednesday, April 07, 2010 6:40 PM
• Seba,

To see the full application you can go to, http://apps.facebook.com/pirateclan , that is if you have a facebook account.

If you do have a facebook account and if you give me your fb user id I can make a link accessible that refreshes the 'inner-container' of the application by calling our getPage() function which is the same as just clicking on a link over and over once per second. Any help would be greatly appreciated seba_msdn.

I have further determined that it is just not limited to iframe, this bug also occurs outside of an iframe. I am setting up a couple of tests with just basic elements trying to figure out what are the problematic ones.

Wish someone could provide some insight on why IE8 SmartScreen Filter is choking.

- Eric.

Thursday, April 08, 2010 4:20 AM
• Hi Eric,

I'm wondering, are you dynamically creating HTML elements?

I create many <IMG> elements, each one having an URL as a source, so maybe the smartscreen filter is confused about that.

Thursday, April 08, 2010 11:52 AM
• Hello Alex,

It crashes without images. Right now have a basic test where we have an inner container that we continue to update 1000 divs and links through the jquery .html() function that will bring down SmartScreen Filter pretty easily. The html is well-formed, it seems that adding in more elements with id's will and links with onclick events will bring IE8 SmartScreen to its knees, the more time I am investing into this bug it is almost like MS should be giving me a paycheck.

How about someone that actually works at MS helps out on this, gets on the board and tries to explain why 1000 elements updated through jqueries .html function with SmartScreen Filter brings the browser to its knees.

The more I am working with IE8 SmartScreen Filter the more that I am beginning to think that it isn't very smart.

As always help would be appreciated as the only response I have received from MS to date is that there is no plan to fix this or acknowledgment that it is even an issue which is rather frustrating.

Thursday, April 08, 2010 9:05 PM
• We can recreate this problem.  Malformed HTML created with an AJAX HTML editor will crash IE8 while editing if SmartScreen Filter is turned on.  The HTML is definitely a mess but HTML should never crash a browser.  The SmartScreen filter code has a bug and needs to be fixed.
Monday, April 12, 2010 11:32 PM
• From our tests this is not just limited to malformed HTML. Something as simple as:

<div id="container_to_update">

<div id="test_div_XX">HELLO THIS IS A TEST <a href="SOME_URL" onclick="ajax_update()">Test Link</a></div>

</div>

Where ajax_update() is a javascript function that interfaces with jqueries ajax functions and uses .html() to update the container, we tried using .innerHtml directly but with no luck.

Where the above is looped from 0 -> xx and "container_to_update" is the container that is updated through ajax, with xx being 250 can crash the browser within 50 or so ajax updates and setting to 1000 will bring down the browser in under 10 updates.

I have reported this bug to MS but they would like me to contact them directly to spend more of my time trying to communicate this bug to them, I have had no luck getting them to help out with this thread. Seems like a waste of my time to phone, wait through their support channel, then repeat the info that is in this thread a bunch of times to different people until I get someone who could help.

I am hopeful that someone from MS can get on these forums and provide some insight into what is going on so that we can build ajax applications that do not cause SmartScreen to reset the tab.

- Eric.

Monday, April 12, 2010 11:58 PM
• If you would like to assist to get someone from MS to look at this thread try getting them through the IE8 support channel here: https://support.microsoft.com/oas/default.aspx?&prid=13043&ln=en-us&st=1&wfxredirect=1

And reference this thread in the request.

Tuesday, April 13, 2010 12:03 AM
• Oh man looks like we are on our own unless we want to pay MS to help out, this is a response I just got from MS IE8 support. Not sure why I would spend more time and even my own $$to get MS to debug this SmartScreen Issue. If Microsofts only incentive to fix their products is to collect a service charge then I don't really know what to say. I may follow up with them on a call to tell them how ridiculous this is but I will not open myself up to possible charges as I have spent more than enough time/$$ on this problem... here is the support response.

"I read the thread that you have sent us and it's bit too technical for us to follow since this a single PC consumer support. Since this issue requires expertise from Developer team, I cannot forward this thread to that team unless you speak to our Customer Service and create a new service request so that they can work on it. Standard charges are applicable for troubleshooting this issue since you are testing applications with the browser. For more information about the charges, please contact Microsoft Customer Central at 1-800-936-5700. Once they create a new service request, they would redirect you to the appropriate department.

I do not have authority to send any forum links or threads to the Developer team without having a service request.

I appreciate your understanding in this regard."

Tuesday, April 13, 2010 6:27 PM
• That's a funny answer... (no no I'm not ironic)
Thursday, April 15, 2010 7:32 AM
• I'm syffering from the same problem using removeChild under iframe, Sometimes after the crash the url ie8 recoves with add some charachter to the original url which indicate a bad pointer. Is Microsoft going to deliver a patch soon?
Thursday, April 15, 2010 1:35 PM
• For those interested, below is the last email that was sent to MS Support after just getting off the phone with MS Support. As I am not interested in paying for MS to look into this bug with their browser it looks like this will not get fixed so it is up to us to find workarounds and to continue to recommend alternative browsers. Unless someone else in this thread would like to open a support account to pay for them to fix this issue.

"I have just gotten off the phone with the support # that you provided with but unfortunately no luck, I have just spent 40-min more of my time which my employer is paying for and my employer is not Microsoft but the issue is with IE8's SmartScreen Filter.

Our company has spent more $$on this issue in employee time than any other issue to date with any other browser. All I want to do is to get someone technically capable of helping give some insight into what could be causing SmartScreen to crash the tab and a workaround until MS can release a patch for the SmartScreen Filter. Why is it that I have to set up a customer support account with a credit card number even if I am not willing to pay for MS to fix this issue in their browser? The last person I talked to was Chris employee id #100274436, he clearly explained to me that Microsoft's new policy is to create a Customer Support Account before they can get someone that can help but since I was not willing to supply a credit card # he could not help me, even though he clearly stated that if the account was to be billed that I would be given the chance to decide to continue or not but even though I have made that decision right now (that I do not want to be billed) he was still unable to proceed. Now this is craziness, I want to continue to push for somekind of developer insight and recognition from MS that this is an issue but I refuse to be liable for support costs to help push this through Microsoft and help better their product. Right now our only workaround is to reduce the number of elements that are being updated through ajax which seems to increase the number of ajax updates before the crash happens and to continue to recommend users to either stay with IE7, turn off SmartScreen Filter for IE8 or use other browsers (FireFox, Chrome, Opera, Safari) which do not have these issues. I really hope that you can find a way to get some kind of technical help with this issue without me having to supply a credit card #. I will be posting this message to http://social.msdn.microsoft.com/Forums/en-US/iewebdevelopment/thread/74c15fcd-0d9e-4f09-af97-0f88d3ac423c/ to let everyone in the thread know that I have taken this as far as I can with Microsoft but not willing to invest anymore of our companies$$ to help fix this issue with Microsoft's IE8 SmartScreen Filter."

Thursday, April 15, 2010 4:58 PM
• Hi Eric,

Whats wrong with this line?

What comes first. the href or the click? (aka the chicken or the egg). For that matter what is the 'target' in this context? Of coarse the validators won't pick up the issues that the above design pattern has. The Validators themselves are not validated and are being contually updated.

Unless you can provide a link to your web site or to a validated test page that exemplifies the issue you are wasting both yours and our time and money.

If you have a look at this thread you will already see that a workable solution has been offered.

The test case provided at

has validation errors. The issue disappeared once the validation errors were corrected. Unless you can wrap your head around the need to validate your markup you should not waste your time chasing red herrings.

Written communication (viz a verbal forum post or support ticket) is useless without a testable example. As the Phishing filter is involved you are dealing with IE security issues. These kazump any poor coding issues. Since the Phishing filter issue disappears once the poor coding issues have been corrected we can only draw on conclusion.

Regards. I am not MSFT.

Rob^_^
Thursday, April 15, 2010 9:04 PM
• Hi Eric,

Whats wrong with this line?

What comes first. the href or the click? (aka the chicken or the egg). For that matter what is the 'target' in this context? Of coarse the validators won't pick up the issues that the above design pattern has. The Validators themselves are not validated and are being contually updated.

Unless you can provide a link to your web site or to a validated test page that exemplifies the issue you are wasting both yours and our time and money.

If you have a look at this thread you will already see that a workable solution has been offered.

The test case provided at

has validation errors. The issue disappeared once the validation errors were corrected. Unless you can wrap your head around the need to validate your markup you should not waste your time chasing red herrings.

Written communication (viz a verbal forum post or support ticket) is useless without a testable example. As the Phishing filter is involved you are dealing with IE security issues. These kazump any poor coding issues. Since the Phishing filter issue disappears once the poor coding issues have been corrected we can only draw on conclusion.

Regards. I am not MSFT.

Rob^_^
Thursday, April 15, 2010 9:09 PM
• Hello Rob,

That is one of the games.

Rob, Html with tidy warnings should not cause IE8 to reset, if that is the product that MS wants to develop then they are targeting about 1% of the web pages out there.

I will try to get some time this week to put a simple example that can be linked to here.

- Eric.

Thursday, April 15, 2010 9:17 PM
• And regarding <a href="SOME_URL" onclick="ajax_update()">

My mistake, should be: <a href="SOME_URL" onclick="ajax_update(); return false;">

Where ajax_update() just completes an ajax request and updates the container.

Thursday, April 15, 2010 9:21 PM
• Hi,

mmm. Facebook.... my favorite pet peeve.

It will be an issue of security zone settings and XSS in IE. Try using your app in FX with IETabs. If it works there it is definately a security issue and/or validation issues (IEtabs uses the IE7 emulation mode).

Sorry, I can't comment on the quality of the Facebook API's - I've let all my pet peeves out the door and don't bother to feed them. You will see that there is another OP on this thread that had the same issue with a site using the FB API's. I would suggest that your take it up at developer.facebook.com

Probably also you are placing a <noscript> tag within your head section of your iframe page like they do throughout their sites. static.facebook.com is on my block list. Run you pages through the Tidy HTML validator in FX and correct ALL the warnings.

Regards.

Rob^_^
Thursday, April 15, 2010 9:56 PM
• Rob,

I quickly put together a simple example of repeated divs and links that is causing IE8 with SmartScreen to crash the tab, and it is validated.

I want to verify that it resets on our work test environments before posting the link here.

I should have something posted in the AM.

Stay tuned,

- Eric.

Friday, April 16, 2010 7:05 AM
• Hi,

Before you go too far... I was pulling your chain a bit with the jibe about the form of your <a> tag.

Think what is happening with this structure...

<a href="SOME_URL" onclick="ajax_update(); return false;">

as compared to

<a href="#" onclick="ajax_update(); navigateto('SomeURL');return false;">

in the context of navigating away from the parent container... In your case an iframe element.

Now, I am not up to speed exactly what or how the Phishing filter works, but I imagine it does some sort of lookup in the beforeNavigate event handler in the Browser control and also in the XMLHTTP request event handlers (I don't know what they are).

So the browser processes the click of an <a> tag, Seeing a href value it will execute it first, so the beforeNavigate event is fired, but also (I imagine) a new thread is created to process the onClick event... I am not really up on this, but can you see my point?

I think also the Phishing filter may play a role in sanitizing a page, so it may be invoked when you inject scripts into pages or iframes.

YOu also have to consider what other anti phishing sofware is installed on your machine. Many anti-virus applications also hook into these events to do their own sanitation, but basicly explicitly supplying both a href and a onclick navigation event I would imaging that the marshalling gets confused.

Why IE and not other browsers? Well, I can only say they are different. The definitive test I use is to load a page in IETabs in FX. If it works there then I definately know it is either a security zone setting issue or an error handling issue in the IEStandards mode (because IETabs only uses the IE7 Emulation mode, even though it is hosted on an IE8 machine..... FeatureControl).

Here is the connect listing for the term Phishing, XSS and Facebook

https://connect.microsoft.com/IE/SearchResults.aspx?SearchQuery=Phishing

https://connect.microsoft.com/IE/SearchResults.aspx?SearchQuery=XSS

A previous post on this thread said, that the issue only occured when injecting elements into an iframe. I've had a cursory look at the FB API's. All examples are within bounding div's, no iframes. iframes have always been a security risk.

The accepted method of communicating across iframes is the PostMessage method.

http://blogs.msdn.com/ieinternals/archive/2009/09/16/Bugs-in-IE8-support-for-HTML5-postMessage-sessionStorage-and-localStorage.aspx

http://ajaxian.com/archives/using-html-5-postmessage

If you really think there is an issue and you want to inform MS about it you can join and raise an issue ticket (for free) on connect.microsoft.com/ie.

You have to go through a seclection process, but as an ISV (Independant Software Vendor - FB service provider) you should be accepted. But also you need to explain the issue very well and include validated test cases and detailed instructions to help the MS triage reproduce and identify the issue. They probably won't have access to static.facebook.com (behind their corporate FW's) so it could be difficult to get this message across. The more information you can supply the more attention they will give it. Their time  and effort is valued also. They could be earning $'s as support engineers. MS doesn't make money from IE sales... there is only so much they can bear. I give my time and effort here as an unpaid volunteer/enthusiast. (I do get some gratuities as a MSMVP, but not comsurate to the effort I put in). There is only so much I can bear too. Regards. Rob^_^ Friday, April 16, 2010 9:35 AM • Rob, first off I do appreciate your input and time that you are putting into this please but I have obviously reached my limit in frustration with MS Support and Support of their IE8 product. Here is a fully validated example that will cause an IE8 tab to crash with SmartScreen filter enabled: http://project250.com/ie_reset_test_iframe.php The above link is resetting 3 of 4 of our work environments consistently at 5 ajax updates, to test out click the link at the top of the page "AUTO AJAX REFRESH (0)". XP and Vista systems are resetting, sometimes Windows 7 will reset too but it seems to depend on which way the wind is blowing at that time. Clicking on the link will call an interface to jqueries$.post() function repeatedly through setTimeout().

Disabling SmartScreen Filter will cause the browser to not reset.

http://project250.com/ie_reset_test.php

The above link is the src of the iframe, running the same tests does not crash the browser.

Now the test page has 1000 div elements and 1000 onclick links, if I half that and use 500 IE8 will reset after 10 updates.

This test eliminates the Facebook theory, so we can ignore that.

And Rob I do appreciate your help but feel that it is necessary to just quickly comment back on a one point but do not want to derail too far from what I am trying to achieve here and that is getting IE8 SmartScreen filter to play nice with heavy ajax applications. If Micrsoft isn't making enough money to support their product that is not my problem it is theirs, if it is not financially advantageous to them and they cannot provide the necessary support to ensure a great browsing experience then they need to drop the product and let companies that have figured out how too to take over their market share which is likely inevitable anyways if this is the kind of support and levels of bureaucracy that are required to log a bug from the developer community.

Hope someone can provide some help and crossing my fingers that a IE8 MS Developer might take some time to comment.

- Eric.

Friday, April 16, 2010 4:52 PM
• Hi Eric,

I am unable to reproduce the issue on Vista x86 SP2, IE8 (fully patched as of yesterday)

I threw everything I had at it, Google and Yahoo toolbars (both up to date).

Things I would like you to try

1. Check that your Advanced tab IE Options settings are all the same on all your test machines.

HTTP - 80 HTTP/1.1 200 OK
Date: Fri, 16 Apr 2010 19:30:48 GMT
Server: Apache/1.3.41 (Unix) mod_gzip/1.3.26.1a mod_log_bytes/1.2 mod_bwlimited/1.4 mod_auth_passthrough/1.8 FrontPage/5.0.2.2635 mod_ssl/2.8.31 OpenSSL/0.9.7a
Last-Modified: Fri, 03 Jul 2009 01:51:51 GMT
ETag: "7601be-2a-4a4d6437"
Accept-Ranges: bytes
Content-Length: 42
Connection: close
Content-Type: text/html

I have both http 1.0 options enabled.

2. If you have not already done so, retest with "Enable third-party browser extensions" unchecked on the Advanced tab of Internet Options. Close all Open IE windows and restart IE before testing.

If you have the Gmail notifier installed also go to msconfig and turn it off for Windows startup and reboot your machines.

(I am asking this as although I do have the GTB enabled while running your test, I have disabled some of its functions which are incompatible with IE8 (see the About links on the GTB options) and I disabled the GMail notifier long ago from my startup list because it caused problems. I note also that you are using the Google versions of the jQuery libraries.... I am wondering if perhaps there is some version conflicts with the versions that GMail notifier may be using.

Generally also I have disabled any Update software from my Windows startup list... GoogleToolbar Notifier, AOL Software Notifier,  Yahoo Mail,  Quick Time updates.... I suppose generally any non MS service..... but Gmail notifier is top on my list of suspects.

3. Download and install the fiddler tool from http://www.fiddlertool.com and run it while conducting your tests to capture your http and xmlhttp traffic. Post back with the header information of the last xmlhttp request before the failure. Do not apply any filters so that you capture all traffic, including xmlhttp request from your rss and mail services.

I have a resonable number of rss feeds installed, but also note your rss request traffic... mmm Google has a feed aggregation service don't they?

Where do we go from here?

I guess I will raise an issue ticket at connect and reference this thread, although if they can't reproduce the issue it won't go far. So it is important that we rule out all other possibilities.

Anyway, since I can't reproduce the issue I am relying upon you to do the forensics on your end... The Fiddler tool will help you imensely. The symptoms you have described (sparodic failure on the Win7 machince, vs clockwork reporducability on your Vista and XP manchines) seems to suggest that some legacy software may be involved. First up you should inspect what you have in Windows Startup with MSConfig (Start>Run... msconfig)

It is Friday afternoon in Redmond, so I will wait until Monday their time before I try and refer this thread to connect and/or my one contact there. There is a MSFT moderator on this forum who will be monitoring these threads, but sometimes they are busy with their business lines of work.

Please leave your test case available on your servers to allow others to jump in and give it a test. Eventually connect may need to access it also.

Regards.

Rob^_^
Friday, April 16, 2010 8:33 PM
• That is unfortunate that you could not reproduce. What we have found is that sometimes to get the resets repeatable make sure you shutdown IE to reset it, then open IE again and then run the test.

Not sure why it is so easy to reproduce on 4 separate computers running either vista or xp, since it is so easy for us to reproduce then I have no doubt that MS will be able to reproduce, if not we can supply whatever info required to get them to.

I will take a look at some of the suggestions but am busy on other development as I have already gone far over budgeted dev time to investigate this SmartScreen issue.

Has anyone else had any luck in reproducing the reset:

http://project250.com/ie_reset_test_iframe.php

Saturday, April 17, 2010 10:45 PM
• Hello Rob,

Have you had a chance to raise this issue with MS yet?

I have not had the time to go through and try the areas that you have suggested, the fact that this test has reset now 8 different computers each at 5 ajax updates with IE8 out of the box defaults (which 99% of our IE8 user base will have) is very concerning but should be very easy for MS to reproduce as we have not had a problem on all machines that we have tested.

I will make sure that my computer has latest updates and retest again just to rule that out.

It is important to note that to get it to reset consistently it is best to restart the browser and have the test page (http://project250.com/ie_reset_test_iframe.php ) be the first one, it seems like when memory used by the browser is large resetting becomes more difficult. Also make sure that SmartScreen Filter is enabled, click "AUTO AJAX REFRESH" and after 5 updates hopefully IE8 will hang like we have seen on our machines.

- Eric.

Tuesday, April 20, 2010 4:28 PM
• Well I updated IE8 with Cumulative Security Update for Internet Explorer 8 for Windows Vista for x64-based Systems (KB980182) and have not been able to replicate on my machine.

Guess it could have been fixed in the update?
Wednesday, April 21, 2010 11:19 PM
• I encountered a very similar APPCRASH event, but since I am using Windows 7, the fix eric_msdn_234 had success with doesn't apply for me. Is there a similar patch for Windows 7 machines?

Same story here, IE8 (smartscreen filter on) is crashing after about 50 ajax page refreshes.  Web app using jquery and .html() to populate a div inside an iframe. Im working with Eric on this so any information above here I've already tried. Hope this crash dump provides some added info.

Here is my Windows 7 IE crash report:

Problem signature:
Problem Event Name:    APPCRASH
Application Name:    iexplore.exe
Application Version:    8.0.7600.16385
Application Timestamp:    4a5bc69e
Fault Module Name:    mshtml.dll
Fault Module Version:    8.0.7600.16535
Fault Module Timestamp:    4b83889f
Exception Code:    c0000005
Exception Offset:    003481f6
OS Version:    6.1.7600.2.0.0.256.48
Locale ID:    4105