MSSQL Server Logon Connection Failed

Problem:

The following error appears when using TimeForce with Windows NT 4.0 Server Edition:

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

Solution:

The solution for this issue is taken from Microsoft Knowledge Base Article 321459.  To access this article directly, go to the following web address:

http://support.microsoft.com/default.aspx?scid=kb;en-us;321459

The CryptoAPI Function Generates an Error When You Try to Connect to an Instance of SQL Server 2000

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 file 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.

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
     

  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