ekrn running wild on DC - NOT CPU usage issue

Have 3 DCs in 3 sites, RA on each one & 672 client as well. RAs are all running the HTTP mirror.

On one of these machines only, the ekrn.exe process seems to get out of control and users of this site experience frequent problems with responsiveness of this server - affecting authentication at times. The CPU usage is fine, hovers around the usual 5-10% but currently it has 57,000 open handles and a Virtual Memory size of around 500Mb - which is 10x more than the next process. The open handles though is the biggest problem as the VM size will be a result of the number of open handles.

Using Process Explorer I can see that all the excess handles are of type "Token" with name "NT AUTHORITY/SYSTEM:3e7", which does not appear on either of the other two DCs running the same combination of Eset apps.

Additionally, the era.exe & ehttpserv processes regularly spike to 50% CPU usage and usually remain there until killed, though sometimes recede on their own - but not the ekrn process, this remains at low CPU usage.

We also get the following errors in the Event Log on this server quite frequently:

Error: "UploadData: Remote select failed, code -103"

Error: "FireEvents internal_renaming_event failed (RES code -103)"

Error: "CCServiceRoutine(HandleInformation): unable to get configuration (Client - Configuration) for '%client name removed%' (connection '%client IP removed%:13067', code 9)"

On top of this the ekrn process produces application faults from time to time and the era process crashes on occasion as well.

This is all less than a couple of weeks after installing the 3.0 client over the top of the 2.7 version. I've already tried removing & reinstalling & that hasn't helped the situation.

This machine also has WSUS & therefore SQL Express, whose databases are excluded from scanning.

Any thoughts would be much appreciated..

 

Should mention that this is W2K3/SP2 x86 std... cheers

 

We had a similar issue on the first DC I put 3.0 on.

Ends up that when I put 3.0 on, it didn't properly uninstall the nonpnp drivers from 2.7.

The fix for me was to first remove 3.0, reboot two times (not just once.)


Now go into device manager and select View / Hidden Devices.

In non-plug and play drivers you will see AMON and nod32drv. Right click and select to uninstall. Select no to reboot now.

After both are removed, reboot. Now reinstall Nod32 3.0.

We have actually had to do this process on many of our servers.

 

Did you set up exclusions for the database and log files in NTDS? File locking there could cause authentication delays.

 

Hi edwin, cheers for that, I thought for a second that must have been it, but no AMON nor nod32drv are visible when I check there... there is however EAMON which I guess is the new version... had my hopes up there, darn it

Smacky they were configured originally in the 2.7 so I assumed they would be pulled over, however they don't appear to be there so that could be it. Will let y'all know how I get on..

 

Woooah, added those exclusions to ntds & ntfrs & the session sprung back to almost-full responsiveness in a matter of seconds.. magic

 

Yeah, it is the same file locking conflict you tend to see with databases and AV programs. Nod32 sees that NTDS is changed by some AD transaction so it tries to scan it and in the mean time a bunch of other transactions pile up because ekrn.exe is holding a lock on the file. If you database is busy enough, you'll see authentication issues or other crazy behavior.

 

I need that full list, because I am still having that issue here.

Have removed sysvol, ntds, ntfrs - still having issues with v. 4 eating up 45,000 to 100,00k and 25-50 on the cpu.

Thanks,
RushB