处理来自 .NET 的访问冲突
Handling access violations from .NET
我们 运行 一个程序即服务，我们将 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);
}
我看到此方法抛出 InvalidOperationException、Win32Exception、UnauthorizedAccessException。
我们的c#代码好像没有这方面的异常处理。
我想知道：
如果我们确实尝试捕获 InvalidOperationException、Win32Exception 和 UnauthorizedAccessException，我们是否仍会获得具有第一次访问冲突的故障转储？
可以处理调用 PerformanceCounterCategory.GetCounterInstances 的访问冲突吗？
我有点不清楚是否可以成功处理访问冲突。在这种情况下，我们调用 PerformanceCounters 的 .NET 库 - 因此我们无法修改此代码以防止发生访问冲突。
我们不经常遇到这种崩溃，但足够频繁以至于我认出了调用堆栈。
编辑：
我们 运行 启用 legacyCorruptedStateExceptionsPolicy="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
您可以 catch 访问冲突异常，方法是使用 HandleProcessCorruptedStateExceptionsAttribute 标记您的方法（您使用 try catch 块来捕获相关异常的方法），或使用配置
<configuration>
<runtime>
<legacyCorruptedStateExceptionsPolicy enabled="true" />
</runtime>
</configuration>
如果您使用的是 .NET Frameowork 3.5-，默认情况下会捕获它们。但是，即使您可以 捕获 并不意味着您可以 处理 它。此类异常被称为损坏状态异常是有原因的 - 您的进程状态可能以不可预测的方式损坏，因此在这种状态下继续 运行ning 可能会导致不可预测的结果。因此，您可以捕获它以记录它，然后优雅地退出 - 不要继续 运行 您的应用程序处于这种状态。
因此，要真正解决您的问题，您应该找到访问冲突异常的原因并解决它，而不是 "handle" 在 catch 块中。
第一次访问冲突并不一定意味着状态已损坏。
第一次机会例外就是第一次机会。在 windows SEH 异常中，SEH 过滤器函数有机会修复问题并从错误指令中恢复。仅当失败时，才会发生真正的异常，并执行 __catch 处理程序。
（旁白：SEH 的类比是 Linux/unix 中的 SEGV 处理程序。__try 映射到 setjmp，异常映射到处理程序。在处理程序中，您可以尝试解决潜在问题并继续，或调用 longjmp，在这个类比中，它将控制转移到跳转到 __catch 块的条件）
第一次机会例外是 windows 中的正常设施，例如加载延迟加载功能时。标准代码路径只是设置处理程序，然后跳转到最初为零的函数地址。访问冲突触发一个 SEH 处理程序，该处理程序使用函数的地址加载导入 table，然后重试调用。
如果没有未处理 访问冲突，您可能不需要担心。 （例外情况是您遇到稳定性问题或怀疑此类异常没有得到正确处理）。
我们 运行 一个程序即服务，我们将 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);
}
我看到此方法抛出 InvalidOperationException、Win32Exception、UnauthorizedAccessException。
我们的c#代码好像没有这方面的异常处理。
我想知道： 如果我们确实尝试捕获 InvalidOperationException、Win32Exception 和 UnauthorizedAccessException，我们是否仍会获得具有第一次访问冲突的故障转储？
可以处理调用 PerformanceCounterCategory.GetCounterInstances 的访问冲突吗？
我有点不清楚是否可以成功处理访问冲突。在这种情况下，我们调用 PerformanceCounters 的 .NET 库 - 因此我们无法修改此代码以防止发生访问冲突。
我们不经常遇到这种崩溃，但足够频繁以至于我认出了调用堆栈。
编辑：
我们 运行 启用 legacyCorruptedStateExceptionsPolicy="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
您可以 catch 访问冲突异常，方法是使用 HandleProcessCorruptedStateExceptionsAttribute 标记您的方法（您使用 try catch 块来捕获相关异常的方法），或使用配置
<configuration>
<runtime>
<legacyCorruptedStateExceptionsPolicy enabled="true" />
</runtime>
</configuration>
如果您使用的是 .NET Frameowork 3.5-，默认情况下会捕获它们。但是，即使您可以 捕获 并不意味着您可以 处理 它。此类异常被称为损坏状态异常是有原因的 - 您的进程状态可能以不可预测的方式损坏，因此在这种状态下继续 运行ning 可能会导致不可预测的结果。因此，您可以捕获它以记录它，然后优雅地退出 - 不要继续 运行 您的应用程序处于这种状态。
因此，要真正解决您的问题，您应该找到访问冲突异常的原因并解决它，而不是 "handle" 在 catch 块中。
第一次访问冲突并不一定意味着状态已损坏。
第一次机会例外就是第一次机会。在 windows SEH 异常中，SEH 过滤器函数有机会修复问题并从错误指令中恢复。仅当失败时，才会发生真正的异常，并执行 __catch 处理程序。
（旁白：SEH 的类比是 Linux/unix 中的 SEGV 处理程序。__try 映射到 setjmp，异常映射到处理程序。在处理程序中，您可以尝试解决潜在问题并继续，或调用 longjmp，在这个类比中，它将控制转移到跳转到 __catch 块的条件）
第一次机会例外是 windows 中的正常设施，例如加载延迟加载功能时。标准代码路径只是设置处理程序，然后跳转到最初为零的函数地址。访问冲突触发一个 SEH 处理程序，该处理程序使用函数的地址加载导入 table，然后重试调用。
如果没有未处理 访问冲突，您可能不需要担心。 （例外情况是您遇到稳定性问题或怀疑此类异常没有得到正确处理）。