Server createobject error

Background

One of my team member moved the IIS site from Windows Server 2000 to Windows 2008 R2 and got the error message below.

Error

Error at line 165 Server.CreateObject Failed

Code

Set CDONTSObj = Server.CreateObject("CDONTS.NewMail")  

Case History

In our production environment this site works fine, but after moving the site to new environment this fails. Case document has no clear information. What to do ? Goolge, Bing? Can we scrub our Event Viewer? Choose anything you want but before that we should
know how the site was moved. Did you moved and registered the required DLL’s? Nope, why should we do when rest of the sites are working fine? Yes, this is what most of the Admins will conclude. Before deciding we should think about the functionality of the
site/Application. All other working applications doesn’t use SMTP but this is consuming the SMTP service to trigger emails.

How to Fix

Assuming your application is running in 32 bit. Delegate appropriate access to all users in Access MDB file. So that it will make an entry for Order placement and retrun. Confirmed that entry found in access file. Okay we are progressing positively. Try to
send email by clicking send button and scrubbed event viewer. No dice, no error found. But application gave the same error message.

Application Code

Set CDONTSObj = Server.CreateObject("CDONTS.NewMail") 
 CDONTSObj.To = strUserEmail 
 CDONTSObj.CC = strRequesterEmail 
 CDONTSObj.MailFormat = 0 
 CDONTSObj.BodyFormat = 0 
 CDONTSObj.From = "ICT Services" 
 CDONTSObj.Subject = "Random-" + cStr(intReference) 
 CDONTSObj.Body = strEmail1 
 CDONTSObj.Send 
 Set CDONTSObj = nothing

Clue

Set CDONTSObj = Server.CreateObject(«CDONTS.NewMail») This is failing to create an object and throws an exception.

What is CDONTS?

CDONTS: Colloboration Data Objects for Windows NT server over SMTP.

Reference Link: CDONTS

Now a quick call to fix this? Shall we change the code ? or Shall we register the DLL?

Solution

Register CDONTS DLL is easy, but a time consuming fix.

How to Register DLL?

1. Step 1: Copy CDONTS DLL from your server or download new DLL
2. Step 2: Open Command Prompt as Administrator.
3. Step 3: Navigate to path C:WindowsSystem32regsvr32.exe D:CDONTSCDONTS.DLL
4. Step 4: Close all your Browser and reset IIS (Optional)

Note: D:CDONTS is the path where I moved my DLL you can change as required.

The advice below relates to both Server.CreateObject and CreateObject use in

vbscript jscript vba

The Web Server sections are specific to asp-classic but still worth reading.

What Causes This error?

Server.CreateObject Failed

is caused most commonly when Web Applications are moved from one Web Server to another without an understanding of external COM components that are in use and registered with the Web server.

_{From PRB: Server.CreateObject Returns HTTP 500.100 or ASP 0177 Error (0x8007007E)}

This error occurs when you attempt to use the Server.CreateObject method to instantiate an object that is not registered on the local system.

Identifying the Source of the Error

If you are using COM components inside a ASP Web application you will see a line like this

set g_pcmsrv=Server.CreateObject("PCMServer.PCMServer") 

Usually the error will point to the Set line which makes identifying the cause easier (luckily you have some nice trace code in place so it’s even better).

What If You Don’t Know Where the DLL Is Located?

Note: Please be careful when accessing the Windows Registry as it is very easier to inadvertently make changes that have serious consequences for the Operating System and in extreme cases will require a system restore or re-install / repair.

The string inside the CreateObject method is known as a ProgId and is used as an identifier to a key inside the Windows Registry that can be found inside the

Note: Windows Registry can be browsed in most versions of Windows using the regedit.exe also known as the Registry Editor. Be very careful when using this tool to browse the Windows Registry.

HKEY_CLASSES_ROOT

and by extension

HKEY_LOCAL_MACHINEClasses

Whenever the ASP processor encounters a ProgId it attempts to talk to the Windows Registry and find a corresponding key that denotes the location of the registered COM accessible DLL.

HKEY_CLASSES_ROOTPCMServer.PCMServer

