Access violation when loading dll

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 wind开发者_C百科ows 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.

---

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.

---

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.