在（另一次）遇到 Visual Studio 缓慢问题后，我进入 procmon 看看是否任何事情都很突出。我们的 IT 部门已经为赛门铁克的实时扫描创建了一些白名单条目，因此我没想到会看到任何过度活跃的实时扫描，或者来自赛门铁克的任何内容（我们使用的企业病毒扫描）。
我看到 Visual Studio (devenv.exe) 在 Visual Studio 的生命周期内多次访问 Symantec 文件，特别是 131MB 的病毒定义文件。我无法理解为什么 VS 会尝试访问 Symantec 的文件。
一些想法：
- 某种赛门铁克插件与客户端软件一起安装 - 我该如何检查？我在扩展管理器中没有看到任何内容
- 我没有正确读取 procmon - 有人有任何批评吗？
- 与我上周五下午安装的VS 2010的SP1有关
系统
- Win 7 Ultimate
- VS 2010 Ultimate with SP1 - 上周五安装了 SP1
- VS 扩展：TFS Auto Shelve v1.3、VS Commands 2010 v3.6.8.3
- 我们使用 .NET 4 开发 Web 应用程序和 silverlight 应用程序， SL 4、实体框架和 WCF RIA 服务（截至上周五，现在为 WCF RIA 服务 - 附带 SP1 安装）
- 我当前正在使用的解决方案文件包含 46 个项目，是一个包含 Silverlight 项目的网站应用程序。
- 当我编辑 XAML 文件，然后尝试切换到视图模型文件时，会发生错误。 VS 在切换文件之前挂起大约 3 秒。
- 屏幕截图可访问 此处
如果需要将其移至超级用户（我理解），我只是想先将其发布到此处，因为你们都是最有可能经常使用 Visual Studio 的人。
我的主要问题是：为什么 Visual Studio 会访问该文件，这是否会导致速度变慢，如何预防？为了便于讨论，假设我与 IT 部门关系良好；）
谢谢，马修
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:
- Some sort of Symantec plugin was installed along with the client software - how would I check that? I don't see anything in the extensions manager
- I'm not reading procmon correctly - anyone have any critiques?
- It is related to VS 2010's SP1 which I installed last Friday afternoon
System
- Win 7 Ultimate
- This OS install is about 1 month or less old
- VS 2010 Ultimate with SP1 - SP1 installed last Friday
- VS Extensions: TFS Auto Shelve v1.3, VS Commands 2010 v3.6.8.3
- We develop web apps and silverlight apps using .NET 4, SL 4, Entity Framework, and WCF RIA Services (now WCF RIA Services as of last Friday - came with SP1 install)
- Solution file I'm currently working with contains 46 projects and is a website application with Silverlight projects in it
- The error occurs when I edit a XAML file and then try to switch to the view-model file. VS hangs for about 3 seconds before switching the file.
- A screenshot is accessible here
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
发布评论
评论（2）
当然，访问该文件的不是 VS。它是一个 DLL，由执行此操作的 Symantec 垃圾软件注入 VS 进程。启动 Visual Studio 的另一个实例并使用“工具”+“附加到进程”来附加非托管调试器。调试 + 全部中断、调试 + Windows + 模块可查看已加载的所有 DLL 的列表。请在 superuser.com 上询问相关问题。
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.
正如 Hans 所建议的，我将 VS 连接到自身:) 并检查了已加载的模块。有一些随机命名的 dll，没有任何与之关联的路径，但赛门铁克并没有给我留下任何明显的印象。
我不断尝试并与 IT 部门合作，在我的机器上完全禁用赛门铁克。在没有任何活动痕迹后，我再次尝试并得到同样的缓慢，但 procmon 没有列出任何与 Symantec（或 VS）有关的内容。因此，尽管最初的 procmon 列表很奇怪（也可能是 Hans 提到的），但它一定不会减慢速度。
我在 google 上搜索了 Visual Studio xaml 的缓慢情况，发现 此连接错误 看起来像我得到的（它又是 此错误）。我对这个问题投了赞成票（如果您有这个问题，您也应该投赞成票）。
然后我就回去工作了。
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.