当前位置： 文江博客话题详情

加载dll时发生访问冲突

发布于 2024-11-25 04:08:24 字数 1925 浏览 4 评论 0原文

普通 C 应用程序在 MSVC6 上编译良好，但在运行时会引发访问冲突。

在 WinDbg 中运行应用程序时，加载 rasadhlp.dll（Windows 文件）时出现 AV 错误。

问题：加载 Windows dll 时什么可能导致访问冲突？

我习惯于在各种尼克斯而不是窗口上工作，所以可能有一些非常明显的东西我错过了。

[...]
ModLoad: 77920000 77a13000   C:\WINDOWS\system32\SETUPAPI.dll
ModLoad: 76fc0000 76fc6000   C:\WINDOWS\system32\rasadhlp.dll
  (f38.a08): Access violation - code c0000005 (first chance)
  First chance exceptions are reported before any exception handling.
  This exception may be expected and handled.
  eax=00000000 ebx=00000000 ecx=00000000 edx=0049f8f0 esi=0049f8f0 edi=00000000
  eip=7c918fea esp=0012fbdc ebp=0012fc50 iopl=0         nv up ei ng nz na pe nc
  cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010286
  ntdll!RtlpWaitForCriticalSection+0x5b:
  7c918fea ff4010          inc     dword ptr [eax+10h]  ds:0023:00000010=????????
0:000> g
  (f38.a08): Access violation - code c0000005 (!!! second chance !!!)
  eax=00000000 ebx=00000000 ecx=00000000 edx=0049f8f0 esi=0049f8f0 edi=00000000
  eip=7c918fea esp=0012fbdc ebp=0012fc50 iopl=0         nv up ei ng nz na pe nc
  cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000286
  ntdll!RtlpWaitForCriticalSection+0x5b:
  7c918fea ff4010          inc     dword ptr [eax+10h]  ds:0023:00000010=????????

注：该应用程序在win2k上编译，在XP上测试。 （由于各种奇怪的原因，现在无法更改...）

[编辑]：程序跟踪：

ntdll!RtlpWaitForCriticalSection+0x5b
ntdll!RtlEnterCriticalSection+0x46
msvcrt!vprintf+0x18
intl!libintl_vfprintf+0xa8
intl!libintl_fprintf+0x1f
image00400000+0x6239
MSCTF!DllGetClassObject+0x1de9
ntdll!RtlpNtMakeTemporaryKey+0x7ec8
ntdll!RtlInitializeSListHead+0x115c0
ntdll!iswdigit+0x339
ntdll!LdrGetProcedureAddress+0x4b
image00400000+0x626f4

[编辑2]：我知道异常首先被调试器捕获，这是完全正常的。您会在日志中注意到我手动跳过了第一次机会异常，并强制它进入我的程序。我想知道这种错误的根源，而不是处理。

原文

A plain C application compiles fine on MSVC6, but when running, it raises an Access violation.

When running the app in WinDbg, I get the AV error raised when loading rasadhlp.dll (a windows file).

Question: What could possibly cause an access violation when loading a windows dll?

I'm used to working on the various nixes rather than windows, so there might be something really obvious that I'm missing.

[...]
ModLoad: 77920000 77a13000   C:\WINDOWS\system32\SETUPAPI.dll
ModLoad: 76fc0000 76fc6000   C:\WINDOWS\system32\rasadhlp.dll
  (f38.a08): Access violation - code c0000005 (first chance)
  First chance exceptions are reported before any exception handling.
  This exception may be expected and handled.
  eax=00000000 ebx=00000000 ecx=00000000 edx=0049f8f0 esi=0049f8f0 edi=00000000
  eip=7c918fea esp=0012fbdc ebp=0012fc50 iopl=0         nv up ei ng nz na pe nc
  cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010286
  ntdll!RtlpWaitForCriticalSection+0x5b:
  7c918fea ff4010          inc     dword ptr [eax+10h]  ds:0023:00000010=????????
0:000> g
  (f38.a08): Access violation - code c0000005 (!!! second chance !!!)
  eax=00000000 ebx=00000000 ecx=00000000 edx=0049f8f0 esi=0049f8f0 edi=00000000
  eip=7c918fea esp=0012fbdc ebp=0012fc50 iopl=0         nv up ei ng nz na pe nc
  cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000286
  ntdll!RtlpWaitForCriticalSection+0x5b:
  7c918fea ff4010          inc     dword ptr [eax+10h]  ds:0023:00000010=????????

