在调试器下加载 DLL 时发生访问冲突
我正在尝试使用 WinDbg 调试 C/C++ Win32 DLL，但目前它因访问冲突而无法加载。这是日志中经过编辑的片段：
ModLoad: 77bd0000 77bd7000 C:\WINDOWS\system32\midimap.dll
ModLoad: ...\PyFM.fmx <-- THIS IS MY DLL
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
...\FMWrapper.dll -
ModLoad: ...\FMWrapper.dll <-- THIS IS ANOTHER DLL I LINK AGAINST
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\WinSxS\x86_Microsoft.VC90.
DebugCRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_f863c71f\MSVCR90D.dll -
ModLoad: 10200000 10323000 C:\WINDOWS\WinSxS\x86_Microsoft.VC90.
DebugCRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_f863c71f\MSVCR90D.dll
(564.970): 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=05e79b68 ecx=b79a0c61 edx=0049e000 esi=05e79c0c edi=00000080
eip=02887094 esp=0012fa0c ebp=00120000 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206
DBEngine!Draco::DBPlugIn::MakeCall+0x94:
02887094 c745fcffffffff
mov dword ptr [ebp-4],0FFFFFFFFh ss:0023:0011fffc=????????
此时的堆栈似乎是这样的（WinDbg 警告信息可能不准确）：
DBEngine!Draco::DBPlugIn::MakeCall+0x94
DBEngine!Draco::DBPlugIn::LoadStringW+0x7e
如果我尝试一步一步继续（虽然我不理解汇编指令），我看到控制是传递给ntdll；例如，下一条指令是：
ntdll!KiUserExceptionDispatcher+0x4:
7c90e480 8b1c24
mov ebx,dword ptr [esp] ss:0023:0012f71c=0012f724
我尝试过：不多，因为我不明白发生了什么。最初，我在 DLL 的非调试版本中遇到了这个错误；然后我尝试使用调试版本，但错误仍然存在。我怀疑清单并阅读了一些有关它们的内容，但这部分似乎没有任何问题；我什至检查过清单文件大小是 4 的倍数:)
为什么会发生这种情况？我要去哪里看？
I'm trying to debug a C/C++ Win32 DLL with WinDbg, but at the moment it fails to load with access violation. Here's an edited snippet from the log:
ModLoad: 77bd0000 77bd7000 C:\WINDOWS\system32\midimap.dll
ModLoad: ...\PyFM.fmx <-- THIS IS MY DLL
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
...\FMWrapper.dll -
ModLoad: ...\FMWrapper.dll <-- THIS IS ANOTHER DLL I LINK AGAINST
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\WinSxS\x86_Microsoft.VC90.
DebugCRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_f863c71f\MSVCR90D.dll -
ModLoad: 10200000 10323000 C:\WINDOWS\WinSxS\x86_Microsoft.VC90.
DebugCRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_f863c71f\MSVCR90D.dll
(564.970): 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=05e79b68 ecx=b79a0c61 edx=0049e000 esi=05e79c0c edi=00000080
eip=02887094 esp=0012fa0c ebp=00120000 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206
DBEngine!Draco::DBPlugIn::MakeCall+0x94:
02887094 c745fcffffffff
mov dword ptr [ebp-4],0FFFFFFFFh ss:0023:0011fffc=????????
The stack at this moment appears to be that (WinDbg warns the information may be inaccurate):
DBEngine!Draco::DBPlugIn::MakeCall+0x94
DBEngine!Draco::DBPlugIn::LoadStringW+0x7e
If I try to continue step by step (although I don't understand assembler instructions) I see that control is passed to ntdll; e.g. the next instruction is that:
ntdll!KiUserExceptionDispatcher+0x4:
7c90e480 8b1c24
mov ebx,dword ptr [esp] ss:0023:0012f71c=0012f724
What I tried: not much, because I don't understand what's going on. Initially I got this error with a non-debug build of the DLL; then I tried to use a debug version, but the error persists. I've suspected manifests and read about them a bit, but nothing seems to be wrong on this part; I even checked that manifest file size is a multiple of 4 :)
Why could it happen? Where I am to look?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
“第一次机会例外”通常是正常的，并且常常可以被忽略。
如果您在调试器中继续该程序——不仅仅是下一条指令，而是让它再次运行；我认为这是 WinDbg 中的“g”命令——它是否有效，或者是否因另一个异常而崩溃（不是“第一次机会异常”）？
（如果您收到另一个“第一次机会异常”，那么您也可以忽略它；这意味着第一个异常已由异常处理程序处理，现在您看到一个完全不同的异常，也可能会被处理。 ）
某些代码使用（或者更确切地说滥用）异常来进行正常的流程控制，这使得在调试器下运行该代码变得困难，而调试器设置为一旦引发异常就会中断。您可以将调试器配置为仅在未处理异常时才中断。
另一方面，如果继续程序确实导致未处理的异常，那么您可能在代码中遇到了错误（可能是由调试器更改某些事物的运行速度或它们运行的顺序而触发的竞争条件） in)，或者您没有在与平常相同的上下文中运行程序（例如当前目录、DLL 路径、环境变量或其他一些不同的东西）。或者，您正在使用的 DLL 可能会显式检查调试器，以尝试阻止人们对其进行逆向工程（但这种情况非常罕见）。
"First chance exceptions" are often normal and can often be ignored.
If you continue the program in the debugger -- not just the next instruction but make it run again; I think it's the 'g' command in WinDbg -- does it work or does it crash with another exception (one which isn't a "first chance exception")?
(If you get another "first chance exception" then you can ignore that as well; it would mean the first exception has been dealt with by an exception handler and now you're seeing a completely different exception which may be dealt with as well.)
Some code uses (or rather abuses) exceptions for normal flow-control, making it difficult to run that code under a debugger which is set to break as soon as an exception is thrown. You can configure the debugger to instead only break when an exception is not handled instead.
On the other hand, if continuing the program does result in an unhandled exception then you've probably got a bug in the code (maybe a race condition that is triggered by the debugger changing how fast certain things run or which order they happen to run in), or you're not running the program in the same context as usual (e.g. the current directory, DLL path, environment variables or some other thing is different). Or maybe a DLL you are using explicitly checks for a debugger to try and stop people reverse engineering it (but that is very rare).