Jump to content

Excessive CPU usage when running File Manager


ppgrainbow

Recommended Posts

Okay, I'm currently running Windows XP Home Edition with Service Pack 3 installed as a guest OS for a while under VMware Player and so far, I'm starting to experience some side effects to updating Windows XP.

 

For some reason, while I'm using the 32-bit Microsoft Windows File Manager (found under \WINDOWS\System32\winfile.exe and originally taken from a Windows NT 4.0 SP6a installation), the CPU utilitisation spikes up between at least 85% to 100% and stays there until I terminate the process. :(

 

Closing File Manager has no effect and the process remains there until I use either Process Explorer or the Windows Task Manager to close the misbehaving winfile.exe process. I believe that one of the security updates from June 2012 had a affect on this. I have provided a screenshot of what the problem looks like:

 

 

How can I fix the problem regarding the excessive CPU usage running Windows File Manager?

Edited by ppgrainbow
Link to comment
Share on other sites


Thank you for the help. I used Process Monitor to look at the callstack summary on winfile.exe (File Manager) as Process ID 1612 and I found that some of the files tied to winfile.exe appear to be causing problems here.

If you fail to understand what I mean, I have provided another screenshot for proof:

For some odd reason it seems that ntoskrnl.exe is using .00009% of the time fork and kernel32.dll is using .00027% of the time fork.

