[RESOLVED] VISTA PROBLEM - msado15.dll failed to register. HRRESULT -2147024769

I have trashed the internet looking for a solution to this and I found nothing final. My associate that is remote to me can't seem to register msado15.dll on a vista machine when going through the installation. XP and others work fine.

unfortunately I don't have a Vista machine to test with...

In essence I need to know if there is a way to register a DLL on vista. The installer I am using is Advanced Installer 6.5.2.. I am packaging the application as MSI,,, nothing out of the ordinary.

Could this be related with running the OS as administrator?

I would greatly appreciate any help you can provide.

your installer must be run as administrator to register dll's ocx's on vista

:)) if that is all you just saved my life !! I will find out and get back. I am sure you are right though. Thank you

Quote:

---

Originally Posted by Deliriumxx

:)) if that is all you just saved my life !! I will find out and get back. I am sure you are right though. Thank you

---

couple other considerations:
Start menu and desktop shortcuts have to be in the proper folders to be seen by standard users. If you want you exe to be run by standard users provide a manifest with your exe to run as invoker:
<requestedExecutionLevel level="asInvoker"
if you want data files to edited by standard users put them in
CSIDL_COMMON_DOCUMENTS
if you put them in CSIDL_COMMON_APPDATA then they are read only for standard users
also admin and standard users write to different parts of the registary

I think everything you are suggesting I did..

I think I did.. :)

I will recheck... I did set the exe file of the app to run as invoker... Used a silly little method with ResHack for that.

The only thing I am still trying to figure out is how to create a RES file for the manifest for XP and vista styles and compile it with the exe.

You should not be trying to install msado15.dll (or any other ADO files) on XP or later - as ADO is fully installed already.

It can be valid on XP if you are installing a later version than is pre-installed, but it is best avoided.

With Vista the way ADO works is a little different (thus needing certain versions of the DLL's etc, which are all pre-installed), so having your installation fail is a good thing - as you won't be breaking what is there already.

ok,, it is a good thing from that perspective but a very bad think from my perspective. I have no time to be figuring Vista out..

Do you know how could I resolve the installation problem in that case? Some users will use vista some xp. How do I get my installer to install on vista and skip registering ADO components?

Should I register msvbvm60.dll and vbscript.dll with vista or not.

I have a total of 3 dll files that my app is using...

msvbvm60.dll
vbscript.dll
msado15.dll

and two ocx files

As I said before, both XP and Vista have ADO pre-installed - so you don't need it for either of them. Just remove it from your package.

Vista already has the latest version of the VB runtimes, so you don't need to install msvbvm60.dll for it (or the other parts of the runtimes, like OLEAUT.DLL).

I have no idea about vbscript.dll, as I've never used it... but I suspect it is an OS-specific file (and pre-installed), in which case it should probably never be installed anyway. You can find info about it by searching msdn.microsoft.com

yes,, :) I just found this
http://msdn.microsoft.com/en-us/vbrun/ms788708.aspx

it is some help.. and according to something else I found there is already a vbscript.dll on vista

Just searched my vista and found the following:
Installed ?
msvbvm60.dll - no
vbscript.dll - yes
msado15.dll - yes
Can you set your installer to not install if they exist, thats the way my installer
is setup

It looks like I have set my installer to Auto-Register components. I don't see an option to NOT register them but I assume that If I set it to NOT Auto Register it will register if they are non existent... I like this advanced installer but sometimes the options are not shown very clearly..

My installer has a couple handy options. The second creates a manifest to the installer, which you will neeed to register dll's ocx's on vista

which installer is this?

ARGH^&&#37;#$%&^$##$%&^#%$&#$@%^&

I found it lol
I have a never overwrite options in my installler

Quote:

---

Originally Posted by Deliriumxx

ARGH^&%#$%&^$##$%&^#%$&#$@%^&

I found it lol
I have a never overwrite options in my installler

---

Good, Just in case:
http://www.gdgsoft.com/pb/index.aspx
good luck

Thank you isnoend07,,,

I think I am getting the idea with Advanced Installer. It's just very large and feature full and I can't say that it is too intuitive,,, but it covers wealth of options...

According to Microsoft, setting components to self register is against MS guidelines.. I am trying to understand the installer process in general.

What happens to files if you supply them in the MSI package and they don't exist on the machine and they require registration?

According to MS again,,, registering them automatically is not supposed to be done.

Does installer register them?

I mean windows installer...

Quote:

---

Originally Posted by Deliriumxx

Thank you isnoend07,,,

