PRB: ASP Returns VBScript Runtime Error '800a01ad'

ID: Q194801

The information in this article applies to:

Microsoft Internet Information Server version 4.0

SUMMARY

The use of CreateObject to create a COM component in an ASP page may result in the following error:

Microsoft VBScript runtime error '800a01ad'
ActiveX component can't create object

This error is usually generated because DLLs on which the COM object depends are one of the following:

Missing from the system

Not in the system path

Not accessible by the system because of security settings

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 will be generated.

There are many ways to determine DLL dependencies. Among these are the Depends.exe tool (shipped with the Platform SDK and Developer Studio 98) and the DUMPBIN utility (installed with Visual C++). 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:

Server object error 'ASP 0177 : 800401f3'

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 manor 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:

error 'ASP 0115'
Unexpected error
/badguy.asp
A trappable error occurred in an external object. The script cannot
continue running.
Server object error 'ASP 0115 : 8000ffff'

Failure of this type will not generate an 800a01ad error.

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.


Keywords          : kberrmsg kbASP kbCOMt kbVBScript kbGrpASP 
Version           : WINNT:4.0
Platform          : winnt 
Issue type        : kbhowto

Last Reviewed: May 25, 1999