I'm wondering if anyone else has experienced failed DLL's after upgrading their servers.
My company is in the process of upgrading our code and server's after ten years of using classic ASP. We've set up our new server running Windows 2008 and IIS 7. Our classic ASP code and our new asp.net mvc code work pretty well.
Our problems started happening when we began moving our old websites to the new server. When trying to load the page on the actual server machine's browser, we initially got a 500 error. If we refreshed the page then some of the page would load but then display an error:
Server object error 'ASP 0177 : 800401f3'
Server.CreateObject Failed
/folder/scriptname.asp, line 24
800401f3
btw: On remote machines we would just get 500 errors.
Line 24 is the first executable code in the script:
'23 lines of comments
set A0SQL_DATA = server.createobject("olddllname.Data")
'the rest of the script
That specific line is trying to use a ten year old DLL to create a server object. I don't think the server configuration is a problem because I'm able to create "adodb.recordset" server objects without any problems.
Is there an issue when running correctly registered old DLL's on 64 bit systems?
Is there a way to get old DLL's working on 64 bit systems?
Edit
I have confirmed that the site's application pool is running in 32bit compatability mode, but the site still sends the same errors whenever set A0SQL_DATA = server.createobject("olddllname.Data") is called.
Is there an issue when running correctly registered old DLL's on 64 bit systems?
Yes, the most prominent example of a 32-bit DLL no longer working on 64-bit Windows seems to be the Microsoft Jet Engine, i.e., the driver required to access .mdb files. Since there is no 64-bit version, the only way to access .mdb files in classic ASP application is to run IIS (or the Application Pool, to be precise) in 32-bit compatibility mode.
How to detect if you are in 32 or 64 bit mode (untested):
Set shell = CreateObject("WScript.Shell")
Response.Write shell.ExpandEnvironmentStrings("%PROCESSOR_ARCHITECTURE%")
This should output AMD64 in 64-bit mode and x86 in 32-bit mode (either native 32-bit or 32-bit emulation on a 64-bit processor).
Well, error 800401f3 means "invalid class name." That strongly suggests that the DLL is registered with the wrong ProgId (or that the ProgId is missing entirely). When your sys admin verified that the DLL was registered, did he also verify that its ProgId is "olddllname.Data"?
Related
While migrating a Classic asp project from windows server 2003(IIS 6) to windows server 2008 R2(IIS 7.5), the Menu is not getting loaded, when checked in the log. It displays the below error.
Menu.asp |107|ASP_0177_:_800401f3|Server.CreateObject_Failed
When checked the code, the line shows
Server.CreateObject("webCalendarv1.objCalandar")
Can some one please help me why im getting this error.
Server.CreateObject_Failed
This type of error usually means the component (DLL) you are trying to reference isn't installed on that server or your syntax is incorrect.
As you say that you've moved servers I would suggest that you check that the
webCalendarv1.objCalandar
component is installed/registered on your new server. Most likely you can move the relevant DLL file across and run;
Regsvr32.exe nameofthecomponent.dll
One thing you'll have to check is that you have the correct bit version of your component that matchs the bit version of your Windows Server OS. There is an option within IIS that allows use of 32bit components on a 64bit Windows Server for a specific App Pool.
We have a web application built with target framework as x86.
On Server 2008 (IIS 7/7.5) we are able to run the application without any issue (For 64 bit system we enable 32 bit application from app pool).
On 32 bit server 2003 - no issue.
On 64 bit server 2003 (SP2) - we are unable to load a dll:
Could not load file or assembly 'acPDFCreatorLib.Net' or one of its dependencies. An attempt was made to load a program with an incorrect format.
We know this error comes on 64 bit system when Enable 32bit application is set to false. So I tried the following:
Ran the script:
cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 1
The issue persisted.
%SYSTEMROOT%\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -ir
On running this the World Wide Web Publishing service stops.
On trying to restart we are getting the following error
ISAPI Filter 'C:\WINDOWS\microsoft.net\Framework\v2.0.50727\aspnet_filter.dll' could not be loaded due to a configuration problem. The current configuration only supports loading images built for a AMD64 processor architecture.
Any ideas?
Below worked for me regarding the issue "Could not load file or assembly 'acPDFCreatorLib.Net' or one of its dependencies. An attempt was made to load a program with an incorrect format."
Go to Application Pools => Select the AppPool you have created (Else Choose DefaultAppPool or ASP .Net v4.0)
Right click AppPool and Select Advanced Settings
Set Enable 32-bit Applications to True
Reset IIS and Check
The following fixed the issue for me:-
Right Click "Web Sites" and select property
Go to Services tab.
Uncheck - "Run WWW services in IIS 5.0 isolation mode".
After removing the selection from Run WWW Services...., I was able to start the service.
I tried installing my old ASPImage from server Objects in my new server, but the object is not created even though the dll is registered and ASP is enabled in IIS7. Does anyone have any ideas on this issue, or used a different component that can be called from VBS as well as ASP classic?
I tried running tests on the object and it returns internal server errors. When running in VBS, no errors but it ignores the object.
Thanks
James F.
Assuming you have a 64 bit Web Server, you have to enable the setting "Enable 32-Bit Applications" in the Application Pool using the 32bit Component.
See here for further details:
http://help.webcontrolcenter.com/KB/a1114/how-to-enable-32-bit-application-pool-iis-7-dedicatedvps.aspx
May you help me, My ASP.NET application can't import excel file when migrating this application that run in Win Server 2003 32-bit to the Win server 2008 64-bit environment.
How to fix this bug? because in Win Server 2003 32-bit, it runs properly.
the error report that appear is:
*System.Runtime.InteropServices.COMException (0x800A03EC): Exception from HRESULT: 0x800A03EC at Microsoft.Office.Interop.Excel.Workbooks.Open(String Filename, Object UpdateLinks, Object ReadOnly, Object Format, Object Password, Object WriteResPassword, Object IgnoreReadOnlyRecommended, Object Origin, Object Delimiter, Object Editable, Object Notify, Object Converter, Object AddToMru, Object Local, Object CorruptLoad) at Admin_ImportRisk.CreateTempTable() in C:\inetpub\wwwroot\ERMApproval\Administrator\ImportRisk.aspx.vb:line 66.*
The code in line 66 of my application is:
oBooks.Open(Server.MapPath("~/App_Data/Risk.xls"))
I have tried several scenarios:
Added Network Service user to the Microsoft Excel Application in DCOM configuration and set the identity of Application pool that in used to be same.
Added all many kind of user to the Microsoft Excel Application and My computer in security of DCOM configuration. And I have added many kind of user too in the application's folder.
Used corflags.exe to force 32-bit application to run in 64-bit environment
Used regsvr32.exe to register a Microsoft.Office.Interop.Excel.dll file to the windows 32-bit component services.
Used rundll32.exe to run the 32-bit Microsoft.Office.Interop.Excel.dll file in the 32-bit environment
But the result is still the same.
It will be a big honour if you can help me^^.
Best regards,
-imanuel-
The simple answer is to compile your project to target x86 only. This is a setting in the project settings. So the .net framework will only generate a 32 bit application at runtime, rather than defaulting to 64 bit. This is no different from setting corflags, however if you have multiple assemblies you ahve to make sure it's done for all of them. The application itself must target only 32 bit.
You're using a COM component that is 32 bit, and you can't do that in a 64 bit application, so force it to be 32 bit.
You can also force IIS to run it in the 32 bit context as documented here:
http://lostechies.com/gabrielschenker/2009/10/21/force-net-application-to-run-in-32bit-process-on-64bit-os/
Also, make sure the 64 bit version of Excel is not installed on the server, but rather the 32 bit version.
I am having an issue related to executing a .Net dll from a classic asp application on a 64 Bit Windows Server 2008 server running IIS7. The situation is as follows:
I have written a .Net C# assembly to perform some encryption tasks. This assembly has been made available to the classic ASP environment via inheriting from ServicedComponent, ensuring the assemblyinfo file has the ComVisible(true) attribute, and it has been installed using the "regsvcs" command line.
When testing on my own desktop (XP running IIS6) everything worked fine. When moving to IIS 7, Windows Server 2008 I get the infamous "ASP 0177 Server.CreateObject failed".
I have tried the following to no avail:
Ensuring the ASP and Script Extension features were installed on the server, as this is not the default for IIS7. This allowed me to execute simple ASP commands, but not server.createobject for the .net assembly.
Enabled 32 Bit application support for the app pool supporting the classic asp site
Used NetworkService as the identity for the app pool supporting the classic asp site
Tried registering dll using regsvr32, which failed
I am able to create other objects such as "scripting.filesystemobject"
Moving dll's to the wow64 directory and then using regsvcs to register them.
And yes when I have been executing the regsvcs commands they have been from a command line launched with "RunAs" Administrator. The regsvcs commands have registred successfully
from both the 64 and 32 bit versions. However, when used from the classic asp application, it fails.
This question is closely related to this one. However, I think this question was more related to using tools on the server as opposed to a programatic problem similiar to mine.
Anyone have any more ideas to try?
After a lot of help here and some more research, we finally came across the answer. To solve our issue we did the following:
No longer inherit from ServiceComponent (This is ok, since we are not actually leveraging any specific COM+ features)
Utilized the following commands to install the component, which must be done in order:
gacutil /i "C:\Inetpub\wwwroot\ASPTest*name of dll*"
regasm /tlb "C:\Inetpub\wwwroot\ASPTest*name of dll*"
This process eliminated the original errors and also had the added benefit of being able to replace the dll while IIS is running.
Try this
Component Services -> Computers -> My Computer -> COM+ Applications
Open a COM+ Application object.
Open Components.
Right-click on a class and select Properties.
Under "Advanced" there is a check box for "Allow IIS intrinsic properties".
It works for me
Create a vbs test file and try to create your COM object there. If you can't (i.e. you get the same error) then your component is not registered correctly.
If you can - then it was installed correctly and the problem is with the lack of permissions for the account your application is executed under in IIS.