gpt4 book ai didi

.net - .NET 应用程序的 native 访问冲突

转载 作者:行者123 更新时间:2023-12-01 11:38:56 25 4
gpt4 key购买 nike

我们的 .NET 应用程序有问题。它在关闭时随机产生 native 访问冲突(因此不是 .NET 异常)。

  • Windows Server 2012 x64(在 Blade 系统上运行的虚拟机)
  • .NET 4.0 Framework(已安装4.5)
  • 我们的应用程序是 .NET x86 应用程序(不是 AnyCPU;不是 ASP.NET)
  • 第三方 native 模块使用 SQL CE 3.5 等

Windows 事件日志中的错误报告看起来像这样(省略了应用程序和模块名称,我从德语翻译了这些条目):

Exceptioncode: 0xc0000005
Offset: 0x00006a9e
Process ID: 0xfe8
...

我发现 0xc0000005 是访问冲突。这也可能由于 .NET NullReferenceException 而发生。我们已经用 ProcDump 创建了一个完整的内存转储当 Windows 错误报告对话框打开时标记 -ma。

当我打开这个转储时,除了 .exe 文件本身之外,我找不到任何加载的 .NET 模块。我不是 native 编程专家,只知道一些 WinDbg 的基础知识。

所以我做了什么:

  1. 用 WinDbg 打开转储
  2. 设置符号路径

    .sympath SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols;C:\PathToMatchingPDBs\ForTheProgram
  3. 重新加载所有符号

    .reload /d /f

    Reloading current modules
    ...*** ERROR: Symbol file could not be found. Defaulted to export symbols for sysfer.dll -
    ...
  4. ~* k 输出

    .  0  Id: 1560.19a4 Suspend: 0 Teb: ff20e000 Unfrozen
    ChildEBP RetAddr
    0058f0e8 7744c752 ntdll!ZwWaitForMultipleObjects+0xc
    0058f26c 76d256c0 KERNELBASE!WaitForMultipleObjectsEx+0x10b
    0058f2e0 76d2586a kernel32!WerpReportFaultInternal+0x1c4
    0058f2f4 76cf7828 kernel32!WerpReportFault+0x6d
    0058f300 774d07c4 kernel32!BasepReportFault+0x19
    0058f39c 7762c11c KERNELBASE!UnhandledExceptionFilter+0x1f1
    0058f3a4 775f3334 ntdll!__RtlUserThreadStart+0x57
    0058f3b8 77691fd7 ntdll!_EH4_CallFilterFunc+0x12
    0058f3e0 77693612 ntdll!_except_handler4_common+0x8e
    0058f400 775f30f1 ntdll!_except_handler4+0x20
    0058f424 775f30c3 ntdll!ExecuteHandler2+0x26
    0058f4ec 775f2f2b ntdll!ExecuteHandler+0x24
    0058f4ec 00406a9e ntdll!KiUserExceptionDispatcher+0xf
    0058f844 7760ac69 MyProgram!COM+_Entry_Point <PERF> (MyProgram+0x6a9e)
    0058f888 7760ac3c ntdll!__RtlUserThreadStart+0x72
    0058f8a0 00000000 ntdll!_RtlUserThreadStart+0x1
  5. 下一部分我不确定我所做的是否正确。我在某处读到,您可以获取列 RetAddr 的地址并将其传递给 uf 以查看此时函数在做什么。这个对吗?所以我期待以下命令显示 MyProgram+0x6a9e 函数的反汇编,请参见上面的调用堆栈。

    >uf 0x00406a9e
    MyProgram!COM+_Entry_Point <PERF> (MyProgram +0x6a9e):
    00406a9e ff2500204000 jmp dword ptr [MyProgram!COM+_Entry_Point <PERF> (MyProgram+0x2000) (00402000)]

    mscoree!_CorExeMain_Exported:
    707f4ddb 8bff mov edi,edi
    707f4ddd 56 push esi
    707f4dde e80c2f0000 call mscoree!ShellShim__CorExeMain (707f7cef)
    707f4de3 6a00 push 0
    707f4de5 8bf0 mov esi,eax
    707f4de7 e84bc4ffff call mscoree!GetShimImpl (707f1237)
    707f4dec e93a800000 jmp mscoree!_CorExeMain_Exported+0x11 (707fce2b)

    mscoree!_CorExeMain_Exported+0x11:
    707fce2b 83f801 cmp eax,1
    707fce2e 750a jne mscoree!_CorExeMain_Exported+0x20 (707fce3a)

    mscoree!_CorExeMain_Exported+0x16:
    707fce30 6858378370 push offset mscoree!g_wszShimImplDllPath (70833758)
    707fce35 e826350100 call mscoree!DisplayMessageBoxForNoShimImpl (70810360)

    mscoree!_CorExeMain_Exported+0x20:
    707fce3a 8bc6 mov eax,esi
    707fce3c 5e pop esi
    707fce3d c3 ret

    我不确定如何解释这个。由于 CoreExeMain Exports,我看起来这真的是应用程序的入口点?所以这里没有太多有用的信息,或者?只是问题发生在 native 代码级别;据我解释。

为了完整起见:

.loadby sos clr
Unable to find module ‘clr’
!pe
No export pe found.

当我用 Visual Studio 打开转储时,也没有发现异常。

这就是我的进展。也许有人可以帮助我解释这些数据和/或给我一些提示,我还可以尝试什么?