I think I am getting the idea with Advanced Installer. It's just very large and feature full and I can't say that it is too intuitive,,, but it covers wealth of options...

According to Microsoft, setting components to self register is against MS guidelines.. I am trying to understand the installer process in general.

What happens to files if you supply them in the MSI package and they don't exist on the machine and they require registration?

According to MS again,,, registering them automatically is not supposed to be done.

Does installer register them?

---

I have never heard that.Your installer has to register them. How else would they get registered unless your app registers them thru vb code. I know that I bought a clean Vista machine to test my app on and my son downloaded WOW to Vista. Wow installed all their files under a public games folder eg: 5 exe's, dll's data files everything. This is against all Microsofts guidlines and they have 11 million users. So i just do what works and try to stay within the guidlines
1. My installer requires admin to run
2.My exe gets installed to program file(runas Invoker)
3.My data files are saved to common documents so admin and standard users can read and write.
4.My program updater prompts for admin within my app

I did exactly the same thing as you do...

Advanced Installer allows you to set the files to self-register... or auto-register ocx and dll... I have an options to set them to 'never overwrite'. I have to assume that in that case i have to set them to auto-register but to never overwrite and that should be a solution to all my users. Those machines that have the files installed and registered will have the registration skipped and those that lack the files will get them installed and registered.

I am now talking to Advanced Installer staff to clarify the hierarchy of installer actions to me...

This is all al problem because I don't have a Vista machine :s to test..

I need to do something about it.

The image per private message

As per private message 2

I just realised this thread is in the wrong forum - moved to Application Deployment forum

Installed your app again and it was added to add-remove program, just didn't see it before and it worked. Still getting the error: msado15.dll failed to register
something you might try: Read this somewhere else:

Quote:

---

I wrote a OLE-automation-server DLL in VB4.0. I use Installshield Express to install it as part of my program on the target computers.

Now on some computers I get the message "Failed to self-register XYZ.dll" (XYZ.dll being my ole-dll)! What is the reason for this message? I cannot find what to do about it!


One: Move the file you want to register to the bottom of the other files, making it the last one that registers. This is typically because the file you are trying to register is dependant on other file being there or already being registered.

Two: If that fails, then remove the "Allow xxxx to self register this file." from the checkbox in the "properties" section of the file.

One (or both) of these should work.

---

You might also try setting up an account as standard user on xp and testing your install. Xp has a lot of the same rules as vista, just not enforced like vista

When I fixed the ocx and dll paths (now they go to system32) I was able to reproduce the error on XP just as it is on Vista.

The last package I created is not producing the error. I have uploaded the last package if you wish to take a look at it.

I am now not sure if that means I resolved the issue or not. I also added the uninstall shortcut to app install folder.

Funny enough though. When installer produces the error about registration of the components the app still works. Possibly because masado15.dll is already in the OS and it is registered.

As you said somewhere earlier. The fact that registration fails is not a bad thing. It just means that Vista and XP are doing their job.

Anyways. I reproduce the issue on XP. Changed a few minor options for the installer and on my XP now the installer gores through silently.

One more thing I can't get to trigger is the installation of the chained MSI supplied with the package. I followed the instructions in the installer to a tiniest detail and it just doesn't get it to kick in.

Have you been able to see if the install of it was triggered?

Quote:

---

Originally Posted by Deliriumxx

When I fixed the ocx and dll paths (now they go to system32) I was able to reproduce the error on XP just as it is on Vista.

The last package I created is not producing the error. I have uploaded the last package if you wish to take a look at it.

I am now not sure if that means I resolved the issue or not. I also added the uninstall shortcut to app install folder.

Funny enough though. When installer produces the error about registration of the components the app still works. Possibly because masado15.dll is already in the OS and it is registered.

As you said somewhere earlier. The fact that registration fails is not a bad thing. It just means that Vista and XP are doing their job.

Anyways. I reproduce the issue on XP. Changed a few minor options for the installer and on my XP now the installer gores through silently.

---

Looks as if you are making progress. When i try to run the app after install it just displays a error message " Runtime error 3706 Provider cannot be found. It may not be properly installed" This may be due to the fact of not being a full app, just a test install app. If thats the case you may want to
send an app that at least displays a messagebox on start to determine if the app will run.
Also the start menu and desktop shortcuts can no longer be seen by standard users, just admin.
let me know

I have run into this problem. You need to register msado15.dll as admin for it to work. Here's a FAQ entry: http://www.issueview.com/FAQ.aspx#Vista

You want number 2.

