“I have virus protection software X with Y features enabled and I’m trying to get
Visual Studio to do Z but I see error messages instead. What
can I do?”
I see this question a LOT about Visual Studio .NET 2002 and 2003. This
post is an effort to consolidate the answers to these general issues into one location.
Why do these problems exist?
During the 2002/2003 we never had much focused testing that included virus protection
software outside of what is installed on the desktops here at Microsoft. For
the Whidbey release we are going to push testing with several other virus protection
suites enabled as well.
Some anti-virus software is overzealous in how they go about their business. This
is sometimes good for security, but usability generally finished a distant second
in these cases.
What are the common problems and what can
I do about them?
Don’t run script blocking software during
the install of Visual Studio. If
you did, ignored warning messages during the install, and you’ve had problems with
VS from the first launch there isn’t much you can do but re-install VS. Covered
KB article. For Whidbey we’ll be moving the install away from its reliance on
scripting thus avoiding this issue.
Other Script Blocking Issues: If you got
past the install of VS, but have re-enabled most of the popular script blockers you
may encounter problems that you will need to turn off script blocking to solve. These
problems may not even give you warnings and may just manifest themselves by just shutting
down VS when a user attempts the following.
Creating a project: The project creation wizards rely on scripts that access the file
system object to create your project on disc. I’m
told in Whidbey we’ll again be changing our scripting model to avoid these problems.
Adding classes or items to a project. (If you see a trend it’s pretty much anything
that uses a wizard is most likely using scripting behind the scenes.)
Accessing the Start Page features: The start page uses the file system and registry
to get MRU information in 2002. In 2003 we moved the MRU to be a normal win32 component
for performance reasons. This also had the effect of removing the script warning whenever
you start up VS. You may still see script
warnings though accessing the “Community Features” of VS 2003 since that relies on
the 2002 start page code that uses scripts. In
Whidbey we’ve replaced/moved most of the start page functionality so it won’t be an
The problem with turning off script blocking completely is that there are useful reasons
to enable script blocking. If your AV
software allows you to be selective you should try to allow the devenv.exe process
to run unfettered and ignore warnings from “VS://” URLs.
Real Time Scan Issues: Virus Scanning
software enabled for “Real-Time” scanning can dramatically effect performance and
sometimes cause apparent hangs during the following operations listed below. The only
solution is to disable the real time scan. Some real time scanners will let you tell
them to ignore files in certain locations which might be a more secure option.
Compiling/Building larger projects. See KB
250670 or KB
- Accessing Projects over source control or network shares.
- Debugging a project
- Visual Studio Startup and Shutdown
- Opening help or help windows
- Deployment of apps
Other Random Issues:
Exceptions when debugging ASP.NET apps? Check
out this KB Article.
There is some (less frequently used) anti-virus software that actually modifies the
name of the running process and or the executable names. If you try to start VS and
get a warning that it is unable to find a certain file ensure that the running process
is “devenv.exe” and not that name with random characters inserted in front of the
process name. We don’t run very well
if someone changes the name of our running process. J
Real time scans can cause files to appear as changed just after project creation/opening. The
solution is to disable the real time scans from touching Visual Studio associated
VS and Kaspersky Antivirus are apparently
not compatible. See this thread.
Some firewall/Proxy server combinations will disable Start Page features and result
in the message “You must be connected to the internet to use this feature”. This
is because the Start Page relies on the MSXML component for content downloads and
there is an issue with this component that will cause it not to retrieve information
that you could see with a normal http request to the source.
If I find more issues I’ll post them here as well. If
you have run into other similar issues feel free to send them my way.