We’ve just deployed McAfee VirusScan Enterprise v8.8 to allour client machines. Our developers are now running into an issue when trying to run a debug session in Visual Studio2012.
When starting a debug session on Visual Studio 2012 for aproject that has the start-up project Platform Target setting as ‘Any CPU’, anerror message appears stating that the MSMVMon.exe can’t be started andtherefore the debug session can’t start. If the Platform Target setting is x86 it doesstart and the debug session runs successfully.
If I disable McAfee Access Protection and On-Access Scanner,the debug session runs – therefore, I’m positive that it’s McAfee that’scausing the problem.
The McAfee clients are managed centrally, via the McAfeeePO. I’ve configured the applicable policies so that the following processes used by Visual Studio 2012 - msvsmon.exe, devenv.exe and msbuild.exe - are configured as low risk processes. I’ve also excluded the paths to VS local workspaces and the Program Files ("%ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE" and "%ProgramFiles(x86)%\Microsoft Visual Studio 11.0\Common7\IDE") from scanning.
Is there something else I need to configure in McAfee? If it's a 64-bit version of MSMVMON.exe that runs when the Platform Target setting is set to ‘Any CPU’, is it likely that it will have a slightly different name that needs to be configured in McAfee or would McAfee handle it differently?
Any help gratefully appreciated.
I will help you out, but first i will verify somthing here, could you enable AP and open it>Under common standard protection>uncheck BLOCK, REPORT for Prevent hooking of McAfee processes>click OK
Now start your debug session and look for this issue?
on 2/15/13 10:43:32 AM CST
Thank you for your reply. I applied your suggested change and unchecked 'Block' and 'Report' for 'Prevent hooking of McAfee processes' but the issue still occurred I'm afraid. I have inserted a screenshot of the error below.
The error message states that the process is not running on the remote computer, but this is a red herring as everything is definitely just running on the local computer. It must be a generic error message that is generated.
Thanks for any further help you can offer me,
Do you get any error message in the Mcafee Logfiles, mostly in the On-Access Scanner one and the Access Protection one?
Normaly it gets logged if Mcafee blocks something.
Now that is fairly weird. Can you check the settings if you do block stuff but not report it?
Also check the even viewer of the affected machine, maybe something else will log something.
As Pato said, could you open VSE console and under Help tab, there is event viewer, open it and look for any error message under application and System .
2.You can also try this as well, open VSe console and open Unwanted programe policy, click exclusions and browse to the path which is being shown in this window.click ok.
3.To make sure VSE is blocking, stop VSE all services, and try your programe again.by doing so I wll be sure that VSe is blocking it, although there is nothing in Logs, also disable your windows firewall or put the procees in allowed application in Windows firewall settings.
Hello Pato & Alex,
There is nothing in the Application or System event viewer either.
Alex - in my original post I said that the debug session in Visual Studio runs if I disable McAfee Access Protection and On-Access Scanner, so I'm positive that it's McAfee that's causing the problem.
When I click 'Exclusions' in Unwanted Programme Policy and click 'Add' > 'Browse', it doesn't let me browse to the path being shown in the screenshot of the error. Instead, it brings up a big list of Potentially unwanted programs that DAT version 6989.0000 can detect and the .exe in the error message isn't in this list. Also, the path detailed in that error varies from user to user, depending on what they're trying to debug. The msvsmon.exe part of the error message is always the same though.
My 'Access Protection Policy' has 'Report' checked next to all things where 'Block' is selected, and below is a screenshot of my Alert Policy settings.
Can you check if it works if you only disable Access Protection?
Or, but that maybe needs some policy tuning, if you leave Access Protection running, but with disabled On-Access?
That way we can rule out which one of those two components is causing the problem.