处理来自 .NET 的访问冲突答案

【问题标题】：Handling access violations from .NET处理来自 .NET 的访问冲突
【发布时间】：2015-09-16 12:03:16
【问题描述】：

我们将程序作为服务运行，并将 adplus 附加到它以获取故障转储。

在启动时，我们会定期通过以下调用堆栈获取具有首次机会访问冲突的故障转储

0:011> !mk -cc
Thread 11:
           IP
00:M 00007ffa710ca358 PerformanceMonitor.GetData(String)(+0x19 IL,+0x88 Native)
01:M 00007ffa710c7c5f PerformanceCounterLib.GetPerformanceData(String)(+0xff Native)
02:M 00007ffa710c7e2c PerformanceCounterLib.get_CategoryTable()(+0x35 IL,+0xac Native)
03:M 00007ffa710c771e PerformanceCounterLib.GetCategorySample(String, String)(+0xe IL,+0x4e Native)
04:M 00007ffa710b605f PerformanceCounterCategory.GetCounterInstances(String, String)(+0x11 IL,+0x8f Native)
05:M 00007ffa165c4ef1 PerformanceCounterCollection.AddCounter(String, String)(+0xad IL,+0x241 Native)
06:M 00007ffa165c4a9f MonitorResponder.CreatePerformanceCounters()(+0x30 IL,+0x8f Native)
07:M 00007ffa165c47ac MonitorResponder.Start()(+0xa IL,+0x2c Native)
08:M 00007ffa718b39a5 ExecutionContext.RunInternal(ExecutionContext, ContextCallback, Object, Boolean)(+0x72 IL,+0x285 Native)
09:M 00007ffa718b3719 ExecutionContext.Run(ExecutionContext, ContextCallback, Object, Boolean)(+0x0 IL,+0x9 Native)
0a:M 00007ffa718b36f7 ExecutionContext.Run(ExecutionContext, ContextCallback, Object)(+0x57 Native)
0b:M 00007ffa718cadc1 ThreadHelper.ThreadStart()(+0x51 Native)
0c:U 00007ffa75b7a7f3 clr!CallDescrWorkerInternal+0x83
0d:U 00007ffa75b7a6de clr!CallDescrWorkerWithHandler+0x4a
0e:U 00007ffa75b7ae76 clr!MethodDescCallSite::CallTargetWorker+0x251
0f:U 00007ffa75d2969d clr!ThreadNative::KickOffThread_Worker+0x105
10:U 00007ffa75b7c121 clr!ManagedThreadBase_DispatchInner+0x2d
11:U 00007ffa75b7c0a8 clr!ManagedThreadBase_DispatchMiddle+0x6c
12:U 00007ffa75b7c019 clr!ManagedThreadBase_DispatchOuter+0x75
13:U 00007ffa75b7c15f clr!ManagedThreadBase_FullTransitionWithAD+0x2f
14:U 00007ffa75d2957e clr!ThreadNative::KickOffThread+0xd2
15:U 00007ffa75cbfcb6 clr!Thread::intermediateThreadProc+0x7d
16:U 00007ffa7e4a13d2 kernel32!BaseThreadInitThunk+0x22
17:U 00007ffa80b45454 ntdll!RtlUserThreadStart+0x34

我相信我们的转储实际上来自：

     foreach ( string instanceName in category.GetInstanceNames() )

WinDbg 给出了这个行号，当我反编译它显示它调用 GetCounterInstances。

/// <summary>
/// Retrieves the list of performance object instances that are associated with this category.
/// </summary>
/// 
/// <returns>
/// An array of strings representing the performance object instance names that are associated with this category or, if the category contains only one performance object instance, a single-entry array that contains an empty string ("").
/// </returns>
/// <exception cref="T:System.InvalidOperationException">The <see cref="P:System.Diagnostics.PerformanceCounterCategory.CategoryName"/> property is null. The property might not have been set. -or-The category does not have an associated instance.</exception><exception cref="T:System.ComponentModel.Win32Exception">A call to an underlying system API failed. </exception><exception cref="T:System.UnauthorizedAccessException">Code that is executing without administrative privileges attempted to read a performance counter.</exception><filterpriority>2</filterpriority><PermissionSet><IPermission class="System.Security.Permissions.EnvironmentPermission, mscorlib, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true"/><IPermission class="System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Flags="UnmanagedCode"/><IPermission class="System.Diagnostics.PerformanceCounterPermission, System, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true"/></PermissionSet>
public string[] GetInstanceNames()
{
  if (this.categoryName == null)
    throw new InvalidOperationException(SR.GetString("CategoryNameNotSet"));
  return PerformanceCounterCategory.GetCounterInstances(this.categoryName, this.machineName);
}

从这里：https://msdn.microsoft.com/en-us/library/vstudio/system.diagnostics.performancecountercategory.getinstancenames(v=vs.100).aspx

我看到这个方法抛出了 InvalidOperationException、Win32Exception、UnauthorizedAccessException。

我们的 c# 代码在这方面似乎没有任何异常处理。

我想知道：如果我们确实尝试捕获 InvalidOperationException、Win32Exception 和 UnauthorizedAccessException，我们是否仍然会获得带有首次机会访问冲突的故障转储？

