Saturday, November 22, 2008

The procedure entry point ?SQLUIUpdateRegistryFromResource@@YAJHPAUHINSTANCE__@@IKPAPBG1@Z could not be located in the dynamic link library SQLRESLD.dll.

Had a customer the other day who was installing an app on Windows 2000 Professional. We don't see Windows 2000 much any more, even 2000 Server. Anyway, this particular machine had been around for years, and had a lot of old apps installed on it, including Microsoft SQL Server version 7.

Whenever the customer would launch our app, he'd get this error:

The procedure entry point ?SQLUIUpdateRegistryFromResource@@YAJHPAUHINSTANCE__@@IKPAPBG1@Z could not be located in the dynamic link library SQLRESLD.dll.

Then he'd click OK, and he'd get this error:

System.Runtime.InteropServices.COMException (0x8007007F): Retrieving the COM class factory for component with CLSID {10020200-E260-11CF-AE68-00AA004A34D5} FAILED DUE TO THE FOLLOWING ERROR: 8007007F.

This second error was recognizable - that's the class ID for SQL-DMO, which the app uses to communicate with SQL Server. We see that 0x8007007F error for that class ID all the time, on machines where SQL-DMO is not registered.

The usual solution is to go find SQLDMO.DLL in C:\Program Files\Microsoft SQL Server\80\Tools\Binn, and register it using regsvr32.exe. Or, sometimes we throw a copy of SQLDMO.DLL and SQLDMO.RLL in our own app folder, and register it there, just to get by.

(A quick note about registering DLLs: you can bring up a command window and navigate to the folder where the DLL resides, and then run regsvr32.exe sqldmo.dll, for example. But most of the time, I right-click on the DLL and choose Open With, and browse to regsvr32.exe in C:\Windows\System32, and make a permanent file type association. That way, from then on I can register any DLL just by double-clicking it. If I get an error that the DllRegisterServer entry point can't be found, then I know it didn't need registering in the first place.)

Back to the IKPAPBG1 issue. we tried to register SQL-DMO, and that failed. I don't have the error handy, but the gist of it was that some RLL couldn't be found at C:\Resources\1033. For this, we tried brute force, and copied

C:\Program Files\Microsoft SQL Server\MSSQL$INSTANCENAME\Binn\Resources\1033

to

C:\Resources\1033.

Not the "right" solution, but worth trying to see if it would get us up and running.

Tried to register SQLDMO.DLL again, and this time, the error thrown by regsvr32 was

C:\Program Files\Microsoft SQL Server\MSSQL$INSTANCENAME\Binn\sqlresld.dll
was loaded, but the DllUnregisterServer entry point was not found.

DllUnregisterserver may not be exported, or a corrupt version of C:\Program Files\Microsoft SQL Server\MSSQL$HDBID\Binn\sqlresld.dll may be in memory. Consider using PView to detect and remove it.

By this time, all the errors together were beginning point to a versioning problem. As if, for some reason, version 7 DLLs were being accessed instead of version 8 (2000). What would make that happen?

In Add/Remove programs, we could see that MSSQL 7 was still installed, although it wasn't running. We checked the Path environment variable, and noticed that C:\MSSQL7 was near the front of the list.

We considered removing it from the Path, since it wasn't in use, but decided instead to try renaming the C:\MSSQL7 folder so it wouldn't interfere. And that did the trick. We ran regsvr32.exe sqldmo.dll, and it worked, and we launched the app, and it worked too.

Solved. If this story helps you, post a comment and let me know!

No comments: