dllcache accessed at startup - hard disk thrashing

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

I am running win2k (sp4) on a machine that has been completely cleaned from
spyware and viruses, and that has been defragmented. At startup, the hard
drive
is accessed for a long time after logon. When this finishes, the system works
fine.

I used filemon from sysinternals to find the reason for the hard drive
thrashing and found that winlogon.exe accesses every file in the dllcache.
Some tests on other win2k machines reveal that there the dllcache is also
accessed, but the difference is that there, most files are only opened and
closed, not read (with OPEN and CLOSE, as reported by FileMon), whereas on
the machine with hard disk thrashing, files are actually read, and with
different calls according to FileMon. There the sequence is, per file in
ddlcache:
IRP_MJ_CREATE
IRP_MJ_CLEANUP
IRP_MJ_READ* (don't know what the * means)
IRP_MJ_READ*
IRP_MJ_CLEANUP
IRP_MJ_CLOSE

So probably the thrashing is caused by the lenghtier file processing.
But then my question is: what causes this difference? I am not a
programmer and also don't know anything about the difference
between "normal" calls and calls like IRP_MJ_whatever.
Has anyone seen this behaviour?

Thanks in advance,

Patrick
 
patrickw said:
Hi,

I am running win2k (sp4) on a machine that has been completely cleaned from
spyware and viruses, and that has been defragmented. At startup, the hard
drive
is accessed for a long time after logon. When this finishes, the system works
fine.

I used filemon from sysinternals to find the reason for the hard drive
thrashing and found that winlogon.exe accesses every file in the dllcache.
Some tests on other win2k machines reveal that there the dllcache is also
accessed, but the difference is that there, most files are only opened and
closed, not read (with OPEN and CLOSE, as reported by FileMon), whereas on
the machine with hard disk thrashing, files are actually read, and with
different calls according to FileMon. There the sequence is, per file in
ddlcache:
IRP_MJ_CREATE
IRP_MJ_CLEANUP
IRP_MJ_READ* (don't know what the * means)
IRP_MJ_READ*
IRP_MJ_CLEANUP
IRP_MJ_CLOSE

So probably the thrashing is caused by the lenghtier file processing.
But then my question is: what causes this difference? I am not a
programmer and also don't know anything about the difference
between "normal" calls and calls like IRP_MJ_whatever.
Has anyone seen this behaviour?

Thanks in advance,

Patrick
Click to expand...
 
The thrashing is probably constant paging due to low RAM

--

Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

:
| Hi,
|
| I am running win2k (sp4) on a machine that has been completely cleaned
from
| spyware and viruses, and that has been defragmented. At startup, the hard
| drive
| is accessed for a long time after logon. When this finishes, the system
works
| fine.
|
| I used filemon from sysinternals to find the reason for the hard drive
| thrashing and found that winlogon.exe accesses every file in the dllcache.
| Some tests on other win2k machines reveal that there the dllcache is also
| accessed, but the difference is that there, most files are only opened and
| closed, not read (with OPEN and CLOSE, as reported by FileMon), whereas on
| the machine with hard disk thrashing, files are actually read, and with
| different calls according to FileMon. There the sequence is, per file in
| ddlcache:
| IRP_MJ_CREATE
| IRP_MJ_CLEANUP
| IRP_MJ_READ* (don't know what the * means)
| IRP_MJ_READ*
| IRP_MJ_CLEANUP
| IRP_MJ_CLOSE
|
| So probably the thrashing is caused by the lenghtier file processing.
| But then my question is: what causes this difference? I am not a
| programmer and also don't know anything about the difference
| between "normal" calls and calls like IRP_MJ_whatever.
| Has anyone seen this behaviour?
|
| Thanks in advance,
|
| Patrick
|
 
Your system modules are incosistent and Windows's default
*RunTimeChecker* is executing itself to replace these corrupted modules
from *WINNT\SYSTEM32\DLLCACHE* directory.

You can disable sfc/wfc if you want using registry editor
(regedit.exe), navigate to the following registry key and set the entry
and value as mentioned below:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Windows File
Protection

Registry Values

SFCDisable (REG_DWORD)

0 = enabled (default)

OR

Perform a full scan using *sfc /scannow* in safe mode. Next time it
should stop searching files in DLLCACHE directory.
 
momisanin said:
Your system modules are incosistent and Windows's default
*RunTimeChecker* is executing itself to replace these corrupted modules
from *WINNT\SYSTEM32\DLLCACHE* directory.

You can disable sfc/wfc if you want using registry editor
(regedit.exe), navigate to the following registry key and set the entry
and value as mentioned below:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Windows File
Protection

Registry Values

SFCDisable (REG_DWORD)

0 = enabled (default)

OR

Perform a full scan using *sfc /scannow* in safe mode. Next time it
should stop searching files in DLLCACHE directory.
Click to expand...

It seems like this is leading somewhere. Let me first describe what I had
already tried before. I had already played with sfc /scannow and regedit, but
it did not help. I even completely emptied the dllcache by
putting it's size to 0 and purgeing it. After that, the thrashing has gone
of course but I no longer have the security that's behind all this. When
then the
cache is repopulated again by increasing its size, I was hoping that some
corrupt internal structure would have been rebuilt, but that's not the case.
Thrashing reappears.

But now I realize that all experiments with sfc so far were done in normal
mode,
not in safe mode, as you suggest. When I tried it in safe mode, I got an error
message: "Windows file protection could not initiate a scan of protected
system
files" Specific error code is 0x000006ba [the RPC service is unavailable]
I don't know if this error is related to the thrashing.

I googled this and found some suggestions, but what I tried
did not help so far (I looked at http://support.microsoft.com/?kbid=296241,
and also used the command net start rpcss, only to learn that the requested
service had already been started).

In reply to Dave Patrick:
I don't think that it is related to low RAM because one of the other
w2k machines that I looked at, behaves normally with a lower amount
of memory (128M versus 192M on the thrashing machine).
 
Update:

sfc does not run in safe mode. Windows File Protection needs to be active and
apparently it isn't in safe mode. I checked it on three w2k machines, and
later found among others this article that confirms it:
http://smallvoid.com/tweak/winnt/install.html

Patrick

patrickw said:
momisanin said:
Your system modules are incosistent and Windows's default
*RunTimeChecker* is executing itself to replace these corrupted modules
from *WINNT\SYSTEM32\DLLCACHE* directory.

You can disable sfc/wfc if you want using registry editor
(regedit.exe), navigate to the following registry key and set the entry
and value as mentioned below:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Windows File
Protection

Registry Values

SFCDisable (REG_DWORD)

0 = enabled (default)

OR

Perform a full scan using *sfc /scannow* in safe mode. Next time it
should stop searching files in DLLCACHE directory.
Click to expand...

It seems like this is leading somewhere. Let me first describe what I had
already tried before. I had already played with sfc /scannow and regedit, but
it did not help. I even completely emptied the dllcache by
putting it's size to 0 and purgeing it. After that, the thrashing has gone
of course but I no longer have the security that's behind all this. When
then the
cache is repopulated again by increasing its size, I was hoping that some
corrupt internal structure would have been rebuilt, but that's not the case.
Thrashing reappears.

But now I realize that all experiments with sfc so far were done in normal
mode,
not in safe mode, as you suggest. When I tried it in safe mode, I got an error
message: "Windows file protection could not initiate a scan of protected
system
files" Specific error code is 0x000006ba [the RPC service is unavailable]
I don't know if this error is related to the thrashing.

I googled this and found some suggestions, but what I tried
did not help so far (I looked at http://support.microsoft.com/?kbid=296241,
and also used the command net start rpcss, only to learn that the requested
service had already been started).

In reply to Dave Patrick:
I don't think that it is related to low RAM because one of the other
w2k machines that I looked at, behaves normally with a lower amount
of memory (128M versus 192M on the thrashing machine).
Click to expand...
 
Further update:

A windows reinstallation (repair installation over the existing one) does
not solve
the problem. I don't want to do a fresh install because this is a pc from a
family
member who asked me to clean it up for her, and I don't have access to all
application cd's (and maybe she neither).
 
Maybe check this registry key:

[HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Windows NT\ CurrentVersion
\Winlogon]
SFCScan=0

Maybe check that the disk-system is configured properly and the
"trashing" is not just a slow performing disk-system.
 
Hi,

Thanks for your comments.

I already checked that key, and it was all right. I also checked the disk
itself before,
defragmented it completely, and confirmed it to be in dma mode. So I don't
think it
is a slow disk. Besides, a slow disk does not explain the difference in system
calls between good systems and the "thrashing" system.
 
Maybe check that no faulty file-system hooks have been made by
Anti-Spyware/Anti-Virus/Firewall application (Uninstall them
completely, several times if Norton and McAfee :P )

"Because Filemon intercepts IRPs, you see commands such as IRP_MJ_READ
and IRP_MJ_CREATE in Filemon's output window, rather than more familiar
commands, such as Read and Open. In Filemon's output windows, you'll
also see non-IRP command names such as FASTIO_READ and
FASTIO_QUERY_BASIC_INFORMATION. These commands represent the Fast I/O
shortcut path that NT uses to speak with file system drivers. This path
is a shortcut because it bypasses the creation of IRPs, and with the
path, the I/O Manager directly invokes functions within file system
drivers to carry out requests. You can see both IRP-related and Fast
I/O commands because file system drivers can service Fast I/O requests
only if the accessed file data is in the file system cache and several
other conditions hold. If a file system driver returns a Fast I/O
command status of FALSE, the I/O Manager falls back on the IRP-based
request path." (Taken from page 2)

http://www.windowsitpro.com/Articles/Index.cfm?ArticleID=4795
 
Interesting article. But all systems that I checked, except the misbehaving
one, show OPEN and CLOSE commands in FileMon, and not their IRP_MJ_
counterpart. Also, on the misbehaving machine, more calls per file are used
(see the sequence shown in the first article in this thread). The article
gives the impression that I should always see the IRP_MJ_ commands.

At least one of the systems with the normal OPEN and CLOSE commands seen by
FileMon, has the same antivirus and anti-spyware software than the
"thrashing" machine. But I will see what happens when I uninstall these, when
I get the chance, because in the meantime the system has returned as it is to
the owner. I still have a ghost copy of its c: partition, but can't get it to
boot, not even in safe mode, on other hardware (I was hoping to continue
testing on other hardware).
 
Back
Top