A common approach to this is the key contains a subkey called CLSID which points to the Class GUID for the associated registered DLL. Once the GUID key is located in the

HKEY_CLASSES_ROOTCLSID

hive it can be used to find the location by looking in the subkey

HKEY_CLASSES_ROOTCLSID{GUID from CLSID}InprocServer32

where the location will be stored in the (default) value.

Example Using the ProgId — Scripting.FileSystemObject

1. Locate Scripting.FileSystemObject subkey in HKEY_CLASSES_ROOT

   HKEY_CLASSES_ROOTScripting.FilesystemObject
   

2. Identify GUID from subkey CLSID

   HKEY_CLASSES_ROOTScripting.FilesystemObjectCLSID
   
   (default) - "{0D43FE01-F093-11CF-8940-00A0C9054228}"  
   

3. Use GUID to find registered DLL subkey in HKEY_CLASSES_ROOTCLSID

   HKEY_CLASSES_ROOTCLSID{0D43FE01-F093-11CF-8940-00A0C9054228}
   

4. Check subkey InprocServer32 (default) value for the DLL location

   HKEY_CLASSES_ROOTCLSID{0D43FE01-F093-11CF-8940-00A0C9054228}InprocServer32
   
   (default) - "C:WindowsSystem32scrrun.dll"
   

No ProgId for PCMServer.PCMServer in the Registry?

If you cannot find the corresponding ProgId in the registry it is likely due to one of two reasons we will elaborate on here.

1. The DLL is not registered.
2. The DLL is registered in the wrong area.

How to register COM DLL with Windows

COM DLLs can be registered and have the corresponding Registry entries created by running the regsvr32.exe tool from the Windows Command Prompt using elevated permissions (this varies from version to version of Windows).

Before we continue though the architecture of both the Operating System and the mode used by the ASP Web application are very important.

Most newer hardware is 64 Bit this creates a conundrum in Windows as it now has to support newer 64 bit architecture and still maintain support for 32 bit architecture. The solution Microsoft came up with was to split the OS in two, so we have 64 bit elements and 32 bit elements. The main OS programs are broken down into two folders (only on 64 bit OS because a 32 Bit OS doesn’t have to contend with 64 Bit, even if the hardware is capable of it).

Note: On 32 Bit only systems just use the 64 Bit locations for both System Files and the Windows Registry.

On a 64 Bit OS the System Programs are located in

1. For 64 Bit programs

   %SystemRoot%System32
   

2. For 32 Bit programs

   %SystemRoot%SysWOW64
   

This is also applies to the Windows Registry

1. 64 Bit

   HKEY_CLASSES_ROOT
   

2. 32 Bit

   HKEY_CLASSES_ROOTWow6432Node
   

So for example on a 64 Bit version of Windows, the following command will register the PCMSRV32.DLL in the 32 Bit Registry and create the associated COM DLL registry keys.

C:WindowsSysWOW64>regsvr32 "C:WindowsPCMSRV32.DLL"

IIS Application Pool

As everything begins to support 64 Bit including IIS you still need to be able to support legacy applications that only support 32 Bit COM, so IIS introduced in IIS 6.0 (starting with Windows Server 2003, Service Pack 1) under the Application Pool settings the configurable property Enabled32BitAppOnWin64 which allows the Application Pool to run in 32 Bit mode on 64 Bit versions of Windows.

With this in mind before you register the COM DLL to know where you should be registering it you need to know whether the Application Pool is running in 32 Bit Mode. In IIS 7.0 and above you can just check this from the Application Pool properties inside the IIS Manager application. The setting is in the Advanced Settings under the General section and is called Enable 32-Bit Applications (can also be configured in the applicationHost.config using enable32BitAppOnWin64 under the <ApplicationPools> section).

• If Enable 32-Bit Applications is set to False

  The IIS Application Pool is running in native 64 Bit mode and any COM DLLs that need to be used by the ASP Web Application will need to support 64 Bit and be registered using the 64 Bit version of regsvr32.exe to be added into the 64 Bit registry.

  C:WindowsSystem32>regsvr32 "C:WindowsPCMSRV32.DLL"
  

