Home/ Questions/Q 3607238
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T21:21:03+00:00

I’m trying to debug a C/C++ Win32 DLL with WinDbg, but at the moment

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    “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).

    • 0