Since Windows Update kb4340556: VBA COM .NET Automation error on CreateObject()
Asked Answered
O

6

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?

Obla answered 11/7, 2018 at 9:19 Comment(5)
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.Obla
I had a number of Windows Update errors while installing that update... Gonna reboot momentarily. (I'm also Win7)Lunatic
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.Maternity
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 KB4338420Perseus
Related to #51289785Chandrachandragupta
G
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

Godchild answered 12/7, 2018 at 11:31 Comment(3)
Thanks. Woke up this morning to the problem. This 'fixed' it for meInvasive
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 muchSoberminded
Ok it works on anonymous authentication, but I can't do this on windows authentication.Paramecium
O
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.

Obla answered 11/7, 2018 at 15:13 Comment(6)
learn.microsoft.com/en-us/dotnet/framework/app-domains/…Tomato
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?Maternity
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.Jonathanjonathon
It is important for [ComVisible] assemblies, they belong in the GAC on the user's machine to solve DLL Hell.Tomato
Understood. Installing an unsigned version of the library still gives the same error. I'm truly puzzled.Maternity
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.Obla
L
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.

Luby answered 12/7, 2018 at 9:7 Comment(0)
H
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.

Homeroom answered 12/7, 2018 at 8:35 Comment(1)
What is the downvote for? Just bringing my experience, this way we fixed many PCs.Koby
P
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.

Pincus answered 12/7, 2018 at 10:42 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.