10

Since the update Windows7 Update KB 4340556 of the Jul 10, 2018 we get the following error message:

"Automation Error" : The system cannot find the file specified" from the Access VBA CreateObject() call.

 Set ComClass = CreateObject("MyApplication1.InteropStart")

Microsoft identifies this as a security issue.

If we uninstall the update KB4340556, the call will work as before.

Does anyone have the same problem? Or a better solution than the update to uninstall?

Erik A
  • 28,352
  • 10
  • 37
  • 55
Volker Fried
  • 303
  • 2
  • 9
  • We have the problem with many customers. Currently over 40 machines. Currently only on Windows 7 SP1 64-bit systems. Windows 7 32-bit systems are not affected. – Volker Fried Jul 11 '18 at 09:50
  • I had a number of Windows Update errors while installing that update... Gonna reboot momentarily. (I'm also Win7) – ashleedawg Jul 11 '18 at 10:00
  • We are experiencing the same issue on Windows Server 2012 R2. The relevant Windows update for 2012 R2 is KB4340558 when you're looking at the update history and KB4338424 when you're looking at installed updates. When we uninstall the update, the error disappears. Despite my best efforts, I was unable to find an alternate solution to uninstalling. We would also prefer a better solution. – user2458080 Jul 11 '18 at 14:58
  • I am seen this on Windows 10 x64, "429: ActiveX component can't create object", uninstalling KB4338819 solves the problem. On Windows 7 x64 we are having problems with KB4338420 – Nickolai Nielsen Jul 12 '18 at 12:13
  • 1
    Related to https://stackoverflow.com/questions/51289285/how-do-i-properly-instantiate-32-bit-com-objects-in-classic-asp-after-installing – Lex Li Jul 12 '18 at 16:12

6 Answers6

6

We were affected with multiple customers too.

I ruled out invalid strong-name signing of our assemblies, since the .NET Assemblies from the Framework itself were affected by that access-denied error too.

Finally I managed to solve the issue by configuration. Apparently the authenticating identity of the website has now to match the identity of the app-pool. Or IUSR has no longer enough permissions. enter image description here

keydon
  • 709
  • 6
  • 8
  • Thanks. Woke up this morning to the problem. This 'fixed' it for me – Matt Jul 12 '18 at 13:51
  • This is the answer that solved it. I had the same problem since the windows security update last week (had a "permission denied" on object creation however). I was a bit desperate to have to rewrite all the code using .net dll with com. Thank you so much – Jonathan Jul 16 '18 at 13:02
  • Ok it works on anonymous authentication, but I can't do this on windows authentication. – piotrbrzuska Jul 17 '18 at 12:18
5

Our Interop .Net Assembly had a signature with a strong name. The signing is apparently no longer accepted. Creating a new signature (* .snk file) in Visual Studio causes the CreateObject ComInterop call to work again.

EDIT 26.07.2018

We enabled User Account Control (UAC) on the machines from our customers like Pao'lino described.

Creating a new signature also create a new public key token for the assembly. This causes reference problems.

Volker Fried
  • 303
  • 2
  • 9
  • https://docs.microsoft.com/en-us/dotnet/framework/app-domains/enhanced-strong-naming – Hans Passant Jul 11 '18 at 15:44
  • Which version of Visual Studio? Are you using a key generated by VS (e.g. untrusted root)? Can you tell if the certificate is SHA1 or SHA256? – user2458080 Jul 11 '18 at 19:06
  • As an alternative, don't strong-name your assembly. As noted in the link that @HansPassant referred to, it's not meant to be used as a security mechanism. When we consider that only one version of the library can be loaded at a time in context of COM, the only good use case for strong names goes out of the window. – this Jul 11 '18 at 19:46
  • It is important for [ComVisible] assemblies, they belong in the GAC on the user's machine to solve DLL Hell. – Hans Passant Jul 11 '18 at 21:04
  • Understood. Installing an unsigned version of the library still gives the same error. I'm truly puzzled. – user2458080 Jul 11 '18 at 21:11
  • The signature was first created with Visual Studio 2010. Project is today a Visual Studio 2017 project and the new working signature was created with Visual Studio 2017. – Volker Fried Jul 26 '18 at 12:20
3

We are experiencing problems as well. We found that it was actually one of the embedded updates inside of KB4340556 - KB4338420 that was causing our the problem.

We have an APP that uses COM object as a hook between itself and MS Office. Installing this update removed the COM object causing the required mscoree.dll not to load. Only seeing the problem on 64bit Win7 with 64Bit Office products installed.

I have posted to the developer community at visualstudio.com (https://developercommunity.visualstudio.com/content/problem/291884/july-2018-cumlative-security-and-quality-update-kb.html) in their .NET forum. The problem is under Triage at the moment. Removing KB4338420 fixes the problem temporarily, but then the next time your system checks for updates, it thinks KB4340556 is not installed and wants to re-install it. Only work around for now is to hide the update, since it is only KB4338420 that is missing.

2

Enabling UAC and setting it to default level fixed the issue for us.

Our scenario is .NET assemblies exposed to COM and a VB6 application instancing this .NET objects with CreateObject.

Update.. The UAC trick doesn't work on Windows Server 2012 R2.

Pao'lino
  • 49
  • 3
1

To corroborate what other users here have said. We are also having problems following KB4340556. The following code

Set myObject = CreateObject("System.Collections.ArrayList")

causes a 'Permission Denied' error when creating a .NET component within classic ASP running on IIS and Server 2008r2 64bit.

The same code run in a .vbs file (in 32 bit) works fine.

Specifying a different version of .NET in the application pool has no effect.

TB DTC
  • 41
  • 3