Reputation: 2385
After (another) bout with Visual Studio slowness, I went into procmon to see if anything stood out. Our IT department had already made some whitelist entries for Symantec's real-time scanning, so I wasn't expecting to see any over-active real-time scans, or much of anything from Symantec (the enterprise virus scanning we use).
What I saw was that Visual Studio (devenv.exe) was accessing a Symantec file, specifically a 131MB virus definition file multiple times during the lifetime of Visual Studio. I cannot fathom why VS would be trying to access Symantec's files.
Some thoughts:
System
If this needs to be moved to super user I understand, I just wanted to post it here first since you all are the people most likely to be using Visual Studio a lot.
My main question is: Why is Visual Studio accessing that file, is this causing the slow down, and how can it be prevented? For the sake of argument, let's say I'm on good terms with IT ;)
Thanks, Matthew
Upvotes: 0
Views: 776
Reputation: 2385
As Hans suggested, I attached VS to itself :) and checked out the modules that were loaded. There were some randomly named dlls that didn't have any paths associated with them, but there was nothing obviously Symantec sticking out to me.
I kept trying and worked with IT to disable Symantec on my box completely. After there was no trace of it being active, I tried again and got the same slowness, but procmon didn't list anything having to do with Symantec (or VS for that matter). So, even though the original procmon listing was strange (and could have been what Hans mentioned), it must not have been slowing it down.
I googled for visual studio xaml slowness, and came across this connect bug which looked like what I was getting (it in turn is a duplicate of this bug). I voted the issue up (and you should too if you have the issue).
and then i went back to work.
Upvotes: 0
Reputation: 941970
Of course it isn't VS that's accessing this file. It is a DLL that gets injected into the VS process by the Symantec crapware that does this. Start another instance of Visual Studio and use Tools + Attach to Process to attach an unmanaged debugger. Debug + Break All, Debug + Windows + Modules to see the list of all the DLLs that got loaded. Ask questions about it at superuser.com.
Upvotes: 1