是否可以处理对 PerformanceCounterCategory.GetCounterInstances 的调用的访问冲突？

我对是否可以成功处理访问违规有点模糊。在这种情况下，我们调用 PerformanceCounters 的 .NET 库 - 所以我们不能修改此代码来防止发生访问冲突。

我们不会经常遇到这种崩溃，但经常足以让我认出调用堆栈。

编辑：

我们确实使用 legacyCorruptedStateExceptionsPolicy enabled="true"

使用我们的 QA 服务器 - 我们运行完全转储并在第一次机会访问违规时退出。

我相信我们对此的推理是我们不想在损坏的进程中运行，并且我们希望在遇到访问冲突时尽快获得尽可能多的信息。

它可以嵌套在 c++ 调用堆栈的深处，但我们可以在入口点有一个托管异常处理程序。

我们不想进行完整转储并继续，因为有时您可能会进入糟糕的状态并最终导致大量崩溃转储。此外，完全转储可能需要很长时间，我认为这可能会导致其他问题。

默认情况下，客户不会在附加了 adplus 的情况下运行，但如果他们这样做了，他们会使用 minidump 运行并继续处理首次机会访问违规。对我们来说，我们总是在首次访问违规时使用完整转储，因为我们可以从中获得更好的信息。

我想我们的困境是，如果我们在 c++ 代码中存在访问冲突，但在调用 .NET 代码并获得我们“处理”的访问冲突时，我们希望在第一次机会时进行完整转储。虽然据说你不能“处理”访问冲突。

我在 qa 服务器上看到了几个故障转储，用于围绕 PerformanceMonitor 进行服务器启动。我检查了一下，我们确实捕获了这方面的异常。问题是，当我们附加了 adplus 以执行完全转储并在第一次机会访问违规时退出时，我最终会得到这些崩溃转储。

我想我可以忽略它们，因为当我们没有将 adplus 设置为在第一次访问违规时进行完全转储和退出时，它们可能会得到安全处理。

0:011> .exr -1
ExceptionAddress: 00007ffa710ca358 (System_ni+0x000000000093a358)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 0000000000000000
   Parameter[1]: 0000000000000000
Attempt to read from address 0000000000000000

【问题讨论】：

这 - msdn.microsoft.com/en-us/library/dd638517%28v=vs.100%29.aspx（见备注部分）回答了您的问题。访问冲突是损坏状态异常，您可以根据需要捕获它，但默认情况下不会。
不太清楚你在问什么。性能计数器访问由 ACL 控制。如果我正在使用它们，我通常会用任何捕获来包装第一次访问（异常很好），如果它抛出就不要再触摸它们。
您得到故障转储，但程序继续成功？还是真的崩溃了？
您的帖子没有提供证据表明您发现了访问冲突。 .exr -1 和 !pe 的输出是什么？
另外，GetInstanceNames() 不在!mk 的调用堆栈上。究竟是什么让你相信你在那个方法中？仅当您的符号真正匹配时，行号才相关。请注意，PDB 中的行号应该是正确的，但同时您的源代码文件可能已更改。

标签： c# exception-handling windbg

【解决方案1】：

您可以catch 访问冲突异常，方法是使用 HandleProcessCorruptedStateExceptionsAttribute 或配置标记您的方法（您尝试 catch 块以捕获有问题的异常的方法）

<configuration>
   <runtime>
      <legacyCorruptedStateExceptionsPolicy enabled="true" />
   </runtime>
</configuration>

如果您使用的是 .NET Framework 3.5-，则默认情况下会捕获它们。然而，即使你能抓住，也不代表你能处理它。这种异常被称为损坏状态异常是有原因的——您的进程状态可能会以不可预知的方式损坏，因此继续在这种状态下运行可能会导致您产生不可预知的结果。所以你可以抓住它来记录它，然后优雅地退出——不要继续在这种状态下运行你的应用程序。

所以，要真正解决你的问题，你应该找到访问冲突异常的原因并摆脱它，而不是在catch块中“处理”它。

【讨论】：

【解决方案2】：

第一次访问冲突并不一定意味着损坏状态。

第一次机会例外就是这样 - 第一次机会。在 Windows SEH 异常中，SEH 过滤器功能有机会修复问题并从错误指令中恢复。只有当失败时，才会发生真正的异常，并执行 __catch 处理程序。

（旁白：SEH 的类比是 Linux/unix 中的 SEGV 处理程序。__try 映射到 setjmp，异常映射到处理程序。在处理程序中，您可以尝试解决潜在问题并继续，或调用longjmp，在这个类比中，它将控制转移到跳转到__catch块的条件）

第一次机会异常是 Windows 中的正常功能，例如加载延迟加载功能时。标准代码路径简单地设置处理程序，然后跳转到函数地址，该地址最初为零。访问冲突触发了一个 SEH 处理程序，该处理程序使用函数地址加载导入表，然后重试调用。

如果没有未处理访问违规，您可能无需担心。（例外情况是如果您有稳定性问题或怀疑此类异常没有得到正确处理）。

【讨论】：