We've recently encountered a problem in a Classic ASP application which relies upon a set of C# COM components, and have identified that the changes introduced in KB4338419 have broken something for us!
We have reduced the problem down to the essentials:
Created the simplest possible C# COM library:
using System;
using System.Runtime.InteropServices;
namespace TestComObject
{
[ComVisible(true)]
[Guid("B5C7370F-0EB5-4279-885C-9C169F9CBAA5")]
[ClassInterface(ClassInterfaceType.None)]
public class Class1
{
public string GetString()
{
return Guid.NewGuid().ToString("D");
}
}
}
Registered it on the server using RegAsm /codebase
Created the simplest possible ASP script to consume it:
<%
Const COM_OBJECT_NAME = "TestComObject.Class1"
Dim co
Set co = Server.CreateObject(COM_OBJECT_NAME)
Response.Write co.GetString()
%>
When accessing the page, we see:
Microsoft VBScript runtime error '800a01ad'
ActiveX component can't create object
/Default.asp, line 4
The web application runs in IIS (8), under a dedicated, non-priveleged user account. The (real) code has been running just fine for years, with limited privileges. If I add the user to the Administrators group, the COM object is instantiated. As a normal user, the page/code fails. If I change the progID to a non-.Net library everything works fine
File system permissions are fine. If I write a .vbs equivalent and execute as the non-privileged user, everything works fine.
The article for KB4338419 implies that some security change was made to how .Net COM objects are instantiated or accessed, and understandably doesn't go into much detail, and I can believe we're doing something wrong or not doing something now considered essential, but I can't find any information that suggests what we should be doing!
Your help would be appreciated! Tim