Note: The app is compiled on win2k, tested on XP. (which, for various weird reasons, can't be changed right now...)

[edit]: program trace:

ntdll!RtlpWaitForCriticalSection+0x5b
ntdll!RtlEnterCriticalSection+0x46
msvcrt!vprintf+0x18
intl!libintl_vfprintf+0xa8
intl!libintl_fprintf+0x1f
image00400000+0x6239
MSCTF!DllGetClassObject+0x1de9
ntdll!RtlpNtMakeTemporaryKey+0x7ec8
ntdll!RtlInitializeSListHead+0x115c0
ntdll!iswdigit+0x339
ntdll!LdrGetProcedureAddress+0x4b
image00400000+0x626f4

[edit 2]: I know that the exception is first caught by the debugger, and that this is completely normal. You'll notice in the log that I manually skip over the first-chance exception, and force it to rise into my program. I'm wondering about the origin of such an error, rather than the handling.

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（2）

心奴独伤 2024-12-02 04:08:25

加载库时，RtlpWaitForCriticalSection 中的访问冲突通常是由于库尝试在 DllMain 中使用 LoadLibrary 或 kernel32.dll 之外的代码引起的，因为操作系统在调用该例程时持有“加载程序锁”。

Access violations in RtlpWaitForCriticalSection when loading a library, is typically caused by the library trying to use LoadLibrary or code outside of kernel32.dll, in DllMain since the OS holds a "loader lock" while calling that routine.

回复 原文
七色彩虹 2024-12-02 04:08:25

请参阅 Microsoft 支持- 第一次和第二次机会异常处理

使用 SEH 作为信号机制是一种常见的做法。一些
应用程序编程接口 (API) 注册异常
预计出现故障​​情况的处理程序
发生在较低层。

当引发异常时，处理程序可能会纠正或忽略异常
条件而不是允许故障向上传播
中间层。这在复杂的环境中非常有用，例如
作为预计会发生部分故障的网络，但事实并非如此
仅仅因为几个原因之一就希望整个操作失败
可选部件失败。在这种情况下，可以这样处理异常
应用程序无法识别异常
发生了。

但是，如果正在调试应用程序，调试器会看到所有
在程序执行之前发生异常。这就是两者之间的区别
第一次和第二次机会异常：调试器获得第一个
有机会看到异常（因此得名）。如果调试器允许
程序继续执行并且不处理异常，
程序将像往常一样看到异常。如果程序没有
处理异常，调试器有第二次机会看到
例外。在后一种情况下，程序通常会崩溃，如果
调试器不存在。

如果您不想在调试器中看到第一次机会异常，
您应该禁用特定的第一次机会异常处理
异常代码。否则，当第一次有机会发生异常时，您
可能需要指示调试器将异常传递给
程序照常处理。

See Microsoft support - First and second chance exception handling

It is a common practice to use SEH as a signaling mechanism. Some
application programming interfaces (APIs) register an exception
handler in anticipation of a failure condition that is expected to
occur in a lower layer.

When an exception is raised, the handler may correct or ignore the
condition rather than allow a failure to propagate up through
intervening layers. This is very useful in complex environments such
as networks where partial failures are expected and it is not
desirable to fail an entire operation just because one of several
optional parts failed. In this case, the exception can be handled so
that the application does not recognize that an exception has
occurred.

However, if the application is being debugged, the debugger sees all
exceptions before the program does. This is the distinction between
the first and second chance exception: the debugger gets the first
chance to see the exception (hence the name). If the debugger allows
the program execution to continue and does not handle the exception,
the program will see the exception as usual. If the program does not
handle the exception, the debugger gets a second chance to see the
exception. In this latter case, the program normally would crash if
the debugger were not present.

If you do not want to see the first chance exception in the debugger,
you should disable first chance exception handling for the specific
exception code. Otherwise, when the first chance exception occurs, you
may need to instruct the debugger to pass on the exception to the
program to be handled as usual.

回复 原文
~没有更多了~

关于作者

两相知

暂无简介

文章
评论
27 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

尘曦

文章 0 评论 0

在梵高的星空下

文章 0 评论 0

善良天后

文章 0 评论 0

韬韬不绝

文章 0 评论 0

qq_CgiN62

文章 0 评论 0

不美如何

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文