Error=429 : ActiveX component can't create object

[RobGG]

Hi,

I have a problem in Vista Home Premium with two commercial programs, one in VB and the other in a script environment. Both give the above message.

I have spent hour investigating and have got to the following point.

I can correct the error temporarily by running "regsvr32 scrrun.dll" from the CMD prompt (Run as Administrator). The error is eliminated in both programs but returns when the computer is re-booted.

If I re-start the machine in Safe Mode the error remains corrected.

I have tried preventing all start-up programs from loading at re-boot but this did not eliminate the problem.

I suspect that data is loaded to the registry at boot time and this contains the corruption, however I do not know how to proceed further.

Any assistance would be appreciated !

Robert

[Steve]

Hi RobGG,

more than likely a registry permissions problem.

First of all download Regmon from Microsoft here... RegMon for Windows v7.04

In the Filter dialog, uncheck "Log Successes"

Clear the entries and run "regsvr32 scrrun.dll" again.

This will allow you to see all the keys that regsvr32.exe accesses to perform this command. Look for ACCESS DENIED and if found, change the permissions on that key.

Hope this helps.

regards

Steve

[RobGG]

Thanks Steve,

I downloaded Regmon and got a message that it had been replaced in Vista by SysInternals Process Monitor.

I used Process Monitor (with trepidation) and found many entries for the "regsvr32" entry. Captions included: Success, No more entries, Name not found, Fast IO disallowed and Reparse. There were two "Access Denied" entries for "Set Basic Information File" into "c:\Windows" and "c:\Windows\System32".

From this result I would surmise that I need to make these system folders able to be written to by regsvr32. Is this as simple as removing the "read only" attribute in Folder Properties ?

Robert

[RobGG]

Hi,

Can anyone help?

Robert

>
> Can anyone help?
>

I wonder if it might be some half-wit, overzealous
anti-virus-type program. Some people, including
some network admins, consider scrrun.dll and the
Windows Script Host to be unnecessary security risks.
Maybe you're dealing with something that's deliberately
disabling it?

You might also try asking in:
microsoft.public.scripting.vbscript

There should be at least someone there who's
using VBS on Vista.

There do seem to be COM problems on Vista, too.
I still haven't figured out exactly what they are, whether
permission issues, just plain bugs, or what. But there
have been discussions in VB groups where people talk
about strange things like COM registrations that only
work on Vista if they *unregister* the component after
registering. I can't even imagine under what scenario
that would make sense, but I've seen it posted a number
of times.

mayayana wrote:
>> Can anyone help?
>>
>
> I wonder if it might be some half-wit, overzealous
> anti-virus-type program. Some people, including
> some network admins, consider scrrun.dll and the
> Windows Script Host to be unnecessary security risks.
> Maybe you're dealing with something that's deliberately
> disabling it?
>
> You might also try asking in:
> microsoft.public.scripting.vbscript
>
> There should be at least someone there who's
> using VBS on Vista.
>
> There do seem to be COM problems on Vista, too.
> I still haven't figured out exactly what they are, whether
> permission issues, just plain bugs, or what. But there
> have been discussions in VB groups where people talk
> about strange things like COM registrations that only
> work on Vista if they *unregister* the component after
> registering. I can't even imagine under what scenario
> that would make sense, but I've seen it posted a number
> of times.
>
>
>


A duplicate registry entry where the wrong one is found first? Could be
permissions actually, maybe something can't be overwritten by the
installer but can be created new at runtime?

[RobGG]

Thanks Mayayana and Charlie Tame,

I am using AVG and Defender as anti-virus etc. so this is unlikely to be the issue.

I also have Vista on a laptop running both the programs in question without any problems (the laptop is also running AVG and Defender).

I think it more likely that some other program install has either corrupted the registry or has over-written a Vista system file. The use of "regsvr32 scrrun.dll" fixes the problem for this logon - but the problem re-appears on the next logon.

Vista seems to be very clumsy in the new "UAC/Authorisation" process - is this likely to be a Vista "bug" to be corrected in SP1?

I tried to do a Vista "upgrade in place" but got a message after the full process that there was an incompatibilty and upgrade was not available.

I have considered doing a file for file compare of C:\Windows between my laptop and desktop to see if any current files have been overwritten by earlier versions - do you think this could be fruitful?

Charlie Tame's suggestion "A duplicate registry entry where the wrong one is found first? Could be permissions actually, maybe something can't be overwritten by the installer but can be created new at runtime?"

I do not know enough about the registry to explore it effectively. Do you know of any gidelines that would assist me?

Regards,

Robert

> I do not know enough about the registry to explore it effectively. Do
> you know of any gidelines that would assist me?
>

I can tell you that but I'm not familiar with the inner
workings of Vista. I know that UAC will cause Registry
writes to dummy HKCU keys in some cases without
telling you that it's not allowing you to write the real value.
There are also complications if you've got 64-bit, but
again, I don't know the details.

When you create an object it goes through
HKCR (CLASSES_ROOT). For instance, if you're getting
the error with the FileSystemObject:

When you create a FileSystemObject instance it gets
created by looking up the ProgID in HKCR. In the case
of script you have something like:

Set FSO = CreateObject("Scripting.FileSystemObject")

Scripting.FileSystemObject is the ProgID of the object.
An object can be found in HKCR by either its ProgID or
CLSID. So to trace the path of how COM is trying to
load the object, you start by looking at the ProgID key:

HKCR\Scripting.FileSystemObject

The CLSID subkey there has a default value that points
to a key under HKCR\CLSID. That seems to be
{0D43FE01-F093-11CF-8940-00A0C9054228}

So you then look under
HKCR\CLSID\{0D43FE01-F093-11CF-8940-00A0C9054228}

The subkey there named InProcServer32 has a default
value that should be a string representing the full path to
scrrun.dll. In some cases that will be a LocalServer32 subkey,
but either way, that's the basic COM setup for figuring out
which library to load given a ProgID.

It might also help to run Regmon to see what is *actually*
being accessed in the Registry when your program is run, but
I don't know whether Microsoft has blocked Regmon from
running on Vista. They bought out sysinternals.com and
are now saying that Regmon has been "replaced" on Vista
by Process Explorer. But procexp.exe is actually an entirely
different thing. (Search for Regmon at Google if you don't
know what I'm talking about.)

[RobGG]

Thanks Mayayana for the thoughful reply,

I'll investigate further ans do a little study around Regmon ( I was earlier put off by a MS message directing me to SysInternals). I'll post my results in due course.

Regards,

Robert

"RobGG" <RobGG.2zif5u@no-mx.forums.vistaheads.com> wrote in message
news:RobGG.2zif5u@no-mx.forums.vistaheads.com...
>
> Thanks Mayayana for the thoughful reply,
>
> I'll investigate further ans do a little study around Regmon ( I was
> earlier put off by a MS message directing me to SysInternals). I'll
> post my results in due course.
>

The problems you're having are program problems and the software vendor. If
the applications work one Vista machine and don't on another Vista machine
as you are indicating, then I would be on the phone with the software vendor
to get a clarification and help. It seems that all you're doing here is
spinning your wheels, because you're not going to the right place, the
software vendor. For all you know, the problem may have been already
reported with a solution given by the vendor.