I am in the process of trying to optimize the boot process of our 700 Windows XP workstations, we regularly have complaints about the start-up and login times on site workstations.

Looking at this in two parts, part one using BootVis to monitor and inspect the boot process; part two using Process Monitor to monitor the login process. Using BootVis' "Boot Done" way point as the metric, I utilized a VMWare workstation virtual machine that has been used for about 18 months as a general purpose testing machine (thus fairly typical of on site machines). I used a snapshot to return the Virtual Machine to the initial state before each test.

From the logs and report that BootVis created the most obvious delay was from Sophos Anti-Virus on access scanner, followed at some distance by mrxsmb. I tweaked with the policies for the machine (ensuring I forced Sophos to update twice each time) and came up with the following numbers:

  • Scan All Files, On Read: 260 seconds
  • Scan All Files, On Write: 160 seconds
  • Scan Executables, On Read and On Write: 111 seconds
  • Scan Executables, On Read: 99 seconds
  • Scan Executables, On Write: 95 seconds
  • On-Access Scanning Disabled: 102 seconds

The above tends to suggest that Scanning All Files, On Read is by far the most expensive operation (and probably totally unnecessary). I can't quite comprehend why disabling on-access scanning actually slows down the boot sequence however fractionally fractionally. The final three results are pretty much the same, which means I must use other factors to influence my decision as to selecting Scan Executables, On Read or On Write.


I did some more tests, on the same virtual machine (at a different time of day, so they can not be compared directly with the above results:

  • Sophos Not Installed: 67.4 seconds (average over 5 tests)
  • Scan Executables, On Read: 84.5 seconds (average over 5 tests)
  • Scan Executables, On Write: 85 seconds (average over 5 tests)

The averaging causes the values for On Read and On Write to converge further, it is interesting to see that using Sophos scan Executable Files only adds a 21% performance overhead over Sophos not being installed.

So what other considerations should I make when configuring On-Access scanning to improve the boot time?

  • I am interested in this too. We are using Eset NOD32 (previously Trendmicro Officescan) and see poor startup & login times. It is especially painful on laptops (Thinkpads) with slower disks.
    – Doug Luxem
    Commented Jun 16, 2009 at 18:38
  • Hang on? do you mean you used to use Trend Micro OfficeScan and now you use ESET NOD32? or ESET NOD32 used to be called Trendmicro Officescan? I use NOD32 on administrator workstations, I can probably install it in a Virtual Machine and do some testing with BootViz tomorrow. Of course it isn't just boot time that can be affected by over aggressive on-access anti-virus. Commented Jun 16, 2009 at 20:16
  • NOD32 and Trend Micro OfficeScan aren't related. I think he meant the "we used to use" interpretation of what he said. Commented Jun 16, 2009 at 22:25
  • Sorry, we switched from Trend to NOD32.
    – Doug Luxem
    Commented Jun 24, 2009 at 16:52

3 Answers 3


We are currently investigating SOPHOS speed issues and I have come up with the following suggestions which in our winxp sp3 environment has made a fair bit of difference:

  1. Exclude these files at within the On-Access section:

    • c:\windows\system32\authz.dll
    • c:\windows\system32\drivers\srv.sys
    • c:\windows\system32\es.dll
    • c:\windows\system32\netman.dll
    • c:\windows\system32\oakley.dll
    • c:\windows\system32\pstorsvc.dll
    • c:\windows\system32\rasadhlp.dll
    • c:\windows\system32\regsvc.dll
    • c:\windows\system32\winipsec.dll They are startup files and aslong as you have full system scans running at some point, you shuold be fine.
  2. The second thing to do is turn off checking for updates at startup. This is a tiny bit risky as thats a key point for new viruses can attack, but you can combat this by have regular 30 min checks for updates meaning you are never more than half an hour out. To turn of checking for updates do this:

alt text http://www.sophos.com/images/common/misc/27646.gif

After implementing these changes there was a noteable speed increase from power on to desktop.

I hope this helps.



I have not used Sophos so I am not sure if there is something similar, but in Symantec there is a registry change you can make that disables the full system scan on startup. Without this, Symantec will scan everything when the system first starts potentially making things very slow for the first little while after the system boots up. There might be a similar setting in Sophos.

Of course disabling this is potentially a slight downgrade in security. There is a reason why they have a startup scan.

  • Sophos doesn't do a full system scan at start up, in my case I scheduled Sophos to do a fairly aggressive full system scan at 1530 on a Monday, which works well in our particular Use Case. Commented Jun 16, 2009 at 18:18

We had the same problem with McAfee on our older machines. These machines don't have access to the internet, so I wrote a boot script to delay the start of the services a few minutes.

' Place script in C:\Documents and Settings\All Users\Start Menu\Programs\Startup
' The McShield and McTaskManager services must be set to Manual

Wscript.sleep 12000 'Delay start for 2 minutes

Set objWMIService = GetObject ("winmgmts:{impersonationLevel=impersonate, (Debug)}\\.\root\cimv2")

StartService "McShield"     
StartService "McTaskManager"

Function StartService (strService)
    Dim intStatus, colServices, objService
    Set colServices = objWMIService.ExecQuery ("Select * from Win32_Service Where Name = " & chr(39) & strService & chr(39))
    For Each objService in colServices
        intStatus = objService.StartService
End Function

This might not be practical for your situation, but the solution worked well for us.

  • Presuming those processes provide you with on-access protection, your computers are unprotected starting up. In a school, this is probably not an acceptable compromise as we do have malicious users who would use it to their advantage. It is a good solution for a trusted environment however. Thanks for your input. Commented Jun 24, 2009 at 21:48
  • 1
    I suspected that might be the case, but it's better to offer the information than be holding the solution and not share.
    – KevinH
    Commented Jun 25, 2009 at 0:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .