Re: CryptAcquireContext _sometimes_ fails with NTE_PROVIDER_DLL_FA

From: lelteto (lelteto_at_discussions.microsoft.com)
Date: 11/23/05 

Date: Wed, 23 Nov 2005 10:41:05 -0800

>From your description (when debugging it works and with simple app it works)
you may have somewhere a synchronization problem. Try to look into the
buffers you are sending to the crypto calls:
- are they valid?
- are they used somewhere else?
- maybe they are freed while still used within the crypto function?
(When you are debugging usually the debugger stops the other threads, so
these type of errors won't show up.)

Laszlo Elteto
SafeNet, Inc.

"Stephan Keil" wrote:

> Thanx, yes, I've tried CRYPT_VERIFYCONTEXT, but it didn't help. Finally
> I solved the problem on the WinXP machines, now I am not using the
> default container but a named one.
> Here's what I do:
>
> // create container if not already there
> CryptAcquireContext(&hdl, _T("MyContainer"), MS_ENHANCED_PROV,
> PROV_RSA_FULL, CRYPT_NEWKEYSET); // may fail if container already exists
>
> // ... and somewhere later
> CryptAcquireContext(&hdl, _T("MyContainer"), MS_ENHANCED_PROV,
> PROV_RSA_FULL, 0); // should not fail
>
> This works on WinXP, but on Win2003 Server SE I have the following effects:
> 1. When using these calls within the target application (huge MFC MDI
> application with ComServer etc., but started as normal EXE) and the
> rsaenh.dll shipped with Win2003 Server (version 5.2.3790.1830
> (srv03_sp1_rtm.050324-1447)), the application silently closes without a
> notice and return value 128
> 2. When using these calls within a test application (command line app),
> they work just fine
> 3. Doing 1. with the rsaenh.dll from WinXP copied to Win2003 Server
> (version 5.1.2600.2161 (xpsp.040706-1629)), the calls fail with
> NTE_PROVIDER_DLL_FAIL (0x8009001D)
> 4. Doing 1. or 3. with a remote debugger connected to the application
> (connected before the calls) the calls succeed
>
> Any ideas?
>
> Thanks & Regards, Stephan
>
> lelteto wrote:
> > Did you try CryptAcquireContext with CRYPT_VERIFYCONTEXT flag? If that works
> > and your call doesn't that means you don't have default container on those
> > systems.
> >
> > Laszlo Elteto
> > SafeNet, Inc.
> >
> > "Stephan.Keil@gmx.de" wrote:
> >
> >
> >>Hi,
> >>
> >>in a program I call
> >> CryptAcquireContext(&hdl, NULL, MS_ENHANCED_PROV, PROV_RSA_FULL, 0)
> >>which always succeeds on some machines (esp. WinXP), but fails on
> >>others (Win2003 Server, but also other WinXP) with
> >>NTE_PROVIDER_DLL_FAIL (0x8009001D).
> >>I tried to remote debug the software on those machines but when using
> >>the remote debugger the call succeeds :-o.
> >>
> >>I tried to track the problem with FileMon from SysInternals, which
> >>shows me that in both cases the rsaenh.dll is looked up and found in
> >>c:\windows\system32. At some time the access pattern changes but this
> >>doesn't make sense to me (I can provide more details if necessary).
> >>
> >>Any hint what's going wrong here?
> >>
> >>Thx & Regards, Stephan
> >>
> >>
>

Relevant Pages

  • Re: Problem in adding file to deployment
    ... in the debug folder when debugging. ... >> 1.1) A solution is a container for projects, ... >> lack the Build Action property. ... >> setup knows the path because you have added it... ...
    (microsoft.public.vsnet.general)
  • Debugger / message pump problems
    ... I'm having problems debugging a MFC app in eVC++ 4. ... essentially a container for several ActiveX controls with a ... on the CE platform get processed, and the debug application runs as ...
    (microsoft.public.windowsce.embedded.vc)