PRB: The CryptoAPI Function Generates an Error When You Try to Connect to an Instance of SQL Server 2000 (321459)


The information in this article applies to:

  • Microsoft SQL Server 2000 Desktop Engine (MSDE)
  • Microsoft SQL Server 2000 Personal Edition
This article was previously published under Q321459

SYMPTOMS

You may receive the following error message when you try to connect to an instance of SQL Server from a client computer:
MSSQL Server logon. Connection failed. SQL State 42000 SQL Server error 552

[Microsoft][ODBC SQL Server Driver][SQL Server]CryptoAPI function 'CryptAcquireContext' failed.
Error 0x8009001d: Provider DLL failed to initialize correctly.
You can receive this error message in various situations; however, this article only applies to situations in which you receive the error message and all of the following conditions are true:
  • The client application is trying to connect to an instance of Microsoft SQL Server 2000 Personal Edition or Microsoft SQL Server 2000 Desktop Engine.
  • The computer that is running SQL Server Personal Edition or Desktop Engine has at least 512 MB of physical RAM.
  • The computer that is running SQL Server Personal Edition or Desktop Engine is running one of the following operating systems:
    • Microsoft Windows NT 4.0 Server
    • Microsoft Windows NT 4.0 Enterprise
    • Microsoft Windows NT 4.0 Workstation
  • You are using SQL Server Authentication to connect to the instance of SQL Server Personal Edition or Desktop Engine.

CAUSE

SQL Server uses the Windows NT CryptoAPI functions for authenticating SQL Server (Standard Security) logins that are trying to connect to an instance of SQL Server. In this case, the CryptoAPI .dll files does not load because of a problem with the Ole32.dll file, which dynamically rebases. The .dll file rebases because SQL Server was already using its default load address, which causes a handled access violation and the error that is returned to the client computer. For additional information about this handled access violation, click the article number below to view the article in the Microsoft Knowledge Base:

193430 PRB: Relocating OLE32.DLL Causes an Access Violation

WORKAROUND

To work around this problem, have SQL Server or Desktop Engine load Ole32.dll during the server startup process. To do this, configure the sp_MSgetversion stored procedure as a startup stored procedure:
  1. On the computer that is experiencing the problem, use the osql utility to try to connect to an instance of SQL Server or Desktop Engine Windows NT Authentication. Make sure to use Windows NT Authentication while you are logged on with a Windows NT account that is a member of the SQL Server sysadmin role. If you can do this successfully, go to step 7.
  2. Use the following code to modify the Boot.ini file. Use the /maxmem=96 option to limit the physical memory that Windows NT 4.0 registers to 96 MB:
    multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows NT" /maxmem=96
    For additional information about the maxmem option, click the article number below to view the article in the Microsoft Knowledge Base:

    108393 MAXMEM Option in Windows NT BOOT.INI File

  3. Restart the operating system.
  4. In Task Manager, verify that the physical memory that Windows NT registers is 96 MB. If not, make sure that you performed step 2 correctly.
  5. Start Desktop Engine.
  6. Try to connect to SQL Server Desktop Engine by using the osql utility. Use the sysadmin login and the appropriate password. If you cannot connect, note the error message that you receive, and then open a support incident with Microsoft Product Services (PSS).
  7. If you can connect to the instance of SQL Server or Desktop Engine by using the osql utility, run the following query to set up the startup stored procedure: 
    SP_PROCOPTION 'sp_MSgetversion', 'STARTUP', 'TRUE'
  8. Restart the instance of SQL Server or Desktop Engine.
  9. View the most recent Errorlog file and verify that the sp_MSgetversion is being called during the SQL Server startup process: 
    2002-04-30 13:09:28.00 spid3     Launched startup procedure 'sp_MSgetversion'
    If you do not see this in the Errorlog file, repeat step 6 through step 8.
  10. Connect to the instance of SQL Server or Desktop Engine by using the sa account. If you cannot connect, note the error message that you receive, and then open a support incident with Microsoft Product Services (PSS).
  11. If you performed step 2 to reduce the memory that the operating system registers, modify the Boot.ini file, but remove the /maxmem=96 parameter that you originally added in step 2. Restart the computer, and then verify that Windows NT 4.0 can now see all the physical memory that is on the computer.

MORE INFORMATION

To view a complete list of Microsoft Product Support Services phone numbers and information about support costs, visit the following Microsoft Web site:

http://support.microsoft.com/default.aspx?scid=fh;EN-US;CNTACTMS

Modification Type:MajorLast Reviewed:10/30/2003
Keywords:kbprb KB321459 kbAudDeveloper
©2003 Microsoft Corporation. All rights reserved.