none
Why? - "Internet Explorer cannot display the webpage" in IE7,8,9 but page works in Firefox or Chrome

    Question

  • I have randomly experienced "Internet Explorer cannot display the webpage" with IE7, IE8 and now IE9 with pages that load without issue in Firefox. Sometimes if I hit refresh 2-3 times the page will load but generally it will never load and the "Diagnose Connection..." link does not find an issue - in ALL cases if I try to load the same page using Firefox 3.x, 4.x or Google Chrome (10.x) the page will display without issue. Many of these pages are Microsoft support pages as in the example below.

    Microsoft KB956196 suggests the website or network conenction as the issue - this is not the case.
    http://support.microsoft.com/kb/956196

    See this screenshot for an example of a page that I cannot display in Internet Explorer 9 on Windows 7 SP1. Page displayed instantly with no issues in Firefox.
    Page: http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=0a87658f-20b8-4dcc-ad7a-09ad22641f3a
    Screenshot of IE9 vs Firefox 4: http://i.imgur.com/JoM6J.png

    Any help appreciated as I love IE9 (finally a real browser from MS!) but between this and animated GIF's not working at all (that's critical!) I keep having to lean over to other browsers.

     

    Any help appreciated!



    Friday, April 29, 2011 2:26 PM

All replies

  • the "Diagnose Connection..." link does not find an issue

    See this screenshot for an example of a page that I cannot display in Internet Explorer 9 on Windows 7 SP1. Page displayed instantly with no issues in Firefox.
    Page: http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=0a87658f-20b8-4dcc-ad7a-09ad22641f3a


    The Diagnose... tool only can do useful stuff in that scenario on W7.   Click it and reply to its Can't find... message, then wait for an automatic refresh of the page to be done.   If that doesn't work flush the dnscache and try again.  Then, before closing the troubleshooter, use  ipconfig /displaydns  to see what it has done.   You will have to be quick; the Time To Live for some of those records is very short.   ; )

    You might get different results by inserting Fiddler2 between the host(s) and the browser.

     

    Good luck

    Robert Aldwinckle
    ---

    Friday, April 29, 2011 9:38 PM
  • Thanks Robert, I'll try to do all that next time. The page is working in IE now so have to wait until it happens again.

    Any possible explaination or insight as to why the issue is IE specific? Two browsers side by side hitting the same page at the same time and one says the page is not available... interesting.


    Friday, April 29, 2011 9:48 PM
  • Any possible explaination or insight as to why the issue is IE specific?


    It has to be timing generally but it could also be differences due to User-Agent.  I have (facetiously) speculated that bits of functionality that were originally imbedded in both the OS and IE for an old ill-considered feature called AutoScan still linger in both but I have no way of checking that idea.  Also, I don't know how other browsers do their lookups or cache them, e.g. whether they are as dependent on the dnscache behaviour as IE seems to be.   Supposedly once IE has opened a file on a site, lookup should no longer be an issue--provided the IP address it has picked is kept in service for as long as the task stays running.  So, if that's true the favicon.ico that we see it fetching unsolicited could satisfy that requirement.  Then that would be another workaround for getting connectivity for slow pages, make IE fetch the site's favicon.ico file first.  A possible problem with that idea is that if it was from a site you had previously visited you might only be getting a cached copy; then press Ctrl-F5 to be sure that you are getting it with current connectivity.

     

    HTH

    Robert
    ---

    Saturday, April 30, 2011 4:23 PM
  • Loaded for me. try and reset IE.
    Monday, May 02, 2011 2:48 AM
  • Any possible explaination or insight as to why the issue is IE specific?


    It has to be timing generally but it could also be differences due to User-Agent.  I have (facetiously) speculated that bits of functionality that were originally imbedded in both the OS and IE for an old ill-considered feature called AutoScan still linger in both but I have no way of checking that idea.  Also, I don't know how other browsers do their lookups or cache them, e.g. whether they are as dependent on the dnscache behaviour as IE seems to be.   Supposedly once IE has opened a file on a site, lookup should no longer be an issue--provided the IP address it has picked is kept in service for as long as the task stays running.  So, if that's true the favicon.ico that we see it fetching unsolicited could satisfy that requirement.  Then that would be another workaround for getting connectivity for slow pages, make IE fetch the site's favicon.ico file first.  A possible problem with that idea is that if it was from a site you had previously visited you might only be getting a cached copy; then press Ctrl-F5 to be sure that you are getting it with current connectivity.

     

    HTH

    Robert
    ---


    Thanks Robert - AutoScan or something like that sounds plausible due to the behavior. It's just odd that Internet Explorer decides a website isn't available when it is - That has to be something unique that other browsers aren't doing, or some manner in which IE or parts of the OS that IE leverages, and other browers don't, is perhaps affected by being on a domain. It's very frustrating to have IE tell you a site isn't available - clear cache, close and re-open, delete cookies and it's still not available - while you browse the same site on the same system with another browser, and can borwse the same site at a later time.
    Monday, May 02, 2011 1:18 PM
  • Loaded for me. try and reset IE.

    Yes loaded for me at a later time as I noted in the thread - that's part of the issue.


    Monday, May 02, 2011 1:20 PM
  • I was having a similar problem with a web site that simply would NOT be found with IE9.  It would always give the page not found error and diagnostics would not find any problem.  I deleted IE9 cache, reset IE9 to defaults, ran IE9 in safe mode, cleared the DNS cache,  etc.  No help.  Yet going to the site in Firefox was no problem.  So I figured it had to be something specific to IE9 that I wasn't catching (since Firefox would find it and IE9 would not I figured that it couldn't be at the DNS level.

    So I decided to clear the browsing history one more time... and this time I paid a little more attention to the first item in the Delete Browsing History dialog box.  Note that the text says that it will keep temporary Internet files for favorite sites (whatever favorite means) for faster access.  Hmmmmmmm... does that mean the page and address information might be cached?  I unchecked the "Preserve Favorites website data" and wa-la, IE9 found the site!  And so far, hasn't had a problem finding it since ;)

     


    Norm Sash http://nerdmans.com
    • Proposed as answer by Norm Sash-ns Friday, September 30, 2011 11:26 PM
    • Edited by Norm Sash-ns Friday, September 30, 2011 11:28 PM
    Friday, September 30, 2011 11:26 PM
  • I was experiencing the exact same issue, tried everything Microsoft suggested (even though I strongly suspected ahead of time that none of their solutions was going to help), and also what Norm Sash suggested above. None of it worked. What did work for me was to disable Tracking Protection under the Manage Add-ons Tool. Voila! Hope this can help someone else.

    Tuesday, November 29, 2011 11:28 AM
  • OK, I take that back. Disabling tracking protection solved the problem for some sites, but not all. After trying many other suggestions found online and experimenting some more on my own, I found that lowering my Kaspersky Internet Security 2012 web antivirus setting from 'recommended' to 'low' solved the issue on the other sites.
    Tuesday, November 29, 2011 12:32 PM
  • I experienced the same issue.  I had to change an intranet home page to redirect to another page so created just a small web page that did a redirect (a server side redirect is preferable but i don't have access to make server configuration changes).  After making this change, i started getting the random "Intranet explorer cannot display the webpage" error.  This was a big problem since it was the intranet home page and everybodies browser in the company opened this page by default using IE.

    The solution for me was to pad out the page so that it wasn't as small.  I added alot of invisible text to the home page by inserting a few of the divs below.  After the page size exceeded a certain threshold (not sure exactly what it is), the "Intranet explorer cannot display the webpage" error stopped happening.  Why this fixes the problem is beyond me, but it does work and it saved me a lot of grief. 

    Here's the invisible div i added to my web page to stop this error from happening...

    <div style="display: none">
    Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum
    </div>

    • Proposed as answer by httPants Thursday, April 05, 2012 12:46 AM
    Thursday, April 05, 2012 12:45 AM
  • @PANTS

    you are probably correct....

    Ie has security settings that affect the navigation to sites in different zones... a homepage on your hard disk is treated like a web page in the internet, while your intranet site is mapped to the Intranet zone....

    certain types of server side redirects are also controled by IE's security settings, and a web site designer has control over how those server side redirects are implemented and the response codes that they send back to the client.

    the 'Show friendly errors' setting on the Advanced tab of internet options, is used to display the "Internet Explore cannot display webpage" page... If the content returned by the server is less than 500 kb...that is why adding additional content to your intranet homepage fixes the issue.

    regards.


    Rob^_^

    Thursday, April 05, 2012 8:33 AM
  • This rather sounds like a "redirect" done incorrectly. Remember that IE displays server-side error pages below 512 bytes only if you have disabled "friendly error pages". Your issue looks like something completely different than the OP's problem. (= you shouldn't have added this unrelated problem to a dead thread.)

    IEFAQ: http://iefaq.info


    Thursday, April 05, 2012 12:11 PM
  • [image of possible lookup problem for host  answers.microsoft.com]

    @ Vapor Lock

    Did you try the diagnostics I suggested?   This could be an example of what I meant:

    <nslookup>

    Non-authoritative answer:
    Name:    origin.answers.ms.akadns.net
    Address:  65.55.121.50
    Aliases:  answers.microsoft.com
              g.answers.ms.akadns.net
    </nslookup>

    Notice that the host name that you want to use is an alias for the one that has the address?   That means it is only represented by a CNAME record.   Also, you will probably find that it only chains to the other alias and then finally to the canonical name.  

    So, let's try something a bit different.   Go for the canonical name first...

    http://origin.answers.ms.akadns.net/

    Wow.   That redirects to the host that we want.   Who knew?   I was expecting a  404  but at least proof that the  IP address would be cached.

    See if that helps your case?   If not please do the  ipconfig  /displaydns   so you can tell us what it did get.


    Good luck

    Robert
    ---

    Friday, April 06, 2012 10:14 AM
  • Why should I? And I wasn't talking to you. Please understand that if I'm telling a certain poster that his problem is not the same as what's been discussed in this thread (and which is dead, I won't follow it) is just this. It does not mean that others don't have the same or similar problem as discussed in this (dead) thread.

    IEFAQ: http://iefaq.info


    Saturday, April 07, 2012 2:12 PM
  • [Address bar of screenshot shows
         http://animals.howstuffworks.com/reptiles/alligator-pictures.htm
    ]

    Another example of a possible problem with a DNS alias.   However, with this one you won't be as lucky as with the Answers caching host name case.

    <nslookup>

    Non-authoritative answer:
    Name:    a462.g.akamai.net
    Addresses:  72.246.43.81
              72.246.43.56
    Aliases:  animals.howstuffworks.com
              wildcard.origin.howstuffworks.com.edgesuite.net
    </nslookup>


    So one way to test using this information would be to

    1. In a cmd window (elevated if necessary) enter:  ipconfig /flushdns
    2. Enter in the IE Address bar
      http://a462.g.akamai.net/animals.howstuffworks.com/reptiles/alligator-pictures.htm
    3. Observe an HTTP 400 from the caching server (addressable host but wrong name for that path and file)
    4. Delete the caching host name from the above URI (e.g. use Ctrl-CursorLeft to position to that from the end and Ctrl-Backspace to remove the parts of it, or do whatever else you would like to do to change it the the URL that you wanted to use)
    5. Press Enter with the desired URL
    6. Switch back to the cmd window and enter:  ipconfig  /displaydns


    BTW I have realized from this example that my usual suggestion of using  ping -n 1  -w 1  to load the dnscache with all the parts of the lookup is actually best because if  IE  actually does get to do a lookup for the caching server host and see its 400 response you won't be able to use it again as a method of loading the dnscache with the necessary pieces of your lookup until either IE's  DNS timeout expires for that one or you close your IE window and open a new instance of  iexplore.exe.


    FYI

    Robert
    ---



    Saturday, April 07, 2012 5:42 PM
  • @Vapor Lock

    I get Room 500 at CERN.

    http://en.wikipedia.org/wiki/Encarta

    In March 2009, Microsoft announced it was discontinuing the Encarta disc and online versions. The MSN Encarta site in all countries except Japan was closed on October 31, 2009. Japan's Encarta site was closed on December 31, 2009.<sup class="reference" id="cite_ref-EncartaDead_2-0">[3]</sup><sup class="reference" id="cite_ref-Ars_encarta_dead_3-0">[4]</sup> Microsoft continued to operate the Encarta online dictionary at dictionary.msn.com until 2011.

    na na.

    heres a blank page I encountered in Chrome

    <!-- begin ad tag (tile=15) -->
    
    <script type="text/javascript">
    
    //<![CDATA[
    
    ord=Math.random()*10000000000000000;
    
    document.write('<script type="text/javascript" src="http://ad.doubleclick.net/adj/dfp.coastalwatch.com/;sect=surfcam;state=NSW;cam=3400;tile=15;sz=243x30;ord=' + ord + '?"><\/script>');
    
    //]]>
    
    </script>
    
    <noscript><a href="http://ad.doubleclick.net/jump/dfp.coastalwatch.com/;sect=surfcam;state=NSW;cam=3400;tile=15;sz=243x30;ord=123456789?" target="_blank" ><img src="http://ad.doubleclick.net/ad/dfp.coastalwatch.com/;sect=surfcam;state=NSW;cam=3400;tile=15;sz=243x30;ord=123456789?" border="0" alt="" /></a></noscript>
    
    <!-- end ad tag -->


    Rob^_^

    Saturday, April 07, 2012 8:39 PM
  • http://encarta.msn.com/encnet/features/dictionary/dictionaryhome.aspx

    <nslookup>

    Non-authoritative answer:
    Name:    encarta.msn.com
    Address:  65.55.93.69

    </nslookup>

    If this comment had done, as I suggested, a  displaydns  after  IE  tried the above request, it could have proved that IE can do a successful lookup for this host.  Hence it would prove that DNS lookup for that host name could not be an issue with any subsequent problem which would have been reported.

    In fact, though, this host name is an excellent example (e.g. apparently very reliable) of how to generate IE's cannot display message.   So now we can look at the list of possible explanations for it and see that several are now ruled out, in particular the ones about DNS.

    Then next I would suggest using Fiddler2 either for its Composer tool (previously called Request Builder) or just as an HTTP tracer.

    Doing the latter  Fiddler  reports:

    [Fiddler] ReadResponse() failed: The server did not return a response for this request.

    One of the other benefits of having a reliable cannot display case is that now we can look at the  Diagnose Connection Problems  feature in more detail.

    As is often the case after doing the diagnosis it informed me that  Troubleshooting couldn't identify a problem.   But then I could click on the View Detailed Information link, expand the Detection Details section and then open the  Diagnostic log (.etl) file.  That opened in Performance Analyzer and I think now explains why a problem was not detected in this case.   It appears that it stops short of actually issuing an HTTP request or at least of waiting for its response.   So, it shows that it can do a lookup and this can be proved by once again doing an  ipconfig /flushdns  before using it and an  ipconfig /displaydns  after using it.

    Another thing that this example nicely demonstrates is how the troubleshooter's lookup can be cached and immediately ready for IE to use.   Unfortunately, as I have been pointing out throughout this incident, it does not take into consideration that the host name that the user wants might be an alias and does not test the alias' canonical host name; hence it can not provide any cached records for an IP address to be applied to the desired alias.


    Thank you for your example, Vapor Lock.   Very helpful.   ;  )


    Robert
    ---

    Sunday, April 08, 2012 8:09 AM
  • @Vapor Lock,

    Sorry, yes you were correct I thought you were referreing to me...

    CERN Room 404 is where the original 404 error code referrs to.

    are we derailing the thread?.... Grafis was the OP.... (your the thread hijacker)...

    your other example...

    http://animals.howstuffworks.com/animals/aligator-pictures.htm

    returns room 404... turn on Friendly errors on the Advanced tab of Internet Options.


    Rob^_^

    Sunday, April 08, 2012 8:45 PM
  • your other example...

    http://animals.howstuffworks.com/animals/aligator-pictures.htm

    Are you still seeing that?   It has been changed for me somehow.   Now it is some kind of animated graphic.   Very funny but definitely not what I was seeing before.   Maybe I need to clear my cache?   E.g. once he knows that I got the change he could change it back to what it was originally?

    FWIW here is what the Developer Tools, Find tool gets:

    <img src="http://public.blu.livefilestore.com/y1pkT-XLhOkMbYE3PlcSNhvNvc17v-eA2d3LUsj5kF8yioubACXrgDIIYop3JY7u_3XdaKmJdlRR4JAqXqZmf7gWA/EasterBunny.gif">

    I wonder if I only picked up one of the overlays?...   Nope.  It's all there.   You just have to wait for it.   (Until it gets deleted or changed.)



    ---

    Sunday, April 08, 2012 9:25 PM
  • @Robert.

    alligators.... my mis-type from the screen shot..

    s.b http://animals.howstuffworks.com/animals/alligator-pictures.htm

    which gets redirected to

    http://animals.howstuffworks.com/reptiles/alligator-pictures.htm

    URL Method Result Type Received Taken Initiator Wait‎‎ Start‎‎ Request‎‎ Response‎‎ Cache read‎‎ Gap‎‎
    /animals/alligator-pictures.htm GET 301 text/html 311 B < 1 ms navigate 0 0 0 0 0 17378
    http://animals.howstuffworks.com/reptiles/alligator-pictures.htm GET 304 text/html 270 B 15 ms navigate 0 0 0 15 0 17363

    Time to pull the chain on Vapor Lock and follow Kais' wise advice to Vapor Lock.

    Why should I? And I wasn't talking to you. Please understand that if I'm telling a certain poster that his problem is not the same as what's been discussed in this thread (and which is dead, I won't follow it) is just this. It does not mean that others don't have the same or similar problem as discussed in this (dead) thread.

    see Vapor Locks reply to Kai... he's broken the terms of conduct.


    Rob^_^


    Monday, April 09, 2012 12:51 AM
  • see Vapor Locks reply to Kai... he's broken the terms of conduct.


    Not intolerably?   I suspect this is our old friend derosnec.   I appreciate his technical skill and points of view, so put up with some of the obnoxiousness.   ;  )

    If you complain this thread is going to look pretty strange...    ;  }


    Robert
    ---


    Monday, April 09, 2012 1:53 AM
  • Hi all, original poster here. Back because I've experienced the issue again several times - the issue comes and goes with no explanation and no apparent rhyme or reason. I've been watching this thread and others and waiting for a fix or recognition of the issue from Microsoft. So far Vapor Lock and Robert Aldewinkle have given the most data I've seen (appears Vapors posts were removed?) I tried the Preserve Data trick from Norm Sash-ns (no luck but a good one to know) ... otherwise haven't seen suggestions or solutions that could help solve the issue.

    Scenario for my latest issue, see attached screenshot. 

      • In Conference room browsing Concur website using IE9 on Windows 7.
      • Returning to my desk and docking station.
      • Website will not load in IE9.
      • Run Connection Diags - "troubleshooting couldn't identify the problem"
      • Load Firefox 10.0.7 ESR and Concur website instantly loads. (ESR = Extended Support Relase for Biz, Edu, Gov, and large entities)
      • Run PING and TRACE and Concur website responds and resolves.
      • Check website from Mac using Safari and Firefox. Site loads. Check using Google Chrome on XP, site loads.
      • Curse IE
      • Site works fine 2 days later in IE9

    So all of the theories and potentials aside - How can a web browser decide a website isn't available when it is? How can a Microsoft web browser tell me websites built by Microsoft (see my first posted example), designed for IE9 and hosted on IIS (?)... are not not available when they are in other browsers. ARGH!

    IE9 - sigh........


    • Edited by Grafis Tuesday, September 25, 2012 12:13 AM
    Tuesday, September 25, 2012 12:11 AM
  • So all of the theories and potentials aside -

    Why aside?  

    How can a web browser decide a website isn't available when it is?

    FWIW I think timing factors that we have no control over and insufficient diagnostics to prove, would explain things adequately.

    [image implying problem accessing  concursolutions.com]

     

    That site has a favicon.  Why didn't you try it?   In fact, though doing that would only prove HTTP connectivity and evidently it is HTTPS connectivity that you ultimately need so there would be even more unknown factors to consider to get there.   But if *any* of those unknowns caused a failure in the first attempt at connectivity you would be presented with the same confounding "diagnostic" message.

     
    Robert
    ---

    Tuesday, September 25, 2012 12:50 AM
  • Robert - poor choice of words (all theories aside...) just can't wrap my head around how one browser has had this issue for 6+ years over four major version releases spanning three full operating systems. Timing sounds plausible, DNS caching... or a problematic tie between the OS and the browser which could explain why no other web browser suffers the issue. Favicon - not sure what to try there, F5 certainly isn't helpful. If I see the issue again I can try calling the favicon directly to see if that will force the site to load? 
    Tuesday, September 25, 2012 1:50 AM
  • Favicon - not sure what to try there, F5 certainly isn't helpful. If I see the issue again I can try calling the favicon directly to see if that will force the site to load? 

    Yes.  Using

    http://concursolutions.com/favicon.ico

    as a connectivity check will be significantly better than using ping or tracert.   E.g. the protocol involved will be HTTP instead of ICMP (though, as I mentioned, not HTTPS).   So, this would prove addressability and connectivity to a server that matters.   However, if you have already visited that host, especially if you have a Favorite for it, you should press Ctrl-F5 at least once to prove that the image file is not being rendered from a local copy, e.g. that all of the connectivity checks you would be using the favicon.ico for were actually done.

     
    FYI

     
    Robert
    ---

    Tuesday, September 25, 2012 4:29 AM