Re: CryptAcquireContext _sometimes_ fails with NTE_PROVIDER_DLL_FA

From: Alun Jones (alun_at_texis.invalid)
Date: 11/25/05 

Date: Thu, 24 Nov 2005 21:31:43 -0800

Stephan Keil wrote:
>> Are you saying that just the Windows API function
>> LoadLibrary("rsaenh.dll") fails in your target application but succeeds
>> in other (simpler) applications (on your Windows Server 2003 system)?
>
> Exactly. And, it also succeeds if I connect a remote debugger to the
> application.
...
> Where I could need a hint is
> - As it works in debugger: what does the debugger do with the
> debugged process? (e.g. does it change the security context?
> or some other things of the process environment?)
> - Why does it work in a simpler application? I checked e.g. (with
> processexplorer) that the favourite base address of the DLL
> and all its (static) dependencies are still available right
> before the LoadLibary call!

Whenever I get behaviour like this, I always check _other_ areas of my code,
particularly other DLLs that I load and call.

Every time - and I mean _every_ time - that a function call that "can't
possibly fail" crashes (and I don't mean fails - I mean it totally blows up
the stack), it's traced back to calling a function with the wrong calling
convention. I'm missing a WINAPI, or a __stdcall, or a __cdecl, or
something like that.

What I'm suggesting is that your stack is _already_ blown before you hit
"LoadLibrary", and something inside of LoadLibrary (probably the return)
demonstrates this.

Alun.
~~~~ 

-- 
[Please don't email posters, if a Usenet response is appropriate.]
-- 
Texas Imperial Software   | Find us at http://www.wftpd.com or email
23921 57th Ave SE         | alun@wftpd.com.
Washington WA 98072-8661  | WFTPD, WFTPD Pro are Windows FTP servers.
Fax/Voice +1(425)807-1787 | Try our NEW client software, WFTPD Explorer.