Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Last Friday I attempted to set permissions on a folder containing multiple folders. I simply deleted one user group's access entry, then clicked Apply and was greeted with an hourglass. Pretty soon I couldn't do anything on the server without extremely lag, and started getting phone calls from users. It lasted a few minutes until I manually hit the power button, because I couldn't even log in anymore, even sitting right at the console--it soft-froze on 'applying desktop settings'.

In the sys log, we have hundreds of these entries per second starting right when I hit Apply and ending with my manual reset:

Event Type:    Error
Event Source:    Srv
Event Category:    None
Event ID:    2000
Date:        2010-11-26
Time:        8:55:01 AM
User:        N/A
Computer:    MyServer
The server's call to a system service failed unexpectedly.

For more information, see Help and Support Center at
0000: 00 00 04 00 01 00 54 00   ......T.
0008: 00 00 00 00 d0 07 00 c0   ....Ð..À
0010: 00 00 00 00 0a 01 00 c0   .......À
0018: 00 00 00 00 00 00 00 00   ........
0020: 00 00 00 00 00 00 00 00   ........
0028: 34 03 bd 00               4.½.  

But only certain seconds. Seemed to have gone in 1-4 second bursts, but still most seconds in a given minute are hit with at least a dozen entries.

Now, I still need to apply this change, but all I could find on Google did not seem to be solutions, just other people saying this or that permissions change took 1 or 2 or 22 or 28 hours of such extreme slowness. I need to make this change at some point soon and I'm wondering what I can do to increase my chances that it won't have to wait until the weekend or Christmas or I don't know what. Our server is not the newest but not too shabby (Dual Intel Xeon 3.2 GHz, 4 GB RAM, around a dozen clients) and is otherwise snappy, especially after recently kicking NetBIOS and other Win98 legacy features off our network.

Does the above event log entry indicate something I could fix to speed the whole process up? (And avoid filling my event log up!)

Update w/kern To answer tony roth's question, it says:

PathName                                  ServiceType    Started  
C:\WINDOWS\system32\DRIVERS\ACPI.sys      Kernel Driver  TRUE     
C:\WINDOWS\system32\drivers\afd.sys       Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\atapi.sys     Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\ati2mpad.sys  Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\audstub.sys   Kernel Driver  TRUE     
C:\WINDOWS\system32\drivers\Beep.sys      Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\cdrom.sys     Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\compbatt.sys  Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\cpqasm2.sys   Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\cpqcidrv.sys  Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\CPQCISSE.sys  Kernel Driver  TRUE     
C:\WINDOWS\system32\drivers\cpqcissm.sys  Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\crcdisk.sys   Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\disk.sys      Kernel Driver  TRUE     
C:\WINDOWS\system32\drivers\dmio.sys      Kernel Driver  TRUE     
C:\WINDOWS\system32\drivers\dmload.sys    Kernel Driver  TRUE     
C:\WINDOWS\system32\drivers\Fips.sys      Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\ftdisk.sys    Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\msgpc.sys     Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\hidusb.sys    Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\i8042prt.sys  Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\imapi.sys     Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\intelide.sys  Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\intelppm.sys  Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\ipsec.sys     Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\isapnp.sys    Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\kbdclass.sys  Kernel Driver  TRUE     
C:\WINDOWS\system32\drivers\KSecDD.sys    Kernel Driver  TRUE     
C:\WINDOWS\system32\drivers\mnmdd.sys     Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\mouclass.sys  Kernel Driver  TRUE     
C:\WINDOWS\system32\drivers\MountMgr.sys  Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\mssmbios.sys  Kernel Driver  TRUE     
C:\WINDOWS\system32\drivers\NDIS.sys      Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\ndistapi.sys  Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\ndiswan.sys   Kernel Driver  TRUE     
C:\WINDOWS\system32\drivers\NDProxy.sys   Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\netbt.sys     Kernel Driver  TRUE     
C:\WINDOWS\system32\drivers\npf.sys       Kernel Driver  TRUE     
C:\WINDOWS\system32\drivers\Null.sys      Kernel Driver  TRUE     
C:\WINDOWS\system32\drivers\PartMgr.sys   Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\pci.sys       Kernel Driver  TRUE     
C:\WINDOWS\system32\drivers\PCIIde.sys    Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\raspptp.sys   Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\ptilink.sys   Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\b57xp32.sys   Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\rasacd.sys    Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\rasl2tp.sys   Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\raspppoe.sys  Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\raspti.sys    Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\RDPCDD.sys    Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\rdpdr.sys     Kernel Driver  TRUE     
C:\WINDOWS\system32\drivers\RDPWD.sys     Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\redbook.sys   Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\serenum.sys   Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\serial.sys    Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\swenum.sys    Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\sysmgmt.sys   Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\tcpip.sys     Kernel Driver  TRUE     
C:\WINDOWS\system32\drivers\TDTCP.sys     Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\termdd.sys    Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\update.sys    Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\usbehci.sys   Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\usbhub.sys    Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\USBSTOR.SYS   Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\usbuhci.sys   Kernel Driver  TRUE     
C:\WINDOWS\system32\drivers\vga.sys       Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\volsnap.sys   Kernel Driver  TRUE     
C:\WINDOWS\system32\DRIVERS\wanarp.sys    Kernel Driver  TRUE     
share|improve this question
If you right-click on the folder, how many files/folders are in the folder? – Greg Askew Nov 30 '10 at 0:53
465k files in 85k folders. – Kev Nov 30 '10 at 1:14
My RDBMS on the same machine can delete that many rows without bringing the server to its knees, and also estimate how long it might be (under 30 seconds.) But in any case, what's causing the event log errors? – Kev Nov 30 '10 at 1:16
Some FS'es may be built on RDBMS but NTFS is not, so again you're comparing apples to automobiles. You're changing the ACE's on the ACL's of more than half a million file system objects. I would expect that to take a while. It's hard to give you any type of estimate but based on similar operations that I've performed I would guess that it's going to take more than 4 minutes but less than 4 hours. Also, you're probably not going to see any noticable dings to overall CPU and memory usage but I would expect to see some high disk metrics as well as seeing the file system cache getting hammered. – joeqwerty Nov 30 '10 at 3:35
one thing a rdbms system does not have to contend with is 3rd party filter drivers as in AV software which temporarily disabling is my #1 troubleshooting step on file server issues. – tony roth Nov 30 '10 at 3:49
up vote 3 down vote accepted

