NanoToolkit Blog

The Way to Keep in Touch.

IE 9, IE10, IE11 and Three Shades on Windows X64

Let’s start by noting that everything said in this article pretty much pertains to Windows X64. If you used Internet Explorer 9 or below on a 64 bit system you might have noticed that by default Microsoft configured IE 32 bit edition to be default the browser that you saw as a shortcut on your Computer Desktop. That’s because up until then Adobe Flash was a 32-bit only component on Windows. Starting with IE10 and Windows8 Microsoft Decided that they are going to ship Adobe Flash along with Windows as a third party component. However, Adobe and Microsoft changed things slightly so that Flash was considered an ActiveX (OCX) that could run on both 32 and 64 bit Architectures of Windows7 and Windows8. I am actually over simplifying the matter since Flash Runs As and out of Process COM Server but more on that later. That’s why on X64 systems with Microsoft Windows8 the default IE Shortcut on your desktop actually points C:\program files\Internet Explorer\iexplore.exe. That is it points to the actual 64 bit version of IE. This behavior is exactly completely to the contrary of default behavior that Windows7 X64 had. Windows7 x64 shipped with IE9 or IE8 and its shortcut pointed to “C:\Program Files (x86)\Internet Explorer\iexplore.exe". This behavior has continued with IE11 that ships with Windows 8.1 (in less than a week).

But Microsoft did not Stop There. With IE10 Installed On Windows7 or Pre-Installed with Windows8 you will notice that that trying to run 32 bit version of IE will actually result in you running IE’s 64 bit edition. As you can see in the figure below which shows SysInternals ProcessMonitor the 32 Bit IE actually terminates itself right after it launches the 64 bit version IE. Thus it is imperative that no one actually tries to launch the browser using CreateProcess API. That’s because the ProcessID obtained from CreateProcess API would be inaccurate.

Running IE10 32-bit on Windows7 X64 results in IE10 Creating a 64-bit IE and terminating it's 32bit process.


Now let’s backup a bit and go back to IE9. When you launched IE9 X64 or IE 32-bit you will have noticed that it creates two processes. One Process for the parent and one for the default Tab. But if you created a second tab you would notice that IE would create a second child process that would be associated to that new Tab. Yet somehow arbitrarily IE would decide to stop there. If you created any other tabs IE9 (64-bit or 32-bit) would continue to operate with Three Processes.

See below that IE9 with Two Tabs, Three Tabs or Five Tabs would all have 3 iexplore.exe processes.

Windows 7 Running IE9 with Two Open Tabs which results in three iexplore.exe processes

Windows7 IE9 With Three Three Open Tabs which results in Three iexplore.exe processes

Windows 7 Internet Explorer 9 Running Five Tabs Which results in Three iexplore.exe processes

But perhaps a more important observation with IE9 would be that if the parent Process was a 32-bit IE9, all child tabs would also be associated with so called worker processes that would be IE 32-bit as well.

Conversely if the Parent Process was a 64-bit IE9 then all the child processes associated with tabs would be 64-bit processes. See below for a Widows7 X64 running IE9 64-bit.

64bit IE9 Running with Five Tabs open which results in three iexplore.exe


As I said before IE10 shipped with Windows8. IE10 took that arbitrary limitation of IE9 that limited child process to only two process away. As you can see below, IE10 actually always has a parent process and then one child process for each tab that is open on the UI.

Running IE10-32 bit on Windows7 X64:

IE10 32-bit Running On Windows7 x64 Five Tabs Open which results in one 64-bit iexplore.exe and 5 32-bit iexplore.exe processes

Running in IE10-64 bit on Windows7 X64. Notice that the Process "topology" (layout) is exactly the same as running IE10-32 bit edition. Notice in both Cases the parent is process is the only one that is 64-bit. But we will cover this in more depth further down.

Clicking on IE10 64-bit under C:\program files\internet explorer\iexplore.exe results in one 64-bit ieexplore.exe and five 32-bit iexplore.exe processes


Frontally IE11 that is about to ship with Windows8 on October 14th 2013 has pretty much stayed consistent with IE10 behavior. But I did notice one extra modification with IE11 as well. IE11 just like IE10 launches one process per browser tab. But an important distinction occurs and that is as soon you start typing the in the browser address-bar which is actually hosted by the parent 64-bit process, IE11 launches a child 64-bit process. This child process is presumably used for things such as fetching a list of suggestions from a Microsoft Server. Unfortunately for the purpose of This Article I did not have the time to hookup Fiddler and see what the Http Server that ends with the domain name “” is all about. I would not be surprised though if this is some kind of REST call to a web service. Fortunately after a minute of idleness this process shuts itself down and goes away.

SysInternals Process Explorer Property, Windows 8.1 IE 11 worker Process that activates itself when you type in DNS name in the Address-bar

The illusion of 64-bit browser:

I think Microsoft correctly realized that two releases of IE8 and IE9 had not managed to convince most developers to release ActiveX components that would actually run in the 64-bit address space. So Starting with IE10 They decided to play a neat trick. The Parent Process when running Internet Explorer Version 10.0 or Version 11.0 would always be a 64-bit process on Windows X64 editions. But they decided that all the child processes that would be created for accommodating tabbed browsing would be actually 32-bit processes. On the surface this really sounds like Microsoft complicated things way too far. But in Reality the process that renders the Tab actually might run an ActiveX control like flash, Browser Plugins such BHOs and accelerators. So if all the Browser plugins insist on shipping as 32-bit .ocx and .dll why not ensure that the tab process which is responsible to load plugins is always a 32-bit process as well. Notice in Windows X64 a 64 bit process (.exe) can only load 64-bit components (.DLL) and similarly a 32-bit .EXE would only be able to load 32-bit DLLs. So that’s how suddenly on Windows8 we felt like we are running a 64-bit IE but in reality we were really running 32-bit IE.

For illustration purposes I went to which uses Flash. Thanks to SysInternals’ Process Explorer which allows one to explore what Dlls Any Given Process has loaded I am able to Find out which .OCX (Active X) is actually IE10’s Worker Process using for brining flash to you. But as mentioned before this is an over-simplication; since the Flash OCX launches a 64-bit Flash Process that does the grunt of the work. But further exploration of that process is out of the scope of this article. Please Observe that the Flash OCX is actually under C:\Windows\SysWOW64\ which implies it is indeed a 32-bit component.

Windows 7 X64 Running Internet Explorer 10.0 (IE10) With Adobe (Macromedia Flash) Activex .OCX loaded

Final Note:

IE10 and IE11 have a funny phenomenon which had I had never seen before. Yes the Tabs are rendered by 32-bit Processes and the Main IE Windows which contains the Address-Bar is a 64-bit Process. But What’s interesting is that the each Tab is a Window that is a child window of the Parent IE which hosts the Address Bar. I was able to confirm this using Spy++ and to my pleasant surprise there is nothing wrong with a Window contained in a 32-bit Process to call a Window in a 64-bit Process its parent. Perhaps this is possible because HWND are not really pointers but really they are IDs associated with a Window. Therefore Windows could always limit an HWND on X64 bit process to the lower 32-bit of that int64.