I have come to that conclusion as well visiting,,, it is not a problem to instruct users to do the steps,, the problem is releasing a product to 800 people and have over 400 ove them complain about the issues with installation, :(

For the moment I am resorting to building separate installers... and getting users download according to the OS they are using.

I am finding that it is near impossible to create a really good unified install package :(

On the other hand Vista should apparently have msado15.dll registered and installer should not supply the file at all... (and I am not sure if I trust that instruction)

My vista has msado15.dll already installed. (Before i installed your test app) Looks as if you need to have your installer check if vista and not install it. Without having a vista machine to test it would be really tuff. Here's what i had to do to get my app working on vista.
Bought a powerfull used pc with xp.
Bought Vista ultimate (Not OEM or upgrade)
Made changes on xp copied to flash drive probably 20 times.
Reinstalled vista 2 times to be sure nothing left from prev install.
Found that cdosys.dll is different on vista and cannot be used to send emails.
Had to buy an ocx to send emails.
Thought i had everything working then discovered data files saved to COMMON_APPDATA could only be changed by admin, only read by standard users. Changed it to COMMON_DOCUMENTS and both could read and write.
Having a different setup for different OS would be a lot of work, making upgrades would require new setups for each

Quote:

---

Having a different setup for different OS would be a lot of work, making upgrades would require new setups for each

---

Now THAT is a very good point....

I cringe when I read about these things. I am getting a Vista machine asap. I just can't handle this without something to work with physically.

I mean my app is not SO overly demanding,,, I need regex support (vbscript.dll),, access 2007 support (msado15.dll) and mysql odbc 3.51 support, which I supply as chained installation module and it seems to be fine...

Oh,, I figured out that icon stuff,, it was a BUG in AI that I use to create the install package with. I reverted to older version and the issue is gone.. The older vrsion however does not deal with this Vista stuff as well as I hoped it would...

Then I upgraded to the newest version,, and I might bypass all this stuff. I contacted support to look at the test app and my requirements,,, they are forth coming for now..

Quote:

---

Originally Posted by Deliriumxx

On the other hand Vista should apparently have msado15.dll registered and installer should not supply the file at all... (and I am not sure if I trust that instruction)

---

Not just Vista, but XP too - and basic research will make that clear.

A quick search found the MDAC downloads/release notes, and the release notes for version 2.8 includes this:

Quote:

---

This release provides the same version of MDAC that was released with Microsoft Windows XP Service Pack 2 (SP2) and Microsoft SQL Server 2000 Service Pack 4 (SP4).
...
File list for MDAC 2.8 (2.81.1117.6)
...
Msado15.dll 2.81.1117.0 ADO

---

Quote:

---

Originally Posted by Deliriumxx

access 2007 support (msado15.dll)

---

That file does not support Access, it just supports ADO.

You need drivers/providers to enable ADO to work with particular database systems - for Access 2007 that is ACE (link in my signature).

Quote:

---

Originally Posted by isnoend07

Thought i had everything working then discovered data files saved to COMMON_APPDATA could only be changed by admin, only read by standard users. Changed it to COMMON_DOCUMENTS and both could read and write.

---

That was the wrong move, what you should have done is set the permissions for your folder in COMMON_APPDATA as part of your installation.

Quote:

---

Originally Posted by si_the_geek

Not just Vista, but XP too - and basic research will make that clear.

A quick search found the MDAC downloads/release notes, and the release notes for version 2.8 includes this:


That file does not support Access, it just supports ADO.

You need drivers/providers to enable ADO to work with particular database systems - for Access 2007 that is ACE (link in my signature).

That was the wrong move, what you should have done is set the permissions for your folder in COMMON_APPDATA as part of your installation.

---

Quote:

---

That was the wrong move, what you should have done is set the permissions for your folder in COMMON_APPDATA as part of your installation.

---

Tried that and the COMMON_APPDATA is read only for standard users. My app works fine in COMMON_DOCUMENTS for both admin and standard users

The default permissions are read only - which is why you should set them to something else as part of the installation.

si_the_geek,

so the msado15.dll permissions are Read Only by default? And the installer running as admin should be able to bypass that, temporarily change the permissions of the file, register it and then set back to Read Only?

You should not be installing the file msado15.dll at all, and for XP or later (which includes Vista) you shouldn't even be installing MDAC (which is what that DLL is part of).


My previous post was in response to isnoend07's comment about the COMMON_APPDATA folder.

yeh,, I know,,, I figured that out a little while ago and removed msado15.dll from the installer....