我们将程序作为服务运行，并且我们将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库 - 因此我们不能修改此代码以防止发生访问冲突。
我们不会经常发生这种崩溃，但通常我认识到了callstack。
修改
我们使用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
答案 0 :(得分：1)
您可以捕获访问冲突异常，方法是使用HandleProcessCorruptedStateExceptionsAttribute标记您的方法（尝试使用catch块来捕获相关异常的方法），或使用配置
<configuration>
<runtime>
<legacyCorruptedStateExceptionsPolicy enabled="true" />
</runtime>
</configuration>
如果您使用的是.NET Frameowork 3.5-，默认情况下它们会被捕获。但是，即使您可以捕获，也不意味着您可以处理它。这种异常被称为损坏的状态异常，原因是 - 您的进程状态可能以不可预测的方式被破坏，因此继续在此状态下运行可能会导致您的结果不可预测。所以你可以抓住它来记录它，并优雅地退出 - 不要继续在这种状态下运行你的应用程序。
所以，要真正解决你的问题，你应该找到访问冲突异常的原因并摆脱它，而不是＆＃34;处理＆＃34;它在陷阱中。
答案 1 :(得分：1)
第一次机会访问违规并不一定意味着损坏的状态。
第一次机会的例外只是 - 第一次机会。在Windows SEH异常中，SEH过滤器功能有机会解决问题并从故障指令中恢复。只有当失败时，才会发生真正的异常，并执行__catch处理程序。
（旁白：SEH的类比是Linux / unix中的SEGV处理程序。__try映射到setjmp，异常映射到处理程序。在处理程序中，您可以尝试解析底层发出并继续，或者调用longjmp，在此类比中将控制转移到跳转到__catch块的条件
第一次机会异常是Windows中的正常设施，例如加载延迟加载功能时。标准代码路径只是设置处理程序，然后跳转到函数地址，该地址最初为零。访问冲突会触发SEH处理程序，该处理程序使用函数的地址加载导入表，然后重试该调用。
如果没有未处理的访问权限违规行为，您可能不必担心。 （例外情况是如果您遇到稳定性问题或者怀疑此类异常未得到正确处理）。