ESET NOD32 4.2.71.2 issues with Visual Studio 2012 SP1

Hi -- I hope I have the right forum -- if not please let me know where I should be posting this.

My company's IT has recently switched us from MS ForeFront to ESET NOD32 4.2.71.2 and I have been experiencing some problems with Visual Studio under certain circumstances.

The bottom line is that ESET (ekrn.exe) seems to be locking certain EXE and DLL files for up to a couple minutes occasionally. There are two specific scenarios I have identified that are causing issues with ESET that were not a problem with ForeFront:

#1: After build, exe gets locked for a couple minutes:

Create a small console application in Visual Studio, build it, and use CTRL-F5 to run it in a console. After it opens, close the console again. Try and rebuild the project immediately (e.g. with CTRL-SHIFT-B), and an error occurs that the exe file to build to is locked (Access Denied) after 10 tries. Try again and get the same error. Wait a couple minutes and the file will finally be freed up even though it was no longer being used anyway.

Using ProcMon from SysInternals Suite from Microsoft, I was able to determine that ESET (ekrn.exe) is locking the exe file when you run it from Visual Studio, and does not seem to be unlocking it again in a timely manner – e.g. at least 60-120 seconds if not longer in some cases.

#2: (More complicated scenario, but probably a similar cause)
Create a new solution, SQL 2008 Database project, and SQL 2008 CLR project. Reference the SQL CLR project from the database project. The SQL CLR project compiles to a DLL. Deploy the SQL CLR project to a SQL database somewhere.

Doing a Schema Compares between the project referencing the SQL CLR DLL and the database where it was deployed to will intermittently crash Visual Studio and the embedded exception is Access Denied in SQL Server Compact Edition -- indicating most likely that ESET has the SQL CLR DLL file locked (or a temporary copy of a DLL of the CLR assembly from the remote server used in the schema compare).

In this solution scenario, sometimes Visual Studio will crash simply when it opens and build the database project in the background.

Also, deploys will sometimes fail with the same error (Access Denied to file).

In all of the above three cases, using a tool like ProcessHacker to kill ekrn.exe right before the operation will allow the operation to complete without crashing or errors.

What is the best way to resolve this issue? I need to get our IT dept some help so they can fix this and we can get back to some level of productivity.

 

I'm not entirely sure why they've chosen to install version 4.2.71.2 vs. 6.0.308.0 but outside of that, here's a possible solution:

Add the Visual Studio program files folder to the exempt from scan. Here's a KB Article on how to do this: How do I exclude certain files or folders from Real-time scanning?

 

Just to clarify, do you mean that the visual studio PROJECT working folders, where the build and other processes are creating and deleting the EXEs and DLLs that are getting locked, is what needs to be excluded, or the actual program files for Visual Studio? Seem it would be the former to me. But that would essentially mean doing it for my entire Documents folder since there are many projects in that tree. Also, if this is a known issue, does verion 6 fix it? Thanks

 

I'd suggest upgrading to v6 and see if the problem persists.

 

I'd like to try that, but unfortunately I don't have any control over this -- I will suggest it to the IT group however.

 

using version 6, i don't have the problem you described in the first scenario. i don't use sql 2008

 

I have VS 2012 and SQL Server 2008/2012 and no issues with 6, other than Outlook sends...

 

This indicates that you're using ESE NOD32 Antivirus Business Edition 4.2.71. In that case, the administrators should consider upgrade to Endpoint Antivirus which also addresses issues present in the v4 product line.
With v4.2 installed, please confirm or deny that disabling real-time protection (just for a test) makes a difference. If so, create a Process Monitor log from the moment you reproduce the issue, compress it, upload it to a safe location and PM me the download link.

 

We're seeing the same issue.

We have most of our users on windows 7 pro x64 with ESET NOD32 AV Business Edition 4.2.871.2.

But we have also verified the issue exists on Windows 8 x64 Pro with ESET NOD32 5.0.2214.

Adding exemptions does not appear to resolve the issue, only turning off realtime scanning appears to solve the issue. As a result a couple of our developers are now running with their real-time scanner module disabled.

 

Please create 2 Process Monitor logs. One with real-time protection disabled when the issue doesn't occur and the other one with RTP enabled. When done, compress the logs, upload them to a safe location and PM me the download link.

 

I should have the reports available for you within the next couple of days.

 

Hello,

Just to add to Marcos' comments about upgrading, ESET Endpoint Antivirus is the replacement for ESET NOD32 Antivirus Business Edition, which is no longer being actively developed. It is a free upgrade for all licensed users of the older program.

Regards,

Aryeh Goretsky

 

I have the log files. I'll have to create a FTA account for you to access them, one is over 700MB.

Plan

Mackintire

 

Log Files Sent.

You have a private message waiting.

 

There's a problem with NuGet continually opening and closing extremely large (16 MB) htm log files. Try excluding the folder C:\FusionLog\Default\NuGet.exe and see if it makes a difference.

 

That appeared to resolve the issue, I'm going to follow up with a developers explanation on why this default behavior with Visual Studio could be very bad for ESET.