Active Server Pages returns VBScript runtime error '800a01ad' (194801)

MORE INFORMATION

Each of the above reasons applies to the DLL that implements the COM object as well as any of the DLLs dependencies. For instance, if a COM DLL statically links to a Win32 DLL and the Win32 DLL is missing from the system, a 800a01ad error is generated.

There are many ways to determine DLL dependencies. Among these are the Depends.exe tool, which shipped with the Platform Software Development Kit (SDK) and Developer Studio 98, and the DUMPBIN utility, which is installed with Visual C++.

The following files are available for download from the Microsoft Download Center:

Download the Dependsia64version2.1.3623.exe package now.Download the Dependsx86version2.1.3623.exe package now.

Release Date: June 25,2002

For additional information about how to download Microsoft Support files, click the following article number to view the article in the Microsoft Knowledge Base: Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help to prevent any unauthorized changes to the file. For more information about this tool, visit the following Dependency Walker Web site: Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information.

To use Depends, simply run the tool and open the DLL in question. To use DUMPBIN to view the dependencies, run the following at a command prompt "dumpbin /IMPORTS <name of DLL>". The Depends utility has the advantage of displaying dependencies of dependencies. It would appear that quick view in the Windows Explorer would display the same information, but it has been observed that the information displayed is not always complete.

Further information about each of the possible causes follows:

DLLs Missing From the System

The DLL that implements the COM object must exist on the system and be registered with the correct path. Creation failure of a COM object that is not registered at all will actually generate a different error:

To verify that the path in the registry is correct, run the RegEdit program and search for the PROGID (found in the CreateObject call). From the PROGID entry, record or copy the CLSID to the Clipboard and locate the entry for the CLSID. This entry should contain an InprocServer32 key with a path to the DLL. The following illustrates the flow of this process:

   (from the asp file)
   set obj = Server.CreateObject("BadComponent.Badguy")

   (from RegEdit)
   HKEY_CLASSES_ROOT\BadComponent.BadGuy\CLSID
      {683DA7E0-5C73-11D2-80F6-0000F87A8236}

   HKEY_CLASSES_ROOT\CLSID\{683DA7E0-5C73-11D2-80F6-0000F87A8236}\ 
      InprocServer32 E:\Programs\COMPON~1\BADCOM~1\Debug\BADCOM~1.DLL
				

The following commands run from a command prompt will verify the existence of this file:

   E:\>cd E:\Programs\COMPON~1\BADCOM~1\Debug
   E:\Programs\COMPON~1\BADCOM~1\Debug>dir BADCOM~1.DLL

   10/14/98  11:18a               241,739 BadComponent.dll

                  1 File(s)        241,739 bytes
                             2,038,755,328 bytes free
				

If no path is specified in the registry for the DLL, the DLL must exist in the system path.

A COM DLL may have dependencies other than Win32 DLLs that are statically linked (DUMPBIN and Depends.exe show DLLs statically linked). For instance, a COM object may call LoadLibrary() and call functions in a Win32 DLL. Similarly, the control may create COM objects that are contained in separate DLLs. Any of these DLLs may be missing, improperly registered, on inaccessible due to security. This would result in a runtime error that may or may not be encountered during the creation of the control. Returning S_FALSE from the FinalConstruct() method of an ATL control can simulate an example of control failing in such a manner during creation. This assumes LoadLibrary() or CoCreateInstance() failed in FinalConstruct(), and the programmer chose to check for this and return S_FALSE. The error generated in this case will be similar to the following:

DLLs Not in the System Path

The system must be able to find the dependant DLLs (statically linked) of the DLL that implements the COM object being created. Using DUMPBIN or Depends, determine what the dependent DLLs are. Verify that all of these DLLs are either in the same directory as the COM DLL or in the system path.

DLLs Not Accessible by the System Because of Security Setting

When a client requests an Active Server Pages (ASP) page from a server, the ASP page runs in a security context dependant on the authentication method used to access the Web Server. For instance, anonymous requests run in the context of the IUSR_MACHINENAME where MACHINENAME is the name of your computer. For information on other authentication methods and security considerations, please consult the IIS documentation. What this means in terms of an 800a01ad error is that the authenticated user must have access (via NTFS file permissions) to the COM DLL and all of the dependant DLLs.

A shotgun approach can be used to determine if this is the cause of the problem. Using the Windows Explorer, select Properties for the COM DLL, select the Security tab, and grant "everyone" at least read access to the DLL. Do the same for the dependent DLLs and directories containing the DLLs. This should eliminate any security restrictions that may be affecting the creation of the COM object. Security can be tightened after it is determined that this was the problem. Keep in mind, many of the dependant DLLs are Windows system DLLs and will have at least "everyone read" access already. Do not mistakenly remove this access when "tightening" the security.

(c) Microsoft Corporation 1998, All Rights Reserved. Contributions by Robert E. Duke, Microsoft Corporation.