IE9 hang......with no window?
Hi there
Recently we have had an issue with our published XenApp 6 desktop platform not performing very well. We looked into the normal metrics and we saw the CPU usage on particular servers could be high.
Initially we checked the process list and saw that iexplore.exe for one user would usually be the hungry process, taking lots of CPU. This was originally associated with someone browsing to a site they shouldn't have. The DFSS service which is on by default for Windows 2008 R2 RDS servers stopped this being a tragedy as other processes recevied CPU time when required, but there is only so far DFSS can go.
Some information on DFSS
http://blogs.msdn.com/b/rds/archive/2009/05/29/using-wsrm-to-control-rds-dynamic-fair-share-scheduling.aspx
On further inspection (actually calling the user to understand their experience) it was clear that no process window was open at all and that the iexplore.exe process had simply hung. Ending the process had no effect on the user whatsoever. Some of the users mentioned that IE had become unresponsive, but the window closed correctly.
Now this was difficult to track, I couldn't find a way to identify this hung process with RDS or XenApp. I tried all the normal methods like ProcDump, WhatisHang, ProcessExplorer....but all of them didn't recognise the process was in a hung state.
Trying to reproduce the fault was very difficult, however not impossible.
Open 1st tab with www.bbc.co.uk
Open 2nd tab with the browser hang test from Microsoft http://ie.microsoft.com/testdrive/Browser/BrowserHangTest/Default.html
Click the button which says Click to Hang Temporarily
Click the red Close button in the top corner
Click button Close all tabs
What occurred in our environment was the iexplore.exe process remained after closing the window and would take lots of CPU processing. Like this!
See iexplore.exe taking 20%.....but no IE9 window is open.
After some investigation I remebered that a group policy was created call Set Tab Proccess Growth. The idea behind this registry key is to decrease the amount of processes loaded within an Internet Explorer window. By default RDS sets this figure to 1, which means a new iexplore.exe process will open with every tab. This is fine, it allows each tab to have it's own process. If one of these hangs or crashes, the rest should be unaffected.
The downside is the extra memory usage it creates e.g. a 4 tab IE9 window uses 230MB, however if we change this value to 0 (1 iexplore.exe process for unlimited tabs) the memory usage is only about 170MB. It doesn't sound a lot, but multiply that by 20 people and another 1GB of RAM is required on the server.
In our environment it was set to 0 to decrease the memory overhead.
Changing this value back to default (1) solves this issue in my repro environment. We are testing this across the board but I am confident that this will solve the problem.
This setting can be change in Group Policy under
Computer configuration > Windows Components > Internet Explorer > Set tab process Growth (not configued or 1)
Or in registry by editing keys
HKCU\Software\Microsoft\Internet Explorer\Main\ DWORD value TabProcGrowth = 1
HKLM\Software\Microsoft\Internet Explorer\Main\ DWORD value TabProcGrowth = 1
More details on this feature can be found here.
http://blogs.msdn.com/b/askie/archive/2009/03/09/opening-a-new-tab-may-launch-a-new-process-with-internet-explorer-8-0.aspx
My thought is that this feature does not play nicely with IE9 hang resistance feature at all. I do not have definitive proof of this, but this GPO never had a problem with IE8 previously. I suspect that as each tab shares the main iexplore.exe process, it cannot resist the hang as designed.
Some more details on IE9 Hang Resistance below.
http://blogs.msdn.com/b/ie/archive/2011/04/19/hang-resistance-in-ie9.aspx
Thanks
Sam
Google +
Recently we have had an issue with our published XenApp 6 desktop platform not performing very well. We looked into the normal metrics and we saw the CPU usage on particular servers could be high.
Initially we checked the process list and saw that iexplore.exe for one user would usually be the hungry process, taking lots of CPU. This was originally associated with someone browsing to a site they shouldn't have. The DFSS service which is on by default for Windows 2008 R2 RDS servers stopped this being a tragedy as other processes recevied CPU time when required, but there is only so far DFSS can go.
Some information on DFSS
http://blogs.msdn.com/b/rds/archive/2009/05/29/using-wsrm-to-control-rds-dynamic-fair-share-scheduling.aspx
On further inspection (actually calling the user to understand their experience) it was clear that no process window was open at all and that the iexplore.exe process had simply hung. Ending the process had no effect on the user whatsoever. Some of the users mentioned that IE had become unresponsive, but the window closed correctly.
Now this was difficult to track, I couldn't find a way to identify this hung process with RDS or XenApp. I tried all the normal methods like ProcDump, WhatisHang, ProcessExplorer....but all of them didn't recognise the process was in a hung state.
Trying to reproduce the fault was very difficult, however not impossible.
Open 1st tab with www.bbc.co.uk
Open 2nd tab with the browser hang test from Microsoft http://ie.microsoft.com/testdrive/Browser/BrowserHangTest/Default.html
Click the button which says Click to Hang Temporarily
Click the red Close button in the top corner
Click button Close all tabs
What occurred in our environment was the iexplore.exe process remained after closing the window and would take lots of CPU processing. Like this!
See iexplore.exe taking 20%.....but no IE9 window is open.
After some investigation I remebered that a group policy was created call Set Tab Proccess Growth. The idea behind this registry key is to decrease the amount of processes loaded within an Internet Explorer window. By default RDS sets this figure to 1, which means a new iexplore.exe process will open with every tab. This is fine, it allows each tab to have it's own process. If one of these hangs or crashes, the rest should be unaffected.
The downside is the extra memory usage it creates e.g. a 4 tab IE9 window uses 230MB, however if we change this value to 0 (1 iexplore.exe process for unlimited tabs) the memory usage is only about 170MB. It doesn't sound a lot, but multiply that by 20 people and another 1GB of RAM is required on the server.
In our environment it was set to 0 to decrease the memory overhead.
Changing this value back to default (1) solves this issue in my repro environment. We are testing this across the board but I am confident that this will solve the problem.
This setting can be change in Group Policy under
Computer configuration > Windows Components > Internet Explorer > Set tab process Growth (not configued or 1)
User configuration > Windows Components > Internet Explorer
> Set tab process Growth (not configured or 1)
Or in registry by editing keys
HKCU\Software\Microsoft\Internet Explorer\Main\ DWORD value TabProcGrowth = 1
HKLM\Software\Microsoft\Internet Explorer\Main\ DWORD value TabProcGrowth = 1
More details on this feature can be found here.
http://blogs.msdn.com/b/askie/archive/2009/03/09/opening-a-new-tab-may-launch-a-new-process-with-internet-explorer-8-0.aspx
My thought is that this feature does not play nicely with IE9 hang resistance feature at all. I do not have definitive proof of this, but this GPO never had a problem with IE8 previously. I suspect that as each tab shares the main iexplore.exe process, it cannot resist the hang as designed.
Some more details on IE9 Hang Resistance below.
http://blogs.msdn.com/b/ie/archive/2011/04/19/hang-resistance-in-ie9.aspx
Thanks
Sam
Google +
Comments
Post a Comment