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
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.
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
See below that IE9 with Two Tabs, Three Tabs or Five Tabs would all have 3 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.
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:
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.
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 “ptr.us.xo.net” 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.
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 youtube.com 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
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.