Associate
- Joined
- 3 Oct 2007
- Posts
- 795
The Problem
We're currently migrating our entire 1500+ machines from Windows XP to Windows 7 and started finding our file share server CPU, specifically the 'system' process and srv2.sys, taking a hammering.
This occurs from 8am through till 5pm ish - often permanently during this time.
The server is a VMWare hosted Windows Server 2008R2 in a failover cluster, and the problem will occur on whichever server is running the resource.
Backend memory and disk performance looks totally normal, it is only CPU taking the brunt.
Diagnosis
We were able to identify a user that was causing the issue to happen, and have been able to recreate the problem with a test account and PC under the following conditions:
> Windows 7 PC (Tested with Xp and can't recreate)
> Access to 2 folders that contain ~150K files (Remove access and can't recreate the issue)
> Using the Navigation Pane (left hand pane) in explorer, expand a folder and a couple of subfolders (not the huge folders listed above) and watch the CPU usage on the server go crazy.
> Once you close the explorer window the CPU on the server drops back to 'normal'
What we've done
We've patched up both the server and client with the latest hotfix rollup - KB2775511, and switched off AV on both client and server to rule that out.
We've switched on the Windows Search Service for the 2 huge folders (Properties only, they're rtf's so would have taken an age to index the contents too) and still have the issue.
When we run procmon on the client, we can see that explorer.exe goes off and does a 'querydirectory' for everything on the mapped drive, not just what was being accessed.
The Dilemma
Our next step is to disable the navigation pane for all users (There is no GPO for this either....) as a temporary workaround. Our worst case scenario is someone leaving their machine on and having this issue roll on into the backup window and cause issues there.
We want to fix this properly, but we're struggling to come up with any more resolutions or troubleshooting for the problem.
Does anyone have any helpful advice on our next steps?
We're currently migrating our entire 1500+ machines from Windows XP to Windows 7 and started finding our file share server CPU, specifically the 'system' process and srv2.sys, taking a hammering.
This occurs from 8am through till 5pm ish - often permanently during this time.
The server is a VMWare hosted Windows Server 2008R2 in a failover cluster, and the problem will occur on whichever server is running the resource.
Backend memory and disk performance looks totally normal, it is only CPU taking the brunt.
Diagnosis
We were able to identify a user that was causing the issue to happen, and have been able to recreate the problem with a test account and PC under the following conditions:
> Windows 7 PC (Tested with Xp and can't recreate)
> Access to 2 folders that contain ~150K files (Remove access and can't recreate the issue)
> Using the Navigation Pane (left hand pane) in explorer, expand a folder and a couple of subfolders (not the huge folders listed above) and watch the CPU usage on the server go crazy.
> Once you close the explorer window the CPU on the server drops back to 'normal'
What we've done
We've patched up both the server and client with the latest hotfix rollup - KB2775511, and switched off AV on both client and server to rule that out.
We've switched on the Windows Search Service for the 2 huge folders (Properties only, they're rtf's so would have taken an age to index the contents too) and still have the issue.
When we run procmon on the client, we can see that explorer.exe goes off and does a 'querydirectory' for everything on the mapped drive, not just what was being accessed.
The Dilemma
Our next step is to disable the navigation pane for all users (There is no GPO for this either....) as a temporary workaround. Our worst case scenario is someone leaving their machine on and having this issue roll on into the backup window and cause issues there.
We want to fix this properly, but we're struggling to come up with any more resolutions or troubleshooting for the problem.
Does anyone have any helpful advice on our next steps?
