Visual Studio 用户广泛使用“报告问题”工具报告一系列问题。 Visual Studio 团队发现用户反馈中的崩溃和缓慢趋势，并解决影响广大用户的问题。 特定反馈工单的可操作性越高，产品团队就越有可能快速诊断和解决问题。 本文档介绍报告崩溃或速度缓慢问题的最佳做法，使它们更具可操作性。
常规最佳做法
Visual Studio 是一个大型的复杂平台，支持多种语言、项目类型、平台等。 其性能取决于在会话中安装和启用的组件、安装的扩展、Visual Studio 设置、计算机配置，最后是正在编辑的代码的结构。 鉴于变量的数量，很难判断一个用户的问题报告是否与另一个用户的问题报告具有相同的基础问题，即使可见的症状是相同的。 考虑到这一点，下面是一些最佳做法，以确保特定问题报告更有可能被诊断出来。
尽可能提供一个具体的标题
查找所报告问题的不同签名，并尽可能多地包含在标题中。 如果是描述性标题，具有无关问题（但表面症状相同）的用户就不太可能对你的工单进行投票或评论，因此会加大问题的诊断难度。
怀疑时，请记录新问题报告
许多问题可能没有任何独特的特征或重现步骤。 在这种情况下，新报告要比投票支持和评论报告了类似表面症状的其他报告更好。 根据报表的类型，将其他诊断文件包含在报表中，如本文档稍后所述。
特定于问题的最佳做法
下面介绍在没有良好诊断文件的情况下难以诊断的问题。 确定最能描述你的问题的案例后，请按照特定于该案例的反馈步骤进行操作。
崩溃： 当进程（Visual Studio）意外终止时，就会发生崩溃。
无响应： VS 在较长时间内变得无响应。
慢速问题： VS 中的任何特定操作比所需慢
高 CPU 使用率：CPU 使用率长时间高乎寻常
进程外问题：Visual Studio 附属进程导致的问题
故障
当进程（Visual Studio）意外终止时发生崩溃。
可直接重现的故障
可直接重现的故障具有以下所有特征：
可以通过遵循一组已知的步骤来观察
可以在多台计算机上观察到（如果可用）
可以在能够通过链接访问或在反馈中提供的示例代码或项目中重现（如果步骤涉及打开项目或文档）
对于这些问题，请按照“如何报告问题”中的步骤操作，并确保包括：
重现问题的步骤
上述独立重现项目。 如果无法独立重现，请包含：
开放项目的语言（C#、C++等）
项目类型（控制台应用程序、ASP.NET 等）
注意
最有价值的反馈： 在本例中，最有价值的反馈是重现问题的步骤集以及示例源代码。
未知故障
如果不确定导致故障的原因或它们像是随机发生的，则可在 Visual Studio 每次发生故障时在本地捕获转储并将其附加到单独的反馈项。 若要在 Visual Studio 崩溃时本地保存崩溃转储文件，请在管理员命令窗口中运行以下命令：
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\devenv.exe" /v DumpType /t REG_DWORD /d 2
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\devenv.exe" /v DumpCount /t REG_DWORD /d 2
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\devenv.exe" /v DumpFolder /t REG_SZ /d "C:\CrashDumps"
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ServiceHub.RoslynCodeAnalysisService32.exe" /v DumpType /t REG_DWORD /d 2
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ServiceHub.RoslynCodeAnalysisService32.exe" /v DumpCount /t REG_DWORD /d 2
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ServiceHub.RoslynCodeAnalysisService32.exe" /v DumpFolder /t REG_SZ /d "C:\CrashDumps"
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ServiceHub.RoslynCodeAnalysisService.exe" /v DumpType /t REG_DWORD /d 2
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ServiceHub.RoslynCodeAnalysisService.exe" /v DumpCount /t REG_DWORD /d 2
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ServiceHub.RoslynCodeAnalysisService.exe" /v DumpFolder /t REG_SZ /d "C:\CrashDumps"
根据需要自定义转储计数和转储文件夹。 有关这些设置的详细信息，请单击此处。
注意
使用任务管理器捕获的转储可能位数不正确，因此用处不大。 上述过程是捕获堆转储的首选方法。 如果想使用任务管理器，请关闭当前正在运行的命令，启动 32 位任务管理器 (%windir%\syswow64\taskmgr.exe) 并通过它收集堆转储。
注意
此方法生成的每个转储文件的大小最大为 4 GB。 请确保将 DumpFolder 设置为具有足够驱动器空间的位置，或相应地调整 DumpCount。
每次 Visual Studio 崩溃时，它都会在已配置的位置创建一个名为 devenv.exe。[number].dmp 的转储文件。
然后，使用 Visual Studio 的“报告问题...”特征。 利用该功能，可以附加相应的转储。
找到当前报告的故障的转储文件（查找具有正确创建时间的文件）
如果可能，请压缩文件（*.zip）以在提交反馈之前减小其大小
按照如何报告问题中的步骤操作，并将堆转储附加到新的反馈项。
注意
最有价值的反馈：对于这种情况，最有价值的反馈是发生故障时捕获的堆转储。
无响应性
VS 长时间处于无响应状态。
可直接重现的无响应
如有关崩溃的相应部分所述，对于可以轻松重现的问题，可在多台计算机上看到并在一个小示例中演示，最有价值的反馈报告包括重现问题的步骤，并包括演示问题的示例源代码。
未知无响应
如果无响应以不可预知的方式显示自己，在下一次出现时，启动 Visual Studio 的新实例并从该实例报告问题。 在“记录”屏幕中，请务必选择无响应的 Visual Studio 会话。 （有关如何记录我们可以跟踪的操作以重现问题的详细信息，请参阅 如何报告问题 页面的步骤 8。
如果在管理员模式下启动无响应的 Visual Studio 实例，则还需要在管理员模式下启动第二个实例。
注意
最有价值的反馈：对于这种情况，最有价值的反馈是在无响应时捕获的堆转储。
慢速和高 CPU 问题
在运行缓慢的操作或 CPU 使用率过高的事件正在进行时捕获的性能跟踪能最大限度提高运行缓慢和 CPU 使用率过高问题的可操作性。
注意
如果可能，请在单独的特定反馈报告中隔离每个方案。 例如，如果键入和导航都很慢，请按问题执行以下步骤一次。 这有助于产品团队隔离特定问题的原因。
为了获得最佳性能捕获效果，请执行以下步骤：
如果尚未运行，请打开 Visual Studio 的副本，可在其中重现问题
设置好所有内容，以重现该问题。 例如，如果需要使用打开的特定文件加载特定项目，请确保在继续操作之前完成上述两个步骤。
如果未报告特定于加载解决方案的问题，打开解决方案后尝试等待 5-10 分钟（或更长时间，具体取决于解决方案大小），然后再记录性能跟踪。 解决方案加载过程会生成大量数据，因此等待几分钟有助于我们专注于报告的特定问题。
启动 Visual Studio 的第二个副本，但不打开解决方案
在 Visual Studio 的新副本中，打开 报告问题 工具
按照如何报告问题中的步骤操作，直到完成“提供跟踪和堆转储（可选）”步骤。
选择录制 Visual Studio 的第一个副本（遇到性能问题的副本）并开始录制。
步骤记录器应用程序将显示并开始录制。
录制过程中， 在第一个 Visual Studio 副本中执行存在问题的操作。 如果特定性能问题未在记录的时间内出现，我们很难纠正这些问题。
如果操作短于 30 秒且可以轻松重复，请重复该操作以进一步演示问题。
在大多数情况下，60 秒的跟踪足以证明问题，尤其是在有问题的操作持续（或重复）超过 30 秒时。 可以根据需要调整持续时间，以捕获要修复的行为。
在完成要报告的慢操作或高 CPU 事件后，在步骤记录器中单击“停止记录”。 处理性能跟踪可能需要几分钟时间。
完成后，您的反馈中将包含多个附件。 附加可能有助于重现问题的任何其他文件（示例项目、屏幕截图、视频等）。
提交反馈。
记录性能跟踪时，如果要报告的运行缓慢的操作或 CPU 使用率过高的事件结束，则立即停止记录。 如果收集了太多信息，最早的信息就会被覆盖。 如果在有趣的操作后不久（几秒钟内）未能及时停止跟踪，则有用的跟踪数据将被覆盖。
不要直接将性能跟踪附加到开发人员社区网站上的现有反馈项目。 请求/提供其他信息是 Visual Studio 内置报告问题工具中支持的工作流。 如果需要性能跟踪才能解决以前的反馈项目，我们将反馈项的状态设置为“需要更多信息”，该状态可以像报告新问题一样做出响应。 有关详细说明，请参阅报告问题工具文档中 “需要更多信息”部分。
注意
最有价值的反馈： 对于几乎所有运行缓慢/高 CPU 使用率问题，最有价值的反馈是您尝试执行的操作的概括性描述，以及在此期间捕获行为的性能轨迹（*.etl.zip）。
高级性能跟踪
报告问题工具中的跟踪收集功能足以满足大多数场景。 但是，有时需要对跟踪集合进行更多的控制（例如，具有较大缓冲区大小的跟踪），在这种情况下，PerfView 是一个很好的工具。 使用 PerfView 工具手动记录性能跟踪的步骤可在使用 PerfView 记录性能跟踪页中找到。
进程外问题
注意
从 Visual Studio 2019 版本 16.3 开始，进程外日志会自动附加到使用报告问题工具提交的反馈。 但是，如果问题可以直接重现，请按照以下步骤操作，这样可以添加其他信息，以便更好地诊断问题。
有许多附属进程与 Visual Studio 并行运行，并从主 Visual Studio 进程外部提供各种功能。 如果其中一个附属进程发生错误，则通常在 Visual Studio 端看到“StreamJsonRpc. RemoteInvocationException”或“StreamJsonRpc ConnectionLostException”。
最能使这些类型的问题可操作的是提供可通过以下步骤收集的其他日志：
如果这是直接重现的问题，请首先删除 %temp%/servicehub/logs 文件夹。 如果无法重现此问题，请保持此文件夹不变，并忽略以下项目符号：
- 将全局环境变量 ServiceHubTraceLevel 设置为“全部”
- 重现此问题。
在此处下载 Microsoft Visual Studio 和 .NET Framework 日志收集工具。
运行该工具。 这会将 zip 文件输出到 %temp%/vslogs.zip。 请将该文件附加到你的反馈中。