Windows 7 – Fix New Tab Freezes in 32-bit Explorer on 64-bit Windows 7

64-bitinternet explorerwindows 7

The title says it all.

When running 32-bit Explorer on 64-bit Windows-7, right click a link and select "Open in New Tab", a new tab opens, tab caption is"Connecting...", but it never connects and the tab response to nothing other than a close.

64-bit Exporer works fine.

Anyone any ideas why this happens?
Thanks

P.S. To forestall the inevitable questions, we need to use 32-bit Explorer to test our own sites that rely on 32-bit controls. This has nothing to do with this problem, it shows up with general browsing.

Best Answer

Folks, sorted with help from an answer to a (sort-of) related question on serverfault.com (which I no longer can find).

Registering ieproxy.dll fixed the problem, assuming similar setup to my own, run

regsvr32 "c:\Program Files (x86)\Internet Explorer\ieproxy.dll"

Related Solutions

Windows – How to stop – Google chrome window opening bottom right of screen

Exit Chrome, navigate to your User Data folder (eg C:\Users\IanN\AppData\Local\Google\Chrome\User Data\Default), then open the file Preferences and look for the following section

"browser": {
   .
   . <there will likely be a few sections here>
   .
   "window_placement": {
      "bottom": 1149,
      "left": 0,
      "maximized": false,
      "right": 1600,
      "top": 406,
      "work_area_bottom": 1149,
      "work_area_left": 0,
      "work_area_right": 1600,
      "work_area_top": 0
   },
   .
   .
   .
},…

Either adjust the number, or just delete the whole window_placement block—make sure to be careful not to delete other stuff; use the curly-braces as guides and make sure to match them. (Make a backup copy of the file, just in case.)

Now run Chrome. It should be displayed in the default location. If not, then you could delete the other window_placement_* blocks from Preferences and …\User Data\Local State (Local State is a file in the parent folder of Default.)

Windows – IE doesn’t work with localhost + port

The WWW3 article Setting the HTTP charset parameter specifies :

Content-Type: text/html; charset=utf-8

This defines Content-Type as having a blank before charset.

I know that you have already found out that this is indeed the problem, so the source of the problem is some very unimaginative programming by Microsoft or by some middle-man proxy.

Best Answer

Related Solutions

Windows – How to stop – Google chrome window opening bottom right of screen

Windows – IE doesn’t work with localhost + port

Related Question