【问题标题】:How to debug nondeterministic access violation crash?如何调试非确定性访问冲突崩溃?
【发布时间】:2010-04-16 18:31:59
【问题描述】:

我们的 C#/COM/C++ 应用程序崩溃了,我需要帮助来调试它。在启用 gflags 并附加 WinDbg 的情况下运行,我们确定崩溃是由访问冲突引起的,但我们无法缩小范围。我们没有在所有机器上都看到这个问题;有几台机器似乎经常重现该问题,但不是确定性的。我们观察到应用程序崩溃是从简单地从应用程序(例如,Alt-Tab)切换然后返回。 WinDbg 的输出如下。

我们一直在尝试系统地注释掉可能导致问题的代码区域,但我们还没有取得太大的成功。

对于我们应该尝试哪些调试步骤或工具有什么建议吗?

!分析-v

EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff) 异常地址: 1a584ff2 (+0x1a584ff1)
异常代码:c0000005(访问 违规)异常标志:00000000 NumberParameters:2 参数[0]: 00000000 参数[1]:1a584ff2 尝试从地址 1a584ff2 读取

PROCESS_NAME:ProcessFiles.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - 引用了 0x%08lx 处的指令 内存在 0x%08lx。记忆可以 不是 %s。

EXCEPTION_CODE:(NTSTATUS)0xc0000005 - 0x%08lx 处的指令引用了 0x%08lx 处的内存。这 内存不能是 %s。

EXCEPTION_PARAMETER1: 00000000

EXCEPTION_PARAMETER2: 1a584ff2

READ_ADDRESS: 1a584ff2

FOLLOWUP_IP:Ed20+1a584ff1 1a584ff2 ?? ???

NTGLOBALFLAG:2000000

APPLICATION_VERIFIER_FLAGS:0

IP_MODULE_UNLOADED:Ed20+1a584ff1 1a584ff2 ?? ???

MANAGED_STACK:(TransitionMU) 0EC6F6F4 7B1D8CCE System_Windows_Forms_ni!System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32, Int32, Int32)+0x24e 0EC6F790 7B1D8937 System_Windows_Forms_ni!System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext)+0x177 0EC6F7E4 7B1D8781 System_Windows_Forms_ni!System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext)+0x61 0EC6F814 7B195911 System_Windows_Forms_ni!System.Windows.Forms.Application.Run(System.Windows.Forms.Form)+0x31 0EC6F828 0969D97A Extract_Utilities_Forms!Extract.Utilities.Forms.VerificationForm`1[[System.__Canon, mscorlib]].A(System.Object)+0x23a 0EC6F8C0 79A00EEE mscorlib_ni!System.Threading.ThreadHelper.ThreadStart_Context(System.Object)+0x72a25e 0EC6F8CC 792E019F mscorlib_ni!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, 系统.对象)+0x6f 0EC6F8E4 797DB48A mscorlib_ni!System.Threading.ThreadHelper.ThreadStart(System.Object)+0x4a (过渡UM)

LAST_CONTROL_TRANSFER:来自 7e418734 到 1a584ff2

FAULTING_THREAD: ffffffff

ADDITIONAL_DEBUG_TEXT:后续集 基于属性 [ip_not_executable] 来自 Frame:[0] on thread:[e30]

BUGCHECK_STR: APPLICATION_FAULT_BAD_INSTRUCTION_PTR_INVALID_POINTER_READ_WRONG_SYMBOLS_WINDOW_HOOK

PRIMARY_PROBLEM_CLASS: BAD_INSTRUCTION_PTR

DEFAULT_BUCKET_ID: BAD_INSTRUCTION_PTR

STACK_TEXT:7b1d8cce System_Windows_Forms_ni!System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop+0xc 7b1d8937 System_Windows_Forms_ni!System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner+0x0 7b1d8781 System_Windows_Forms_ni!System.Windows.Forms.Application+ThreadContext.RunMessageLoop+0x0 7b195911 System_Windows_Forms_ni!System.Windows.Forms.Application.Run+0x31 0969d97a Extract_Utilities_Forms!Extract.Utilities.Forms.VerificationForm`1[[System.__Canon, mscorlib]].A+0x23a 79a00eee mscorlib_ni!System.Threading.ThreadHelper.ThreadStart_Context+0x72a25e 792e019f mscorlib_ni!System.Threading.ExecutionContext.Run+0x6f 797db48a mscorlib_ni!System.Threading.ThreadHelper.ThreadStart+0x4a

STACK_COMMAND: .ecxr ; ~~[e30] ; .frame 0 ; ** 伪上下文 ** ; kb

FAILED_INSTRUCTION_ADDRESS: Ed20+1a584ff1 1a584ff2 ??
???

SYMBOL_NAME:Ed20

FOLLOWUP_NAME:MachineOwner

模块名称:Ed20

IMAGE_NAME:Ed20

DEBUG_FLR_IMAGE_TIMESTAMP:0

FAILURE_BUCKET_ID: BAD_INSTRUCTION_PTR_c0000005_Ed20!卸载

BUCKET_ID: APPLICATION_FAULT_BAD_INSTRUCTION_PTR_INVALID_POINTER_READ_WRONG_SYMBOLS_WINDOW_HOOK_BAD_IP_Ed20

跟进:MachineOwner

【问题讨论】:

  • 您是否尝试过在启用第一次机会异常处理的情况下附加到调试器运行? (Visual Studio 中的 Ctrl+Alt+E)。
  • 是的,奇怪的是:我们什么也没看到。它似乎只能在几台机器上重现,而不是我们的开发机器。
  • 堆已损坏。您将在此线程中找到很好的调试提示:stackoverflow.com/questions/1010106/… 或通过谷歌搜索“如何调试堆损坏”。

标签: c# c++ com crash access-violation


【解决方案1】:

找到一台经常重现崩溃的计算机,并在该计算机上安装 WinDbg。然后运行windbg.exe -I,这将使WinDbg 成为事后崩溃处理程序。

等待崩溃发生。发生这种情况时,WinDbg 将在崩溃点自动打开。使用 WinDbg 命令kpn 获取堆栈跟踪。 (您可能需要确保机器上也有符号。)

【讨论】:

  • 我过去预先附加了windbg.exe,并尝试将其配置为不会经常中断,但我不知道-I 开关,这似乎更清洁接近。
【解决方案2】:

感谢您的回复。

我们最终通过评估自上一个软件版本(未崩溃)以来的所有代码更改来发现问题。罪魁祸首是在文本控件的 OnLostFocus 覆盖中将 HideSelection 设置为 false。根据this 的帖子——这会导致坏事发生(好吧,无论如何,在某些机器上)。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-05-13
    • 2014-12-25
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多