我的问题:

  • 使用 Reflection.Emit 生成的 IL-Code 会导致这种错误吗?
  • 我该怎么做才能进一步分析问题/找到原因?
  • COM+_Entry_Point 是什么意思。这是我的应用程序的主要入口点还是与某些外部组件有关?

编辑

@Jochen Kalmbach

.ecxr;kP

Minidump doesn't have an exception context
Unable to get exception context, HRESULT 0x80004002
ChildEBP RetAddr
0058f0e8 7744c752 ntdll!ZwWaitForMultipleObjects+0xc
0058f26c 76d256c0 KERNELBASE!WaitForMultipleObjectsEx+0x10b
0058f2e0 76d2586a kernel32!WerpReportFaultInternal+0x1c4
0058f2f4 76cf7828 kernel32!WerpReportFault+0x6d
0058f300 774d07c4 kernel32!BasepReportFault+0x19
0058f39c 7762c11c KERNELBASE!UnhandledExceptionFilter+0x1f1
0058f3a4 775f3334 ntdll!__RtlUserThreadStart+0x57
0058f3b8 77691fd7 ntdll!_EH4_CallFilterFunc+0x12
0058f3e0 77693612 ntdll!_except_handler4_common+0x8e
0058f400 775f30f1 ntdll!_except_handler4+0x20
0058f424 775f30c3 ntdll!ExecuteHandler2+0x26
0058f4ec 775f2f2b ntdll!ExecuteHandler+0x24
0058f4ec 00406a9e ntdll!KiUserExceptionDispatcher+0xf
0058f844 7760ac69 MyProgram!COM+_Entry_Point <PERF>
0058f888 7760ac3c ntdll!__RtlUserThreadStart+0x72
0058f8a0 00000000 ntdll!_RtlUserThreadStart+0x1b

为什么是小型转储?

@Thomas W.

lm

start end module name
00400000 0040c000 MyProgram (private pdb symbols) c:\...\release\MyProgram.pdb
707f0000 7083a000 mscoree (pdb symbols) c:\symbols\mscoree.pdb\7608F9FF3C954E429A27D833164E4BEE2\mscoree.pdb
74b70000 74bdd000 sysfer (export symbols) sysfer.dll
76cc0000 76df0000 kernel32 (pdb symbols) c:\symbols\wkernel32.pdb\CFACA818EC334A5EAD707CD86C847B4A1\wkernel32.pdb
77440000 774e6000 KERNELBASE (pdb symbols) c:\symbols\wkernelbase.pdb\CAE0056433064B78937D9022B20FA1102\wkernelbase.pdb
775b0000 77707000 ntdll (private pdb symbols) c:\symbols\wntdll.pdb\EC83D8DF555946E0B630133EBD9792662\wntdll.pdb

编辑2

附加信息:

!heap
Index Address Name Debugging options enabled
1: 009c0000
2: 006b0000
3: 00770000
4: 00d00000


!heap -a
Index Address Name Debugging options enabled
1: 009c0000
Segment at 009c0000 to 00abf000 (0000b000 bytes committed)
2: 006b0000
Segment at 006b0000 to 006bf000 (00003000 bytes committed)
Segment at 00810000 to 0090f000 (00042000 bytes committed)
3: 00770000
Segment at 00770000 to 0077f000 (00003000 bytes committed)
4: 00d00000
Segment at 00d00000 to 00d3f000 (00001000 bytes committed)


!heap -l
Searching the memory for potential unreachable busy blocks.
Heap 009c0000
Heap 006b0000
Heap 00770000
Heap 00d00000
Scanning VM ...
Scanning references from 204 busy blocks (0 MBytes) ...
Entry User Heap Segment Size PrevSize Unused Flags
-----------------------------------------------------------------------------
006b07c0 006b07c8 006b0000 006b0000 88 220 8 busy
007707c0 007707c8 00770000 00770000 88 220 8 busy
2 potential unreachable blocks were detected.

那是什么意思呢?

最佳答案

这还不是一个确切的答案,但对于评论来说太长了。按出现顺序:

"when the windows error reporting dialog was open."

在 Windows 错误报告已在处理该进程时进行故障转储效果不佳。相反,直接使用 ProcDump 运行应用程序:

procdump -e -ma -x c:\MyDump.dmp C:\PathTo\MyApplication.exe Arguments

ProcDump 将在异常发生时生成故障转储。如果这对您不起作用,请让 Windows 错误报告将转储保存在磁盘上。参见 Collecting User Mode dumps注册表设置这样做。对于 .NET,请务必将 DumpType 设置为 2。

"I cannot find any .NET modules loaded"

您如何检查 .NET 模块?您可以使用 lm 列出所有模块,看看您是否找到了一些您知道的 DLL。

"Setup the symbol path with ..."

没关系。如果你不想输入所有 HTTP 内容,你也可以使用

.symfix C:\Symbols
.sympath+ C:\PathToMatchingPDBs\ForTheProgram

"~* k outputs KERNELBASE!UnhandledExceptionFilter+0x1f1"

这可能是您没有获得有关原始异常的太多信息的原因:该异常刚刚由 Windows 错误报告处理。

"Unable to find module ‘clr’"

您确定这是 .NET 4 应用程序吗?尝试 .loadby sos mscorwks 看看它是否是 .NET 2。如果这也没有帮助,请检查 lm m ms* 是否有其他类似 .NET 的程序集。

关于.net - .NET 应用程序的 native 访问冲突,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/23807966/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com