• If Enable 32-Bit Applications is set to True

  The IIS Application Pool is running in 32 Bit Mode and any COM DLLs that need to be used by the ASP Web Application will need to be 32 Bit COM DLLs and be registered using the 32 Bit version of regsvr32.exe to be added into the 32 Bit registry.

  C:WindowsSysWOW64>regsvr32 "C:WindowsPCMSRV32.DLL"
  

Registering the COM DLL Using the Wrong Version of regsvr32.exe

For example, using

C:WindowsSysWOW64>regsvr32 "C:WindowsPCMSRV32.DLL"

to register the COM DLL with the 32 Bit registry on a 64 Bit version of Windows when the IIS Application Pool is not in 32 Bit Mode will cause the ASP 500.100 Internal Server error

Server object error ‘ASP 0177: 8007007e’

Server.CreateObject Failed

COM DLL Checklist

1. What is the IIS Application Pool Advanced Setting Enable 32-Bit Applications set to, as it impacts on how you register the COM DLL?

2. Is the DLL registered using the architecture-specific version of regsvr32.exe (if Windows version isn’t 64 Bit use the default) that reflects the setting of Enable 32-Bit Applications?

3. Does the Windows Registry contain a ProgId for the DLL in the architecture-specific location of

   HKEY_CLASSES_ROOT
   

   that reflects the setting of Enable 32-Bit Applications?

4. Does the InprocServer32 key contain the correct location for the DLL?

5. In the context of the account I’m using to access the COM DLL (ApplicationIdentity, LocalSystem, NetworkService etc), do I have permission to access both the physical DLL file and the registry entries?

Useful Links

• PRB: Server Object Error ‘ASP 0177:80040154’ Server.CreateObject.

Over the past year or so we’ve been wrestling with an intermittent error from classic ASP when trying to instantiate .NET components with Server.CreateObject. Everything works fine 90% of the time, and now and then we’ll start seeing this error:

Server object error 'ASP 0177 : 8000ffff'
Server.CreateObject Failed
<FileName>.asp, line <LineNumber>
8000ffff

Once this error starts happening, it generally persists until we move the application to another application pool or restart IIS. Recycling the app pool does not fix the problem.

Unfortunately, the error message and number are fairly generic, so it’s been pretty tricky to track down. There are lots of people with very similar issues posting all over the web that have solved them in various ways. None of the solutions we found have ever worked for us. Most of them were people seeing the error all the time (eg. permissions errors), but we found very few people seeing our behaviour where the code would just randomly stop working.

After many, many months of searching, we found some reports of similar behaviour being caused by installing an Internet Explorer 7 patch. Many people were rolling the patch back with some success. Rolling back patches doesn’t seem like the best thing in the world, so we’ve always avoided the complications that go with it.

The Solution

Eventually, we found the solution. It’s in this Microsoft knowledgebase article KB945701. The problem appears to be a failure to read some IE-related values from the registry. The hotfix on the page above (which is included in the latest service pack, so you probably do not need the hotfix) adds the ability to ignore these errors by setting a registry key:

• Locate and then click the following registry subkey:

  HKEY_LOCAL_MACHINESOFTWAREMicrosoftInternet ExplorerMAINFeatureControlFEATURE_IGNORE_ZONES_INITIALIZATION_FAILURE_KB945701

  Note If the FEATURE_IGNORE_ZONES_INITIALIZATION_FAILURE_KB945701 subkey does not exist, you must manually create it.
  If you’re using a 64 bit OS, you may need to use HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftInternet ExplorerMAINFeatureControlFEATURE_IGNORE_ZONES_INITIALIZATION_FAILURE_KB945701 instead (thanks Brad Baker!)

• Right-click FEATURE_IGNORE_ZONES_INITIALIZATION_FAILURE_KB945701, point to New, and then click DWORD Value.
• Type w3wp.exe to name the new registry entry, and then press ENTER.
• Right-click w3wp.exe, and then click Modify.
• In the Value data box, type 1, and then click OK.

After setting this registry key, a simple app pool restart will apply the change. No longer will your .NET COM components randomly stop working with no real solution except shuffling application pools!