I'm at a loss of I don't know what to do next to correct the excessive CPU usage error. :(

Link to comment
Share on other sites

Link to comment
Share on other sites

Thanks for the help. I downloaded the 32-bit version of Debugging Tools for Windows from the Windows 7 SDK. I followed the instructions on tracking down better stack traces in Process Monitor like you asked and I configured the symbols for the following:

1. The DGBHELP.DLL path pointing to C:\DebuggingTools\dbghelp.dll
2. The symbol paths pointing to srv*C:\DebuggingTools\symcache*http://msdl.microsoft.com/download/symbols

I checked the call stack on winfile.exe and it uses modules fltmgr.sys, ntdll.dll and ntoskrnl.exe. Upon pressing the Stack tab in the Event Properties, it will look something like this:

The end result is that it fetched 17 frames fltmgr.sys on frames 0 through 3 and ntoskrnl on frames 4 through 16.

Using the Windows Debugger, I attached winfile.exe as a process and this is the final output that I received:

Microsoft ® Windows Debugger Version 6.12.0002.633 X86
Copyright © Microsoft Corporation. All rights reserved.

CommandLine: c:\windows\system32\winfile.exe
Symbol search path is: .sympath srv*C:\DebuggerTools\symcache*http://msdl.microsoft.com/download/symbols

Executable search path is:

ModLoad: 027d0000 02819000 winfile.exe
ModLoad: 7c900000 7c9b2000 ntdll.dll
ModLoad: 7c800000 7c8f6000 C:\WINDOWS\system32\kernel32.dll
ModLoad: 10000000 1000b000 c:\windows\system32\shellwr.dll
ModLoad: 7c9c0000 7d1d7000 C:\WINDOWS\system32\SHELL32.dll
ModLoad: 77dd0000 77e6b000 C:\WINDOWS\system32\ADVAPI32.dll
ModLoad: 77e70000 77f03000 C:\WINDOWS\system32\RPCRT4.dll
ModLoad: 77fe0000 77ff1000 C:\WINDOWS\system32\Secur32.dll
ModLoad: 77f10000 77f59000 C:\WINDOWS\system32\GDI32.dll
ModLoad: 7e410000 7e4a1000 C:\WINDOWS\system32\USER32.dll
ModLoad: 77c10000 77c68000 C:\WINDOWS\system32\msvcrt.dll
ModLoad: 77f60000 77fd6000 C:\WINDOWS\system32\SHLWAPI.dll
ModLoad: 5d090000 5d12a000 C:\WINDOWS\system32\COMCTL32.dll

(568.91c): Break instruction exception - code 80000003 (first chance)
eax=00241eb4 ebx=7ffd5000 ecx=00000001 edx=00000002 esi=00241f48 edi=00241eb4
eip=7c90120e esp=0012fb20 ebp=0012fc94 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202

*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll -
ntdll!DbgBreakPoint:

7c90120e cc int 3

As mentioned above, I received a "Break instruction exception - code 80000003" error and a "ERROR: Symbol file could not be found." error! In short, it appears that something is not right here.

The C:\WINDOWS\System32 sub-directory has 2,476 files in the main-sub directory and another 2,867 files in 203 sub-folders. Using symchk to check for symbols for 12 key system files that are used in winfile.exe, I get the following results:

C:\WINDOWS\System32\WINFILE.EXE: FAILED files = 0; PASSED + IGNORED files = 1
C:\WINDOWS\System32\NTDLL.DLL: FAILED files = 0; PASSED + IGNORED files = 2
C:\WINDOWS\System32\KERNEL32.DLL: FAILED files = 0; PASSED + IGNORED files = 2
C:\WINDOWS\System32\SHELLWR.DLL: FAILED - Built without debugging information; FAILED files = 1; PASSED + IGNORED files = 0
C:\WINDOWS\System32\SHELL32.DLL: FAILED files = 0; PASSED + IGNORED files = 2
C:\WINDOWS\System32\ADVAPI32.DLL: FAILED files = 0; PASSED + IGNORED files = 2
C:\WINDOWS\System32\RPCRT4.DLL: FAILED files = 0; PASSED + IGNORED files = 2
C:\WINDOWS\System32\SECUR32.DLL: FAILED files = 0; PASSED + IGNORED files = 2
C:\WINDOWS\System32\GDI32.DLL: FAILED files = 0; PASSED + IGNORED files = 2
C:\WINDOWS\System32\USER32.DLL: FAILED files = 0; PASSED + IGNORED files = 1
C:\WINDOWS\System32\MSVCRT.DLL: FAILED files = 0; PASSED + IGNORED files = 1
C:\WINDOWS\System32\SHLWAPI.DLL: FAILED files = 0; PASSED + IGNORED files = 2
C:\WINDOWS\System32\COMCTL32.DLL: FAILED files = 0; PASSED + IGNORED files = 2

So far out of the 13 files listed here, only one file SHELLWR.DLL failed symbol checking, because it is built without any debugging information while, three other files had either one passed/ignored files and nine files had at least two passed/ignored files.

The affected files were downloaded to a temporary directory under C:\DebuggingTools\symcache and later moved to C:\Symbols. Each of the 12 files have a PDB extension saved in each directory.

The timestamp and size of the files are the following:

C:\WINDOWS\System32\WINFILE.EXE: 1999-11-18 00:00:00; 250,640 bytes
C:\WINDOWS\System32\NTDLL.DLL: 2010-12-09 07:15:10; 718,336 bytes
C:\WINDOWS\System32\KERNEL32.DLL: 2012-10-02 20:58:14; 990,208 bytes
C:\WINDOWS\System32\SHELLWR.DLL: 2007-12-01 22:34:04; 27,648 bytes
C:\WINDOWS\System32\SHELL32.DLL: 2012-06-08 07:26:20; 8,462,848 bytes
C:\WINDOWS\System32\ADVAPI32.DLL: 2009-02-09 05:10:48; 128,512 bytes
C:\WINDOWS\System32\RPCRT4.DLL: 2013-05-27 18:59:38; 590,848 bytes
C:\WINDOWS\System32\SECUR32.DLL: 2009-06-25 01:25:26; 56,832 bytes
C:\WINDOWS\System32\GDI32.DLL: 2008-10-23 05:36:14; 286,720 bytes
C:\WINDOWS\System32\USER32.DLL: 2008-04-14 05:42:10; 587,560 bytes
C:\WINDOWS\System32\MSVCRT.DLL: 2008-04-14 05:42:02; 343,040 bytes
C:\WINDOWS\System32\SHLWAPI.DLL: 2009-12-08 02:23:28; 474,112 bytes
C:\WINDOWS\System32\COMCTL32.DLL: 2010-08-23 09:12:04; 617,472 bytes

Okay, looking into the files mentioned above, I'm guessing that one file, SHELL32.DLL from June 2012 might be causing this issue, but I could be wrong here.

Now, where do I go from there to investigate this hard to correct issue now? I mean that some progress has been made, but it seems that I'm not going any further.

I'm awfully sorry if this reply is long, but if nothing can be fixed, I personally hate having to re-install Windows XP SP3 update in order to eliminate this issue here. :(

Update: I'm doing a backup copy of the disk.vmdk file found in F:\WinXP directory by backing it up to the F:\WinXP\Backup directory incase something goes wrong with the operating system itself. The file where the operating system is installed in is 17.3 GB in size so far.

I tried to re-apply Windows XP SP3, but the excessive CPU usage tied to winfile.exe exists! Have you got any other ideas how to fix the excessive CPU usage tied to winfile.exe?

Edited by ppgrainbow
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...