The comments on your question have it right, basically.

You're touching the ACEs on all the subfolders and files below the point you're changing an ACL because the API the shell calls does it.

The error you're getting in your event log from SRV.SYS is an "STATUS_PROCESS_IS_TERMINATING" (0xc000010a). It's unclear to me why you're seeing that particular error. Given that it coincided with your change to the ACL it's probably related but isn't something I've ever seen on ACL changes to deep file hierarchies on live file servers, personally.

I've changed ACLs on deeper hierarchies on live file servers w/ slower specs and vastly more active w/o issue. I suspect, as Tony Roth comments, that some third-party software (like anti-virus) may be at play in the behavior you're seeing.

share|improve this answer
How did you determine it's 0xc000010a? I only see the pattern 0xc0000000000a01 in there. – Kev Nov 30 '10 at 15:59
The only "deep" software that might have been running (minimized to tray, though) would be SysInternals' Process Explorer. I'll try again without that. – Kev Nov 30 '10 at 16:01
you may be only scanning on a scheduled basis but the AV filter is doing work all the time! – tony roth Nov 30 '10 at 16:11
It doesn't have a filter. It's ClamAV for Win (the old one, not the new cloud-based ClamWin.) – Kev Nov 30 '10 at 16:14
@Kev: You know, I'm not sure how I know that the DWORD at offset 0x14 in the data returned in an SRV event log entry is the NTSTATUS code for the error, but I do. Your event log entry is formatted as bytes, but the little-endian DWORD value at offset 0x14 is "0xc000010a". (I may know this from reading, like, "Windows NT Internals Revealed" or some such... I don't recall where I learned it.) You can see Microsoft referencing the status code in an SRV event log entry here: – Evan Anderson Dec 1 '10 at 20:03

whats the result of running the following

wmic sysdriver where "servicetype like 'kern%' and started ='true'" get pathname,started,servicetype

share|improve this answer
Thanks, added to question... – Kev Dec 1 '10 at 16:49
dang wrong query see edited answer – tony roth Dec 1 '10 at 17:03
No worries, updated again. – Kev Dec 1 '10 at 22:52
@Kev: I don't see any drivers there that don't look familiar... Hrmph... – Evan Anderson Dec 2 '10 at 1:07
a rootkit would hide everything so I'm starting to wonder about this particular server. Clamav is not really sufficient in anyway and diffently not when its a scheduled scan. Also anything thats demand start won't show up in my wmic query so you could remove the started='true' but I starting to think this path is a waste of time. Kinda confused about this one! – tony roth Dec 2 '10 at 2:49

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.