2

I've had to move a classic ASP application from windows server 2008 to Windows Server 2012R2 and the app uses a com object called (aspmail 4.0) from a company called ServerObjects - which is no longer in business (at least there's no way to contact them).

Anyway, I've registered the DLL (C:\Windows\SysWOW64\regsvr32.exe d:\components\aspmail4\smtpsvg.dll), that works as I checked the registry (it's 100% installed no issues nor errors).

I've verified the DLL is correct and the registry is pointing to the correct path (and that there is only 1 path).

I've given every permission I can think of (even tested it with the "Everyone" account) to the DLL file (and IUSR account).

With 32bit disabled in the app pool, I get the "ActiveX component can't create object." error.

With 32bit enabled in the app pool, it just crashes the page (generates a fatal exception) with an error in the event log as follows:

Faulting application name: w3wp.exe, version: 8.5.9600.16384, time stamp: 0x52157ba0
Faulting module name: smtpsvg.dll, version: 4.1.0.0, time stamp: 0x2a425e19
Exception code: 0xc0000005
Fault offset: 0x0004e001
Faulting process id: 0x3f0
Faulting application start time: 0x01cfe5f2dc426b4d
Faulting application path: C:\Windows\SysWOW64\inetsrv\w3wp.exe
Faulting module path: d:\components\aspmail4\smtpsvg.dll
Report Id: 3dd63a38-51e6-11e4-80da-0cc47a302001
Faulting package full name: 
Faulting package-relative application ID:

Is there some undocumented setting I'm missing? I've gone to dozens of forums and followed everything to the letter, but nothing works (8 hrs now, hair is almost completely pulled out).

user692942
  • 16,398
  • 7
  • 76
  • 175
MC9000
  • 2,076
  • 7
  • 45
  • 80
  • 1
    The DLL is probably quite old and now your trying to run it on a 64 bit operating system. Most of the time registering a 32 Bit DLL using the 32 Bit sub system is enough to get these type of DLLs to work. In this case though it raises an `ACCESS VIOLATION` exception, which in basic terms means that the DLL is trying to access memory addresses it shouldn't be (which will happen as architectures and operating systems change from 32 to 64 bits and from version to version). It may be one or more dependencies the DLL requires don't exist or have changed, or it could be permission related. – user692942 Oct 12 '14 at 15:07
  • That's what I was worried about. I think I'll write a component in DotNet and expose it as a com object. I've got .Net code for sending mail already - just need to convert it. – MC9000 Oct 12 '14 at 17:08
  • You could use something like [Dependency Walker](http://www.dependencywalker.com/) (great little tool) to have a look at what dependencies the DLL uses and workout where the issue might be originating. To be honest though if your just looking to send e-mail with Classic ASP just use the CDONTS library that will be present on most Windows installations. There are plenty of [tag:cdonts] and [tag:cdo] examples on the SO site. – user692942 Oct 13 '14 at 08:25

2 Answers2

1

So I've actually come across this issue myself while migrating some old sites to Windows Server 2012 server and it appeared to be because of a dependency on cdonts.dll which was also known as Collaboration Data Objects for NTS (CDONTS) and was superseded sometime ago by Collaboration Data objects for Windows 2000 (CDOSYS).

See Where to acquire the CDO Libraries (all versions)

Unfortunately, the legacy code I was migrating including references to

Dim cdo: Set cdo = Server.CreateObject("CDONTS.NewMail")

which would cause the error

ActiveX component can't create object

Instead of writing the code, after a little research found it would be easier to just migrate the 32-bit DLL cdonts.dll from the old server to the new one and see if I can register it with the system, here are the steps.

  1. Located cdonts.dll in %SystemRoot%\System32 on the old server.

  2. Copied the DLL to the new server

    This would require some forethought. If the server was a running a 64-bit version of the OS the file would need to be copied into

    %SystemRoot%\SysWow64

    with the other 32-bit subsystem DLLs, otherwise, if it was a 32-bit OS it would need to be copied into

    %SystemRoot%\System32

    It's worth noting that the DLL can reside anyway as long as the correct regsvr32.exe is used, but for the sake of keeping things tidy followed this workflow.

  3. Use the correct subsystem version of regsvr32.exe to register the DLL. In this case, it was a 64-bit server so needed to register the DLL using regsvr32 in the 32-bit subsystem folder.

  4. Test the application. Found that the error had gone and the script worked as expecting using the legacy component.

    C:\>cd %systemroot%\syswow64
C:\Windows\SysWow64\>regsvr32 cdonts.dll

Link that helped me: How to Use CDONTS.DLL on Windows Server 2012 R2

user692942
  • 16,398
  • 7
  • 76
  • 175
0

Check Advanced Settings for Application Pool, option "Enable 32-Bit application"

Zam
  • 2,880
  • 1
  • 18
  • 33
  • 32 bit is enabled but the component has a dependency problem, unfortunately. It appears that any component that accesses network settings, security or the graphical subroutines (written a while back) will no longer work on Windows Server 2012 or 2012R2. Microsoft has mislead a lot of developers to believe IIS8+ will continue to support Classic ASP - which it does so long as you don't use any components. – MC9000 Oct 13 '14 at 06:41
  • The OP already stated that they tried both with and without 32 Bit enabled in the application pool settings - *"With 32bit enabled in the app pool, it just crashes the page"*. – user692942 Oct 13 '14 at 08:22