[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 15611
  • Last Modified:

Runtime Error '429' : ActiveX Component Can't Create Object

I have a large Visual Basic 6 application which has been running for about 6 years on Windows XP, SP3.  I've made a few changes to it to accomodate using it on Windows 7, and have built an install setup.exe using the Package and Deployment wizard.  The install was used to install it on more than one Windows 7 test computer, where it ran without problems.  The install was also used by the client to build a Radius package for their network installation.  It turns out that as time passed the Windows 7 enviroment changed, or in some way the Radius package was flawed, and installations made with it, although no errors were observed, have caused the application complain of the error in the title above, and when the only button (OK) or the X on a red field is clicked the application terminates.  So far as I can tell all the necessary files are in the setup's .CAB file and were installed and registered.

I added several (dozens) of logging messages to the application in an attempt to isolate the problem.  This has not yet been productive.  The database is on a SQL server and the same data was used for the test systems and the systems now having problems.

What I would like is access to a way to obtain a log of .dll and .ocx calls made by the application as it starts up, with an indication of any problems encountered.  I've heard that Winternals Process Explorer (of which I have the most recent version) might do this, but I'm not sure how to obtain this, and have not found any concise explanation.  Buying a book on Amazon is a possible recourse, but I had hoped to find something more to the point on line.

Can anyone help?
0
VB6chuck
Asked:
VB6chuck
  • 49
  • 33
  • 17
  • +1
1 Solution
 
CSI-Windows_comCommented:
Process Explorer will show you what DLLs ARE loaded and their full paths, but it does not reveal the process that was gone through to load them.  It is here: http://live.sysinternas.com/procexp.exe.

What you probably want is process monitor because it will show "Load Module"  events and you can fully trace COM calls to see if something is messed up in the registry.  It is here: http://live.sysinternals.com/procmon.exe

Rohitab API Monitor would be the next level of seriousness in analyzing the problem and it is here:  http://www.rohitab.com/apimonitor

Any chance that this change to the environment was the introduction of 64-bit Windows on some machines?
0
 
SStoryCommented:
It will show you all of the file accesses. If it were me, I'd try to see what ActiveX control it blows up on?  Does the app require MDAC? Is the proper MDAC installed (MS Data Access Controls).  Are there any 3rd party OCX controls?  If so, they may have .DLL files that are incompatible with Win 7.  Were the other machines 32 bit and this one 64 bit?

Is running the app under Windows Virtual PC in Win 7 pro an option?

Eventually the answer it to rewrite the app because VB6's days are numbered.
0
 
VB6chuckAuthor Commented:
I shall give procmon and apimonitor (if necessary) a try, thanks.  Any hints on procmon instructions?

No 64 bit machines involved, thankfully.

Virtuals (and physical machines) have been used in testing but client's system is a network of physical machines, all running Windows 7 pro.  These are gradually replacing a network of XPs.

Client can't wait until eventually and the app is fairly large.
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
CSI-Windows_comCommented:
Procmon hints:
Procmon only does DISPLAY filters - although you can turn one on during data capture it is not limiting the data being captured
Procmon UI is much more responsive if you set a filter that does not display anything (e.g. "Architecture is laa-dee-daa")
Quickly update filter by right clicking the CELL (yes, column + row) and clicking "include or exclude"
Reverse these changes by editing the filter.
Filter excludes first.
Filters on the SAME column are ORed together.
Filters on DIFFERENT columns are ANDed together.
Creatively use "Include/Exclude" to get around not having explicit control of AND / OR
Becarful of broad "Exclude" filters.
0
 
SStoryCommented:
http://answers.microsoft.com/en-us/windows/forum/windows_xp-windows_programs/runtime-error-429-activex-component-cant-create/481475c9-4ed6-4211-be6b-2431b962b257

Here's something on the MDAC and Win 7 with SQL Server:
http://answers.microsoft.com/en-us/windows/forum/windows_7-windows_programs/mdac-and-windows-7/ea7f24cf-d829-4ff5-bf75-f952cca73f77

Until we know which ActiveX is blowing up it will be hard to solve.  I'd try to register all of the DLLs needed.

regsvr32.exe [dllname]

I'd also make sure a compatible MDAC is installed to work with SQL Server.  

Many 3rd party like Farpoint's grid control had it's on DLLs and any of them could be causing problems or be incompatible with Win 7.
0
 
VB6chuckAuthor Commented:
I have a nice Process Monitor capture of activity of the Application.exe from startup until the 429 error and then after I click OK on the error the program shuts down.  All captured.  I've exported both the full thing and after I'd excluded everything except the Application.exe items.  I can also capture the same activity (more or less) for the test version which doesn't have the 429 error and try and compare these two, although there are thousands of lines on each.  Is there not some way to find when the error occurs on the first full capture?  Otherwise I may go blind doing the comparison.
0
 
SStoryCommented:
The best thing for comparisons is Beyond Compare:
http://www.scootersoftware.com/

It can compare anything and show you the differences. It is super cool. There is a freebie called WinMerge that is similar but not quite as good.

Could it be an ActiveX licensing issue?
Can you list the controls used in your project--especially the 3rd party ones?
0
 
CSI-Windows_comCommented:
Right click "success" (any row) in the column "result" and select "Exclude Success".
0
 
ArkCommented:
Why not install VB6 and run your app in IDE on problem machine??
0
 
VB6chuckAuthor Commented:
Cannot install VB6 on client's machine due to administrative restrictions.

Need administrator to remote in and allow access when required.

Have been going blind looking at ProcMon Operations and cannot find the problem.  Am comparing a run without the error on a virtual Windows 7 machine where the App was tested.
0
 
CSI-Windows_comCommented:
You can zip and upload the procmon logs and I can look at them for you (assuming no proprietary data in them).
0
 
VB6chuckAuthor Commented:
Than is an amazing offer . . .

There may be some sensitive data included.  Is there another channel that I might send them to you?  With the understanding that you'll destroy them when when you're done?
0
 
CSI-Windows_comCommented:
Yes there are other channels and I would destroy them afterward -  however, it presents a challenge when not all experts can participate.  

SStory and VB6Chuck - are you two OK with me taking the procmon logs offline?
0
 
VB6chuckAuthor Commented:
Ark is the other expert.  VB6Chuck is me, the one with the problem.  I'm ok with the logs offline, I suggested it.  In this case does silence imply consent?
0
 
SStoryCommented:
I'm fine.  If you can get a result. EE may not be.

Have you considered that it might be a permissions problem also?  What if you grant all access rights to the app folder c:\program files\whatever to everyone
and if there are any registry keys do the same?

If that fixes it, it is permissions related.

In procmon thing look for Access Denied. If you see that, it could help you find the problem.  It is hard to pinpoint from here.
0
 
VB6chuckAuthor Commented:
In ProcMon all Load Image attempts were successful.  Didn't specifically look for Access Denied, however first thing I checked was to attempt running the App with the remotely logged in administrator's rights, which included local admin on that machine.  That should have covered any rights problems, I would expect.

I am away from my desk this morning, but will return around noon, eastern time.
0
 
CSI-Windows_comCommented:
VB6Chuck,
Did you run procmon on BOTH the install and the attempt to run the software?
0
 
CSI-Windows_comCommented:
I will request moderator attention for the sharing of the logs.

If we can go ahead, I would post all results back here.

VB6Chuck - I would also ask your permission to post non-proprietary records of the procmon log as required to explain the problem and/or solution.

Could you please confirm via a post that this would be OK?
0
 
VB6chuckAuthor Commented:
Procmon logs exist only for the running of the App on a virtual Windows7 machine where it worked, and the attempted running of the App on another Windows7 laptop where it had been installed by a Radius system where it failed with the error under discussion.  

I could run a third log of a subsequent install on the virtual Windows7 machine, however none exists of the original install on that machine.  I might have a copy of the virtual before any installs were done, but I would have to check that.

The Setup.exe which was used to make the Radius package was the same as the one used to install on the virtual test machine, and also on more than one client machine where it ran without problems.  It is possible that the Radius package is in some way flawed.

This is to confirm that it is acceptable to me that portions of the procmon logs be posted so long as all names, including computer names and ODBC DSN's, URL's, IP addresses and any other indications of identity be replaced with generic identifications, and specific indications of proprietary program functioning by obscured in some way, if any exist in the portions which are posted.  

I'm not expecting any proprietary stuff, although there are lots of user (client) identifiable things which I would be very unhappy to have posted.

If the requested obfuscation is a problem I would be willing to perform it on the portions of the logs you would like posted as examples.  Performing it on the entire logs would take too long.  I would be expecting all copies of the full logs to be destroyed once you had finished the analysis.

Thank you
0
 
SStoryCommented:
I continue to wonder if you have the appropriate MDAC and ODBC drivers installed on that machine.  My gut says MDAC or third party DLL that isn't compatible with Win 7 or isn't installed or if it is installed isn't properly registered.
0
 
CSI-Windows_comCommented:
The error means that the ActiveX control could not be instantiated.  This would generally be due to:
It isn't registered.
It is registered as one bitness, but the calling process is of a different bitness.
The DLL registration data is inaccessible (registry permissions)
The DLL registration points to the wrong file location
The DLL is registered in BOTH HKCU\Software\Classes and HKLM\Software\Classes and the combination of these two registrations in HKCR makes up a combined DLL registration that is not consistent

But there should be some evidence of this in the procmon log of the failure case.

Try the following filter(s):

Path contains "Software\Classes" (without quotes)
Path contains "HKCR" (without quotes)

There will be lots of "not found" records because CoCreateInstance calls do a lot of probing to figure out if the DLL is registered to the whole machine or to the user. (bouncing back and forth between HKCR and HKCU)

Then locate the last one attempted and see if there is something funky about the registry look ups or an attempt to find the associated DLL / OCX.
0
 
VB6chuckAuthor Commented:
Setup.LST contains an MDAC_TYP.EXE dated 6/25/98 which is unlikely to be appropriate for Windows7, but should not have been installed if a more recent one existed.
0
 
VB6chuckAuthor Commented:
There are no Software/Classes or Software\Classes records and 612 HKCR ones
0
 
SStoryCommented:
I know what the error means. But there are lots of reasons why it couldn't be instantiated. DLLs and MDAC might cause that problem and still give a vague error.  If it is an inhouse control, it might help to know what it does during its Init.
0
 
VB6chuckAuthor Commented:
Very shortly after the last WriteFile to a text log indicating normal operation:

Six attempts at RegOpenKey
Path: HKCR\CLSID\{00000514-0000-0010-8000-00AA006D2EA4}
Result: NAME NOT FOUND
Detail: Desired Access: Maximum Allowed

All Registry operations having HKCR in the path after that result in SUCCESS.
0
 
VB6chuckAuthor Commented:
Above probably not useful in that those 6 attempts follow 52 earlier ones in the program execution which, although they all returned NAME NOT FOUND do not seem to have affected the execution.
0
 
VB6chuckAuthor Commented:
Previous to that there are some BUFFER OVERFLOW and NAME NOT FOUND on attempts to open HKCR\Licenses, but there are identical entries on the successful execution log.
0
 
VB6chuckAuthor Commented:
In checking ODBC information I've discovered that the successful program made 3 sets of inquiries of ODBC Driver through Auto Translate keys, whereas the failed program made only 1 set.
0
 
VB6chuckAuthor Commented:
MDAC version on virtual test Windows7 where App works is 6.1.7601.17514

Checking your suggestions of 12:43:53

Disabling UAC not possible off site (today).
0
 
CSI-Windows_comCommented:
What about asking the client to recreate the package?

Although you can't afford to refuse to  support repackaged software, it is reasonable to request that the repackaging work be redone.

Does your setup.exe work on the exact machines where the Radia package fails?
0
 
VB6chuckAuthor Commented:
I've retracted answers to both question and observation above due to my response below.

Interesting point.  The setup.exe was run on the same machine where the Radia package fails as the next thing after trying admin credentials.  The result was the same error as the Radia package produced.  

This setup.exe has produced working Windows7 machines for my virtual test, as well as at least 3 tests on the client's network.  

Also not a factor would seem to be the SQL server the App connects to, which was another virtual for my virtual test, and the same server on the client's network for the recent failure and 3 or more successful tests a few months ago.

So it isn't Radia, or setup.exe would have worked, unless the Radia install in some way has "poisoned" the machine.  The client isn't complaining about any other features of the machine, such as Outlook.  And it isn't the SQL server.  My guess is that the Windows7 machine on which the problem is occuring has some difference not shared with both vendor and client tests - all of which were successful.
0
 
VB6chuckAuthor Commented:
One last thought before I run errands for an hour or so.

The setup.exe was created on an XP SP3 virtual.  It tested well on so many Windows7 installs that it never seemed like an issue before, but perhaps it might be . . . ?
0
 
CSI-Windows_comCommented:
On your original trace - for each GUID there should be at least one time it WAS found.  I would check the last GUID you mentioned with this filter:

Path contains "{00000514-0000-0010-8000-00AA006D2EA4}" (no quotes).

You should find it successfully locating and reading a key "...\{00000514-0000-0010-8000-00AA006D2EA4}\Inproc32Server\(Default) and finding a DLL name.  If you do not find at least one success for this, then the COM registration for the CLSID {00000514-0000-0010-8000-00AA006D2EA4} is not present.

That CLSID should point to: %CommonProgramFiles%\System\ado\msado15.dll - part of ADO.

If it IS successful, check that the key is pointing to the correct file location and that the file exists and check the registry permissions on the key.

If that one is OK, it may be one of the others.

Also if you use Rohitab API monitor, it should be able to identify exactly what CLSID is actually failing - but try procmon first because you are familiar with slogging through records with it.
0
 
VB6chuckAuthor Commented:
You are onto something there . . . That GUID was found on the "ran successfully" log, but not on the "failed" one.  msado15.dll is NOT in the setup.exe's SETUP.LST, but a version from May 2012 is on the XP SP3 system where the setup.exe was built.  Also one from June 2012 appears on the test Windows7 system.  It's either missing, corrupt, or unregistered on the problem machine.  I wonder why?  And also what other parts of ado might be missing?  And how to install everything missing on the problem machine . . .  A list of what to supply is something I could give the Radius packagers, perhaps . . . especially since they have to roll out the App for many users.

Thank you! Thank you! Thank you!
0
 
VB6chuckAuthor Commented:
I will be back by 6PM eastern time.
0
 
CSI-Windows_comCommented:
Perhaps *MOST* of the Windows 7 machines have another software package installed that has pre-installed this runtime - but some don't.

OR a Radia package that has a broken uninstall (breaks these components) was uninstalled on the machine you are trying to install on now.
0
 
VB6chuckAuthor Commented:
Does Microsoft have an ADO runtime package suitable for Windows7 32-bit?  I don't want to give the Radius packagers an entire application in order for them to have what is needed.  In looking at my test system I find 25 files in C:\Program Files\Common Files\System\ado with modification dates from 1998 to 6 June, 2012.  These later must be from an update, yes?  Presumably if the 1998 package is installed then Windows Update will handle the later ones.  But where is the package, or better yet an up to date package?

If there is no package how would you suggest I proceed with installing and registering the necessary ado files?  The client will obviously require a Radius solution in the long run.
0
 
CSI-Windows_comCommented:
Looks like MDAC 2.8 might be the last: http://www.microsoft.com/en-us/download/search.aspx?q=mdac

You might also want to check if SQL Server Compact Edition contains newer versions of ADO: http://www.microsoft.com/en-us/download/search.aspx?q=sql+server+compact
0
 
VB6chuckAuthor Commented:
MDAC 2.8 is indicated for Windows 2000 and earlier.

SQL Server Compact Edition 4.0 SP1 includes ADO.NET, which does not seem appropriate for VB6.
0
 
VB6chuckAuthor Commented:
In my XP SP3 development system I appear to have msado20, 21, 25, 26, 27, 28, and 60 .tlb in C:\Program Files\Common Files\System\ado  

Many of them are last modified this year.  The logs indicate one or more of them are used by the successful running of the App.

Should these be distributed and registered using REGTLIB.EXE which I have in C:\WINDOWS\system32\URTTemp?

My last attempt at installing an inappropriate MDAC resulted in a client machine which booted to a blue screen and there was a few awkward moments until I booted it with linux and repaired the problem.  I'm not too keen on repeating the experience.
0
 
VB6chuckAuthor Commented:
My proposed approach for tomorrow on the client site is to install the any of the 25 files in the ado folder that may be missing and with admin rights to register the .dll and .tlb files using REGSRV32.EXE and REGTLB.EXE, following which I will run the App and if anything is out of the ordinary I will re-run it capturing a procmon log.

If successful I will supply the files which needed to be installed to the Radius packager and indicate what will be needed to register them.

For future use I'll fix Setup.exe by adding the additional files to the .CAB file and ammending the Setup.LST file by adding the new files, and use $(TLBRegister) instead of $(DLLSelfRegister) for the .TLB files.  On systems where the necessary files already exist this will have no effect.

Does this seem to cover it?
0
 
VB6chuckAuthor Commented:
Ark - that's very illuminating.  Also a  bit scary.  I'm only concerned with 32-bit Windows7, but will see try to understand what's going on from the URL you've provided and see where I can go from there.

Not sure how that affects my plans for tomorrow, but we'll see how tomorrow goes and then get back to the other possible solutions (Windows 8?).

Thanks
0
 
ArkCommented:
Unfortunately, breaking the rules is MS policy. Try to narrow which object cause the problem.
Create a simple project with just a declarations and object initialization, smth like
dim rst AS ADODB.recordset
set rst=New ADODB.Recordset
msgbox "Early-OK"

dim rst2 AS Object
set rst2=CreateObject("ADODB.Recordset")
'(When using late binding try also uncheck ADODB reference in Project->References as well)
msgbox "Late-OK"

dim rst3 AS Object
set rst3=Conn.Execute(strSQL)
msgbox "Conn-OK"
0
 
VB6chuckAuthor Commented:
I have a test Win7 virtual (32-bit) with SP1 and KB2698365 both applied as of 4 Sep 12.  App works fine there.  Client has laptop 32-bit Win7 with ??? applied.  msado15.dll appears either missing or not registered according to logs.  It's onsite so I'll not know for sure until tomorrow.  Not sure if rolling back KB2698365 would help or not.  

Tempted to try installing and registering same ado files as on test virtual which works.  Not sure what coming patches will do to that . . .
0
 
CSI-Windows_comCommented:
OK, here is a bunch of MDAC updates to Windows 7 hidden as "Security Updates" - maybe they will fix things up: http://technet.microsoft.com/en-us/security/bulletin/ms12-045

Also, since you know this is an MDAC issue, you could use RegDLLView to compare a working and non-working machine's CLSID to file mappings for "C:\Program Files\Common Files\System\ado": http://www.nirsoft.net/utils/registered_dll_view.html
0
 
VB6chuckAuthor Commented:
This is becoming a nightmare.  The first URL above refers to a KB which breaks SP1 ADO, except on my test virtual, which still runs.

The second looks like it might be useful.  I'll have a look at it tomorrow if things are going badly.

Thanks.
0
 
SStoryCommented:
HKCR,CLSID\{00000514-0000-0010-8000-00AA006D2EA4}\ProgID,,0x00000000,"ADODB.Connection.2.8"

Sounds a lot like MDAC to me.
0
 
SStoryCommented:
My opinion is that support for VB6 type apps will get worse with each release of Windows. They want to kill it.
0
 
VB6chuckAuthor Commented:
There are two reasons I don't want to touch MDAC.  First is that I've had problems with it before and created and then fixed a machine that booted to a blue screen.  It was not an enjoyable process.  Second is that today's solution can easily be broken by tomorrow's critical patch.

Here's what I'm thinking of doing now:

An analysis with RegDLLView of the ado .DLL's and perhaps looking at update history of the client's Windows7 instance where the App doesn't run.

The same analysis of my Windows7 test virtual where it does.

Add to my development system the registered ado .DLL's from the working system and put these in the C:\UserApps\AppName\ folder with App.exe.

I'm unclear on exactly how I get the recompiled App to use the above DLL's instead of any which might be registered.  I'm hopeing that the solution to this is not too difficult.

Add these .DLL's to the Radius package to be installed in the same folder.
 
Is there any problem with this approach?
0
 
CSI-Windows_comCommented:
There are several ways to isolate DLLs.

.LOCAL isolation is one way (http://msdn.microsoft.com/en-us/library/windows/desktop/aa375142(v=vs.85).aspx).  However, you must still have working COM registrations - this ONLY overrides the module loading operation.  Also, you must LEAVE the COM registration pointing to the shared version of the files (or fix it if broken) and trust .LOCAL to override the path in the COM registration.  Since this DOES NOT HANDLE malformed or missing COM registrations it may or may not help you.  If at the bottom of this you are experiencing a version / file existence problem ONLY (mixed versions of MDAC DLLs or missing DLLs) - then it would help

Side-by-Side is another way - but it looks like MDAC cannot be configured this way (bottom of this page: http://msdn.microsoft.com/en-us/library/58bc9k67(v=vs.71).aspx).

Then there is "registration-free COM" - looks like it also cannot be applied to MDAC (http://kb.flexerasoftware.com/doc/Helpnet/installshield14helplib/COMReg-RegFree.htm)

However I found some interesting MDAC comments while searching registration free COM on this page:  http://mmm4vb6.atom5.com/when-use-regfree-com-1177.html

Maybe some more searching of your own on some of the above topics will lead you to how other developers have handled these issues.
0
 
VB6chuckAuthor Commented:
When I'm using RegDLLView to determine the precise status of the .DLL's in the ado folder, what notice should I be taking, if any, of the several .TLB files?
0
 
CSI-Windows_comCommented:
I am thinking that the the typelibs would not be causing this problem.  However, if they were the only significant difference between the machines, that would make me think twice.
0
 
SStoryCommented:
Thus the term "DLL HELL" from the VB6.0 and prior days...
0
 
CSI-Windows_comCommented:
"DLL HELL" used to be the ultimate concept around which the entire delivery and maintenance of desktop systems was designed (to avoid).  Until, .LOCAL, Side-By-Side and Registration-Free COM and of course .NET (where component registration data is NEVER in the registry in the first place - just like UNIX/Linux) gained gravity.
0
 
SStoryCommented:
The long term fix is to replace or rewrite the app.  In the short term if you have the code and the time, it may be possible to expose ADO.NET as a COM object or some sort in a DLL from vb.net to that app and rework the DB logic. Of course depending upon the size of the app that might be unthinkable and I'm sure would not be your first choice.

The reason VirtualPC was included in Win 7 Pro is for just such a case as this--to run the XP Apps that Win 7 breaks in a Virtual Win XP.  Another ridiculous, temporary, option might be a terminal server or app server with the app being served under the XP way to a Remote Desktop window on the Win 7 boxes.
0
 
SStoryCommented:
How about XBundler?
http://www.oreans.com/products.php

You could possibly use it to recompile the whole app into a single .EXE file and put that on all computers. I've never done it but it claims to avoid "DLL HELL"
0
 
CSI-Windows_comCommented:
SStory,
The XP mode built in to Windows is unmanagable in the Enterprise - mainly because all the user's folders "my documents, appdata, etc" map into the VM - not the real folders.

Med-V (part of MDOP) is Microsoft's solution to this - it is an XP VM that has all the user folders transparently mapped onto the REAL machine the VM is hosted on.

I have not had experience with XBundler, but I do know the original founder of ThinApp and it was originally targeted at developers.  It is even capable of BUNDLING an isolated version of .NET into the virtual packages (http://www.vmware.com/products/thinapp/howtobuy.html).

Bundler might be able to do such serious things as well.

When you can replace the Windows "Loader" inside in process, you can do all sorts of magic.
0
 
SStoryCommented:
Yes. I didn't say it would be expedient on the virtual, but possibly doable.

XBundler looked like a real option to me because it can supposedly bundle it all into a single EXE which _SHOULD_ make it work, unless the DLLs being bundled won't run under Win 7.
0
 
VB6chuckAuthor Commented:
I've had a look with RegDllView at both the client and my test Windows7 machines.  Both seem to have the same files, including typelibs, installed in the Program Files\Common Files\System\ado folders.  

It is noticable that the client machine has only about 3/4 of the patches applied to Windows7 as the test machine.

Also of note is that on the test machine, where there is no problem, there are 8 Class ID registry entries for msado15.dll, from ADODB.Command through ADODO.Stream.  There is only a single entry on the client machine which is for ADODB Error Lookup Service.

So here is the current question:

Does it make sense to pursue creating the missing registry Class ID entries, or perhaps just seeing if applying all of the current patches would accomplish this?

The virtual is of no interest, it doesn't properly host a client program which uses a remote SQL server.

XBundler would be more attractive if it wasn't an add on to products of less interest, and it appears it would prevent the patching of real security problems.
RegDllViewComparison.txt
0
 
ArkCommented:
Can you check client machine HKCR registry for ADODB.XXX (like ADODB.Recordset, ADODB.Connection) entries? If they are there - you can use late binding (set rst=CreateObject("ADODB.Recordset"). Note that  ADODB.XXX.6.0 require WDAC instead of MDAC installed (Vista and up).
Unfortunately, WDAC is not redistributable and you cannot install/update/register it manually on Vista+ and up
Try http://support.microsoft.com/kb/2640696 updates - probably they fix it.
And take a look at http://blogs.msdn.com/b/psssql/archive/2011/10/03/yes-we-made-a-mistake-and-are-finally-going-to-fix-it.aspx
0
 
VB6chuckAuthor Commented:
Ark - KB 2640696 and the blog discussing it don't quite address my problem.  My App was compiled in XP and will not run on ALL Windows7 SP1 machines.  It runs/ran fine on all machines on which it was tested, including the current latest updates on Win7 SP1, and fails on only the client's Win7 SP1 network rollout workstations - which have less than 3/4 of the current updates.

When RegDllView shows me 8 class entries for msado15.dll, is it finding these using the Class ID or ADODB.XXX?  I'm trying to determine if adding the 8 class entries to the Registry will fix my problem.  Are there more than one instance of a particular version of msado15.dll?  If it is installed using self registry how can the same version come up with 8 class entries and sometimes 1 class entry.  Or has some update come along later and added or removed the class entries?

I'd rather avoid MDAC and WDAC for reasons I've given earlier.  If I can come up with a .REG file which will fix my problem on the client machines, then that's what I'd like to do.
0
 
CSI-Windows_comCommented:
A different of 7 class entries would not be typical for DLLs that are this old and well established.

If this is the result of a bad install, then files could be missing or wrong versions as well.

I would run the update that Ark linked:  http://support.microsoft.com/kb/2640696

Looks like Microsoft also made some big problems here by changing the CLSIDs.  You might be able to fix it up by using .REGs - but it will take a long time and then who knows what else was wrong that they fixed in this update.
0
 
VB6chuckAuthor Commented:
Agreed.

Files installed appear (if version numbers are trustworthy) identical on all computers checked.

KB 2640696 Notes: •ADO-based applications that are compiled in Windows 7 SP1 or in Windows Server 2008 R2 SP1 use the new interface identifiers (IIDs) in the ADO type libraries that were included in the SP1 packages for Windows 7 and for Windows Server 2008 R2.  The new interface IIDs include "{00001514-0000-0010-8000-00AA006D2EA4}".

My App as distributed was compiled on XP SP3 and for sure does not use the new IIDs.  This I can see in the ProcMon logs.  All NAME NOT FOUND for Path includes "{00000514-0000-0010-8000-00AA006D2EA4}".

It would appear that adding these 8 registry entries would settle things for now.  I'm not looking for a solution that future MS updates can't break, that doesn't seem like a reasonable goal.

How does the below strike you as a potential solution?

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\ADODB.Command]
@="ADODB.Command"

[HKEY_CLASSES_ROOT\ADODB.Command\CLSID]
@="{00000507-0000-0010-8000-00AA006D2EA4}"

[HKEY_CLASSES_ROOT\ADODB.Command\CurVer]
@="ADODB.Command.6.0"

[HKEY_CLASSES_ROOT\ADODB.Command.6.0]
@="ADODB.Command"

[HKEY_CLASSES_ROOT\ADODB.Command.6.0\CLSID]
@="{00000507-0000-0010-8000-00AA006D2EA4}"

[HKEY_CLASSES_ROOT\ADODB.Connection]
@="ADODB.Connection"

[HKEY_CLASSES_ROOT\ADODB.Connection\CLSID]
@="{00000514-0000-0010-8000-00AA006D2EA4}"

[HKEY_CLASSES_ROOT\ADODB.Connection\CurVer]
@="ADODB.Connection.6.0"

[HKEY_CLASSES_ROOT\ADODB.Connection.6.0]
@="ADODB.Connection"

[HKEY_CLASSES_ROOT\ADODB.Connection.6.0\CLSID]
@="{00000514-0000-0010-8000-00AA006D2EA4}"

[HKEY_CLASSES_ROOT\ADODB.Error]
@="ADODB.Error"

[HKEY_CLASSES_ROOT\ADODB.Error\CLSID]
@="{00000541-0000-0010-8000-00AA006D2EA4}"

[HKEY_CLASSES_ROOT\ADODB.Error\CurVer]
@="ADODB.Error.6.0"

[HKEY_CLASSES_ROOT\ADODB.Error.6.0]
@="ADODB.Error"

[HKEY_CLASSES_ROOT\ADODB.Error.6.0\CLSID]
@="{00000541-0000-0010-8000-00AA006D2EA4}"

[HKEY_CLASSES_ROOT\ADODB.ErrorLookup]
@="ADODB Error Lookup Service"

[HKEY_CLASSES_ROOT\ADODB.ErrorLookup\CLSID]
@="{00000542-0000-0010-8000-00AA006D2EA4}"

[HKEY_CLASSES_ROOT\ADODB.ErrorLookup\CurVer]
@="ADODB.ErrorLookup.6.0"

[HKEY_CLASSES_ROOT\ADODB.ErrorLookup.6.0]
@="ADODB Error Lookup Service"

[HKEY_CLASSES_ROOT\ADODB.ErrorLookup.6.0\CLSID]
@="{00000542-0000-0010-8000-00AA006D2EA4}"

[HKEY_CLASSES_ROOT\ADODB.Parameter]
@="ADODB.Parameter"

[HKEY_CLASSES_ROOT\ADODB.Parameter\CLSID]
@="{0000050B-0000-0010-8000-00AA006D2EA4}"

[HKEY_CLASSES_ROOT\ADODB.Parameter\CurVer]
@="ADODB.Parameter.6.0"

[HKEY_CLASSES_ROOT\ADODB.Parameter.6.0]
@="ADODB.Parameter"

[HKEY_CLASSES_ROOT\ADODB.Parameter.6.0\CLSID]
@="{0000050B-0000-0010-8000-00AA006D2EA4}"

[HKEY_CLASSES_ROOT\ADODB.Record]
@="ADODB.Record"

[HKEY_CLASSES_ROOT\ADODB.Record\CLSID]
@="{00000560-0000-0010-8000-00AA006D2EA4}"

[HKEY_CLASSES_ROOT\ADODB.Record\CurVer]
@="ADODB.Record.6.0"

[HKEY_CLASSES_ROOT\ADODB.Record.6.0]
@="ADODB.Record"

[HKEY_CLASSES_ROOT\ADODB.Record.6.0\CLSID]
@="{00000560-0000-0010-8000-00AA006D2EA4}"

[HKEY_CLASSES_ROOT\ADODB.Recordset]
@="ADODB.Recordset"

[HKEY_CLASSES_ROOT\ADODB.Recordset\CLSID]
@="{00000535-0000-0010-8000-00AA006D2EA4}"

[HKEY_CLASSES_ROOT\ADODB.Recordset\CurVer]
@="ADODB.Recordset.6.0"

[HKEY_CLASSES_ROOT\ADODB.Recordset.6.0]
@="ADODB.Recordset"

[HKEY_CLASSES_ROOT\ADODB.Recordset.6.0\CLSID]
@="{00000535-0000-0010-8000-00AA006D2EA4}"

[HKEY_CLASSES_ROOT\ADODB.Stream]
@="ADODB.Stream"

[HKEY_CLASSES_ROOT\ADODB.Stream\CLSID]
@="{00000566-0000-0010-8000-00AA006D2EA4}"

[HKEY_CLASSES_ROOT\ADODB.Stream\CurVer]
@="ADODB.Stream.6.0"

[HKEY_CLASSES_ROOT\ADODB.Stream.6.0]
@="ADODB.Stream"

[HKEY_CLASSES_ROOT\ADODB.Stream.6.0\CLSID]
@="{00000566-0000-0010-8000-00AA006D2EA4}"
0
 
CSI-Windows_comCommented:
I think your solution is a reasonable work around.  

I would advise thoroughly regression testing against this workaround.

I would advise that you include the installer for the fix as well as the fixup registry keys in your installer.

I would advise you create a roadmap to get off this aging database middleware.
0
 
VB6chuckAuthor Commented:
By installer for the fix as well as fixup registry keys do you mean adding the install of the keys to the Radius package as well as installing the .REG file itself?  That sounds potentially very useful.

A roadmap is an excellent idea.  The client wanted the existing App, which had been in use for 6 years, adapted to Win7.  My suggestion was installing it on an appropriate virtual server where these patches wouldn't have arrived, and using Remote Desktop to access it.  The client will be happy to hear the problem is solved in Windows8.  After that any updates will probably require a rewrite.

Thank you.
0
 
CSI-Windows_comCommented:
I think I misunderstood that you applied the KB fix to resolve part of the problem - but I see you were saying that the machines are already up to date.

You would only need to add the REG keys to the Radia package - you would not also need to run the .REG

I would advise you also update your installer and/or your app to insert the needed keys.  As always, it might be good to check that the files are there before inserting the keys.

One caution! Some apps already running on the platform might be probing which CLSIDs are available and use the old ones when they can (app assumes it's running on Windows XP) - this means it would be VERY important to ensure that your registry keys are distributing the FULL COM registration of the old CLSIDs. Hopefully the are NOT using CLSID detection to do anything else in their application or have any type of limited functionality by switching to the old CLSIDs.

Technically, writing your app to detect and use the appropriate CLSIDs would be the least potential impact to existing applications.
0
 
VB6chuckAuthor Commented:
OK just add the Keys in the Radia package.  I was thinking you wanted the .REG file around in case an update removed the keys.

Both Client (non-working) and Test (working) computers have the same set of files with matching versions in the C:\Program Files\Common Files\System\ado folder.  The DLLs are all version 6.1.xxx.xxx.  Both computers have the same CLSID regestry keys (all 6.0) relating to these files EXCEPT the Client computer has only 1 of the 8 keys for msado15.dll present on the working computer.  The missing 7 keys are the only difference between Client and Test computer relating to the ado folder, and there are no different files other Apps might be using there.

Any other apps which might be running on the old CLSID if they could find it would have been failing to find the new CLSID as it's not there unless it references some other msado15.dll file which isn't in the ado folder.  In this case apps which were failing should start working - I think i've covered enough bases to insure the only app for which this applies would be mine - the one with the original problem.

As MS updates have been switching them back and forth I'm not sure there are any "appropriate" CLSIDs other than the ones which work when referenced.

I understand that porting VB6 to Win7SP1 might allow me to generate a new install package and .exe which works for the moment - except on all the non-upgraged XP's the client still has on the network - but this would only last until the broken ADO was "fixed" by a new update.

I'm off to the client to hopefully get them a working computer on which they can test not only the App but everything else.
0
 
SStoryCommented:
I agree with the "get off it."  It is aggravating to have to rewrite a large app for no good reason.
This often makes me wonder if the ease of initial creation of Microsoft products is worth the fact that they will trash it and rewrite will be their "solution."
0
 
CSI-Windows_comCommented:
VB6Chuck,
Something you mentioned made me think that putting the reg keys into your app would be a good move as well.

If it is indeed an uninstaller (or even a future MS update) that removes the CLSIDs - if you check for and insert them in your App, you would essentially "self-heal" your app anytime something messed with them.  You and the customer would no longer have to have surprises and run around fixing the app.

The challenge is that you would have to push these into HKCU\Software\Classes\CLSID if they are not present because your app probably does not have HKLM\Software access at runtime (and shouldn't).

Perhaps a .REG with the app that the App can use and that admins can use to fix up.  This way you could also update the reg keys without a recompile.

You should *also* do it in the Radia package so that it is initially set to go properly in HKLM.
0
 
ArkCommented:
Which version of ADO are you using in your VB project (Menu->Project->References)?
0
 
VB6chuckAuthor Commented:
Well, the .REG approach doesn't work.  

With admin rights the error message was to the effect that some of the registry entries were not updated (none were) due to the keys being in use.  This would seem to indicate that I shouldn't be changing anything there, if the idle OS has them locked.

An attempt with regsvr32 on msado15.dll appeared to work, but according to RegDllView nothing in the registry was changed.

A final approach might be to have all outstanding Windows Updates applied, and then have another look.

Other than that, I'm at a complete loss . . .
0
 
CSI-Windows_comCommented:
I never thought to check until now, but those registrations are under Windows Resource Protection.

You can tell because only "TrustedInstaller" has full permissions to change them.

regsvr32  (and msiexec.exe) are lied to using the WRPMitigation shim - so when you register the DLLs regsvr32.exe is told that it was successful.  Here is where this lie discussed: http://technet.microsoft.com/en-us/library/dd638325(v=ws.10).aspx

One option that is a bit of a hack, is have your app install these registry keys in HKCU\Software\Classes - it would have check each time you startup to see if it needs to insert them.

HKCU\Software\Classes overlays HKLM\Software\Classes when they are both merged into HKCR.  Also CoCreateInstance actually specifically checks HKCU first.

There should not be able Windows Resource Protection in HKCU.

This wouldn't work if the app is run ELEVATED by users.

Also, if there are updates that fix this, that is a better solution.
0
 
VB6chuckAuthor Commented:
I can add to my app the addition of the keys to HKCU, but it should check to see if they're there first?  Sounds worth trying.

The users can't use ELEVATED as they are all just users.

Are there updates that fix this?  I don't know . . . I do have a Win7 test machine with current updates that doesn't have the problem.  And it's SP1.  And I have no idea why my client's SP1 machines have a problem.  

I've seen references to Hotfixes -

"I was able to get the test patch from MS support (KB2734642). The patch seems to work fine as long as you reinstall the original patch (kb2698365) first and then install the Hotfix."

I've got the hotfix on the way by email.  I'll think about the KB2698365 a little after I get KB2734642 and maybe opt instead for the HKCU program change.  Part of the problem here may be that there are more than one issue.  The majority seem concerned with running Win7 SP1 compiles on Win7 and XP machines, whereas I'm in a minority who want to run XP compiles on Win7 SP1 in a specific highly controlled environment.  And then there are the developers who have concerns with 64-bit ADO, who were apparently happy with Win7 RTM.  I suspect they're in the SP1 compiles camp.

Windows Resource Protection Mitigation?  Hard to know how to respond to that.
0
 
ArkCommented:
As I wrote before WDAC (MDAC successor) is not redistributable - it's part of system. This means that you cannot overwrite/create correspondent registry keys even with admin rights - system rights required.
Explaining my previous question about ADO version - I suggest try using *.tlb ado sources instead of *.dll (AFAIK ADO 2.7 is the last *.tlb based version for VB6, 2.8 and above points to *.dll). TLB is a wrapper which allow using old IID's from executables and redirect to new ones in new ado dll. Each WDAC version replaces old tlb (you can find tlb's at c:\Program Files\Common Files\System\ado\ folder). So if your app call ADO objects using old IID, tlb will redirect calls to msado15.dll with new IID.
0
 
VB6chuckAuthor Commented:
Ark - I presume the .tlb remedy should be somewhere in http://support.microsoft.com/kb/2640696
however all of the scenarios described do not seem to fit my situation.

I have a compiled App.exe made with vb6 on XP SP3 which has passed a several month approval cycle and now needs to be installed using Radius on a network of Windows 7 SP1 machines  which currently will not run it.  The network will also, over a period of months, be replacing legacy XP machines which are currently running the App.exe.  During the approval cycle App.exe was tested without problems on a few Windows 7 computers.  

There is a chance that I can get a recompile approved, however to support the legacy machines I prefer to do the compile on XP SP3, which does not have updates which include msado28.tlb or msado60.tlb.  This also saves me the difficulties of getting VB6 up and running in Win7 SP1.

CSI-Windows_com - In view of the above, adding the keys to HKCU in the app would seem to be the only approach left.  If I update the HKCU registry entries as the app starts, when are they both merged into HKCR?  I'm not clear how this would affect the execution of the app and allow the ado calls to succeed.
0
 
SStoryCommented:
If it is a UAC issue (you could try that by temporarily disabling it), then you might buy some time as follows:

http://www.ghacks.net/2010/07/08/get-rid-of-uac-prompts-with-microsofts-application-compatibility-toolkit/

Turn off UAC for this single app.  If however it is "DLL Hell" this won't help you.
0
 
CSI-Windows_comCommented:
HKCR has become very confusing (but you already knew that).

There are TWO ways in which HKCU is referenced before HKLM.

1) At the registry level the keys I mentioned above are fully merged - unique values from both levels flow up to HKCR.  If data is changed at the HKCR it changes whatever level is "showing through".  Permissions flow through from underlying keys as well.

You can test this by creating a fake key under Software\Classes\ on both HKLM and HKCU and view HKCR.  Use ".111" so it sorts to the top (I demo this in class all the time).

2) CoCreateInstance MANUALLY (as in does not rely on HKCR merging) checks HKCU first and then HKCR.
0
 
CSI-Windows_comCommented:
SStory,
There is not a way to "turn off" UAC for an app - asInvoker manifesting simply tells the OS "I don't need admin rights, even if something is telling you I do."  In the case of using App Compat this can even override an internal manifest for requireAdministrator.

You would generally use this when you have an exe you've named "update.exe" that is NOT an installer and want to suppress the automatic installer detection.  There are other scenarios as well - that is just an example.

(FYI sidepoint: there is a much easier way to manifest using the registry instead of creating and pre-installing .SDBs)

Disabling UAC does not disable Windows Integrity Mechanism (WIM) - it is an upgrade to Windows File Protection that would have been done regardless of UAC being implemented.

Even with UAC disabled, Administrators (and any profile besides TrustedInstaller) will not be able to alter COM registrations protected by WRP.
0
 
SStoryCommented:
Interesting... Well, I'm doing it right now in our organization with an app that will not run with UAC on, but will run by doing this, so I thought I'd mention it to him.

I'd love to know about the easy way if you want to post it.
0
 
CSI-Windows_comCommented:
SStory - edit and merge the below.

There is one key difference between the below and what you have done with an SDB.  The below is a LAYER - which means it applies to EVERYTHING in the process and ANY child process started from the process.  Usually when manifesting asInvoker, this isn't a problem.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Program Files (x86)\\YourFolder\\YourApp.exe"="RUNASINVOKER"

Open in new window

0
 
VB6chuckAuthor Commented:
This is all very interesting, however I have no problem with UAC and the problem I DO have occurs even if the APP is run with Admin priviledges.

To get back to updating HKCU from the App as it starts.  

In my comments Posted on 2012-09-17 at 10:21:22 I listed 40 keys ( 8 x 5 ) which should be in HKCR, which if I add them to HKCU might be added to HKCU\Software\Classes\ .  Is this correct?

In addition, there are cross-referencing keys in HKCR\CLSID which could be added to HKCU as HKCU\Software\Classes\CLSID .  There should be 4 keys for each CLSID for instance:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00000514-0000-0010-8000-00AA006D2EA4}]
@="ADODB.Connection"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00000514-0000-0010-8000-00AA006D2EA4}\InprocServer32]
@=hex(2):25,00,43,00,6f,00,6d,00,6d,00,6f,00,6e,00,50,00,72,00,6f,00,67,00,72,\
  00,61,00,6d,00,46,00,69,00,6c,00,65,00,73,00,25,00,5c,00,53,00,79,00,73,00,\
  74,00,65,00,6d,00,5c,00,61,00,64,00,6f,00,5c,00,6d,00,73,00,61,00,64,00,6f,\
  00,31,00,35,00,2e,00,64,00,6c,00,6c,00,00,00
"ThreadingModel"="Apartment"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00000514-0000-0010-8000-00AA006D2EA4}\ProgID]
@="ADODB.Connection.6.0"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00000514-0000-0010-8000-00AA006D2EA4}\VersionIndependentProgID]
@="ADODB.Connection"

I'm thinking that the last key, VersionIndependentProgID, could be dispensed with in an all 32 bit environment.

I was surprised by -
hex(2):25,00,43,00,6f,00,6d,00,6d,00,6f,00,6e,00,50,00,72,00,6f,00,67,00,72,\
  00,61,00,6d,00,46,00,69,00,6c,00,65,00,73,00,25,00,5c,00,53,00,79,00,73,00,\
  74,00,65,00,6d,00,5c,00,61,00,64,00,6f,00,5c,00,6d,00,73,00,61,00,64,00,6f,\
  00,31,00,35,00,2e,00,64,00,6c,00,6c,00,00,00
which Regedit shows as -
REG_EXPAND_SZ with a value of "%CommonProgramFiles%\System\ado\msado15.dll"

Is it reasonable to expect the user will have rights to create these keys given the problems already encountered?

I'm beginning to think XBundler might be my solution . . .
0
 
SStoryCommented:
CSI-Windows_com,
Thanks for the info. Sorry, vb6chuck, but since the point was brought up I wanted to know how.
0
 
VB6chuckAuthor Commented:
Can't argue with that.
0
 
CSI-Windows_comCommented:
The ROOT of HKCR maps to the ROOT of HKLM\Software\Classes and HKCU\Software\Classes - including subkeys like CLSID

In your reg file simply search for "HKEY_LOCAL_MACHINE" and replace with "HKEY_CURRENT_USER".

REG_EXPAND_SZ keys have any contained environment variables expanded upon reading the key.  I think it is due to the percent signs (%), that the values must be encoded when exported to .REG files.

I just tested merging the first two of the above REG lines with a regular user profile and it works fine.

Complete isolation of your app and it's runtimes is the premier solution - but I think you are right on the cusp of a simple solution that is easy to understand.  More likely than not the isolation of your app in another technology is going to raise issues you hadn't thought of before - especially if you haven't used the technology before.  (for instance, all your OWN COM registered objects will be visible ONLY to your app - not other apps nor Windows - so if any other software or OS attempts to use your COM objects, it won't find them).  

FYI I train people to package using App-V which is Microsoft's application isolation/virtualization solution for IT Pros.
0
 
VB6chuckAuthor Commented:
I'm not all that keen to try Xbundler at this point, especially since it's embeded in code obfuscation that I don't really need, and I'm sure that there'll be a learning curve and perhaps nasty surprises.

My .REG file currently has HEKY_CLASSES_ROOT\, which I should replace with HKEY_CURRENT_USER\Software\Classes\, right?

In addition, I've omitted from my .REG file the CLSID entries which should be under
HKEY_CURRENT_USER\Software\Classes\CLSID\ entries -

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00000514-0000-0010-8000-00AA006D2EA4}]
@="ADODB.Connection"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00000514-0000-0010-8000-00AA006D2EA4}\InprocServer32]
@="%CommonProgramFiles%\System\ado\msado15.dll"
"ThreadingModel"="Apartment"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00000514-0000-0010-8000-00AA006D2EA4}\ProgID]
@="ADODB.Connection.6.0"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00000514-0000-0010-8000-00AA006D2EA4}\VersionIndependentProgID]
@="ADODB.Connection"

Is there a way within a .REG file to specify that keys be added only if absent or different?

I was thinking that perhaps the registry changes should be made from within the app when it starts and checking for the presence of correct keys be done before adding missing ones.

An alternative would be to have a well crafted .REG file added to the install and have the App "execute" it from a CMD shell as soon as the App starts.  This could be tested and proven before bothering to change and recompile the App.  The .REG could be added to the Radius package and the App.exe replaced.
0
 
CSI-Windows_comCommented:
My .REG file currently has HEKY_CLASSES_ROOT\, which I should replace with HKEY_CURRENT_USER\Software\Classes\, right?

> Yes that is correct.

Is there a way within a .REG file to specify that keys be added only if absent or different?

> No.

In addition, I've omitted from my .REG file the CLSID entries which should be under
HKEY_CURRENT_USER\Software\Classes\CLSID\

> Correct.

I was thinking that perhaps the registry changes should be made from within the app when it starts and checking for the presence of correct keys be done before adding missing ones.

> It would be very unusual for these keys to be present in HKCU and especially unusual for them to be directed to a different location or have different information (given that the files they are registering are so old) - so it is not likely to cause problems to slam them in each time.

> I would put in a vote for the .REG as it is simple, easy to update and understandable by the Radia packagers.  I would also consider making it so that it doesn't choke if the file is missing - just move on - that way if there is a better setup-time fix down the road you can just rename the .reg.

Make sure that your registry keys comprise a complete COM registration.

If you look for "Capture Self-Registration Information" on this page: http://www.installsite.org/pages/en/msi/tips.htm, you will find a couple utilities that specialize in capturing COM registration data from DLLs.
0
 
VB6chuckAuthor Commented:
Please excuse my absence, I've been ill and have not been able to test the latest suggestions on site.  My office test system does not exhibit the problem and I've not been able test solutions except by making a 30 minute trip to the client's site at a time convenient to the client.  I expect to have the latest results early next week.
0
 
VB6chuckAuthor Commented:
Every time I think I have a handle on this, something doesn't fit, or work, or whatever.

I've tried RegSpy and RegSpy2 on both the XP machine where the original App .exe was built, and on the Windows7 test machine where the App also works.  The output on the former was the incomplete:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\ADOR.Recordset]
@="ADOR.Recordset"

[HKEY_CLASSES_ROOT\ADOR.Recordset\CLSID]
@="{00000535-0000-0010-8000-00AA006D2EA4}"

[HKEY_CLASSES_ROOT\ADOR.Recordset\CurVer]
@="ADOR.Recordset.2.8"

[HKEY_CLASSES_ROOT\CLSID]

[HKEY_CLASSES_ROOT\CLSID\{0000051A-0000-0010-8000-00AA006D2EA4}]
@="ADO 2.8"

[HKEY_CLASSES_ROOT\CLSID\{0000051A-0000-0010-8000-00AA006D2EA4}\ExtendedErrors]
@="Extended Error Service"

[HKEY_CLASSES_ROOT\CLSID\{0000051A-0000-0010-8000-00AA006D2EA4}\ExtendedErrors\{00000542-0000-0010-8000-00AA006D2EA4}]
@="ADO Error Lookup"
 
Which corresponds to what RegDllView shows on the client's computer, where the error occurs.  I understand that RegSpy was not intended for XP, but find the results interesting.

And on the latter there was no output.  RegSpy2 put out a header, RegSpy, nothing.
This was where I was hoping to get a .REG file which would be useful.
At the same time, RegDllView for this computer shows 8 system entries for the same dll.

I was running the Command Prompt as Administrator and the command in both cases was:
regspy "C:\Program Files\Common Files\System\ado\msado15.dll" > msado15_dll.txt

Presumably RegDllView gives me enough information that I could hand build a .REG file with it, creating the transpositions as I went along.  It seems like that's the next step.  It just doesn't seem like the safest course.

Can you suggest an improvement?

As an example of what I might do -

In reviewing the registry entries for the first of 8 CLSID's relating to msado15.dll I find the entries -

HKCR\ADODB.Command
@="ADODB.Command"

HKCR\ADODB.Command\CLSID
@="{00000507-0000-0010-8000-00AA006D2EA4}"

HKCR\ADODB.Command\CurVer
@="ADODB.Command.6.0"

HKCR\ADODB.Command.6.0
@="ADODB.Command"

HKCR\ADODB.Command.6.0\CLSID
@="{00000507-0000-0010-8000-00AA006D2EA4}"

HKCR\CLSID\{00000507-0000-0010-8000-00AA006D2EA4}
@="ADODB.Command"

HKCR\CLSID\{00000507-0000-0010-8000-00AA006D2EA4}\InprocServer32
@="%CommonProgramFiles%\System\ado\msado15.dll"
"ThreadingModel"="Both"

HKCR\CLSID\{00000507-0000-0010-8000-00AA006D2EA4}\ProgID
@="ADODB.Command.6.0"

HKCR\CLSID\{00000507-0000-0010-8000-00AA006D2EA4}\VersionIndependentProgID
@="ADODB.Command"

AND all of the above repeats with HKCR\ mapped to HKLM\SOFTWARE\Classes\

and to obtain this I should build a .REG file with the above entries
mapping HKCR\ to HKEY_CURRENT_USER\Software\Classes\ so each CLSID would have -

HKEY_CURRENT_USER\Software\Classes\ADODB.Command
@="ADODB.Command"

HKEY_CURRENT_USER\Software\Classes\ADODB.Command\CLSID
@="{00000507-0000-0010-8000-00AA006D2EA4}"

HKEY_CURRENT_USER\Software\Classes\ADODB.Command\CurVer
@="ADODB.Command.6.0"

HKEY_CURRENT_USER\Software\Classes\ADODB.Command.6.0
@="ADODB.Command"

HKEY_CURRENT_USER\Software\Classes\ADODB.Command.6.0\CLSID
@="{00000507-0000-0010-8000-00AA006D2EA4}"

HKEY_CURRENT_USER\Software\Classes\CLSID\{00000507-0000-0010-8000-00AA006D2EA4}
@="ADODB.Command"

HKEY_CURRENT_USER\Software\Classes\CLSID\{00000507-0000-0010-8000-00AA006D2EA4}\InprocServer32
@="%CommonProgramFiles%\System\ado\msado15.dll"
"ThreadingModel"="Both"

HKEY_CURRENT_USER\Software\Classes\CLSID\{00000507-0000-0010-8000-00AA006D2EA4}\ProgID
@="ADODB.Command.6.0"

HKEY_CURRENT_USER\Software\Classes\CLSID\{00000507-0000-0010-8000-00AA006D2EA4}\VersionIndependentProgID
@="ADODB.Command"

There are 20 CLSID's for the 5 .DLL files in the ..\System\ado\ folder.  It seems daunting, but since all the info is in 10 text files, 2 for each .DLL, perhaps I could write a program to generate the .REG from them - providing that's what needs to be done. . . .
0
 
CSI-Windows_comCommented:
If you're concerned about completeness you could just use RegDLLView to identify the CLSIDs and then use regedit to export each.

Make sure you are running the tools from an elevated command prompt.

Another approach, use procmon to monitor.

Create a filter:

Path Contains "CLSID\{"

On each unique instance right click and select "Jump To" and export the key.

Wise and Installshield both have COM registration extraction utilities if you have access to either of those. I believe in both cases it is just a loose EXE in the program files folder - not accessible via a menu.
0
 
VB6chuckAuthor Commented:
I have all the required data in the RegDLLView text output I've already gathered.

Always used elevated command prompt.  Did that.

ProcMon gets me too much data.

Just getting the CLSID\{ won't get me some of the entries, such as -

HKEY_CURRENT_USER\Software\Classes\ADODB.Command.6.0
@="ADODB.Command"

Exporting Regedit entries doesn't get me the transposed entries, although granted that's editable stuff.

Don't have either Wise or Installshield, sorry.

All I need to do is identify each of the parameters in the RegDllView output and write a program to reorganize them into .REG entries.  And the generate the 180 key .REG file that gives me at 9 keys for each of 20 CLSID's.  And carefully review each one.  Ouch.

I take it that you're in agreement with the general approach?
0
 
CSI-Windows_comCommented:
I just did some experimentation.

If you use regspy or procmon, you'll need to do this on XP.  Windows Resource Protection appears to block from these utilities the fact that you are writing to the registry.

Since these files are so old, there should be no difference.  Copy the Win7 ones to the XP machine if necessary.

Separate issue: Does your software run on 64-bit?

If so, people who try to use the .REG you create directly from a 64-bit process (such as double clicking the .REG) will import it into 64-bit COM registry, not 32-bit.

You might want to provide a batch file like "COMRegistrationMustBe32-bit-UseThisScript.cmd.

Which contains:
%windir%\syswow64\regedit.exe /s <yourregfile.reg>

Running the .REG in your 32-bit software is not a problem as it is a 32-bit program so it will be redirected - even if you use %windir%\system32\regedit.exe - Windows will redirect you to SysWOW64.
0
 
VB6chuckAuthor Commented:
In the comment by: VB6chuckPosted on 2012-09-28 at 19:03:46ID: 38446420 above I indicated that I tried both RegSpy and Regspy2 on the XP machine and they produced the results which the client computer (which has the original error) shows.  How this can be the case when the App runs fine on the XP machine is a mystery to me.

I don't need more mysteries, I need an approach to the primary problem.

64-bit compatability, thank heavens, doesn't enter into the issue at all.  The client's entire workstation rollout is 32-bit.

The results of running RegDllView on the client's machine, which has the problem, and on the test Windows 7 machine, which doesn't, seem reasonable.  

Client's machine has 1 System Entry for msado15.dll.  That entry is for ADODB Error Lookup Service.

Test machine has 8 System Entries for msado15.dll, one of which is missing on the client machine which fails on attempting to find it.  Test machine runs fine.

Given the above, and the information provided by RegDllView, I'm suggesting building a .REG file with the information retrieved, using the pattern given above, derived from exported entries, and asking what you think of this approach.

The problem is that I will spend a lot of effort creating this .REG file, then drive for an hour and a half round trip and inconvenience the client to test it out.  If there's something wrong with this approach I'd really appreciate knowing before I waste the time.

I do very much appreciate and value your interest and efforts in this to date, and I've got to give the client some hope of resolution.
0
 
ArkCommented:
I already tried to explain. From http://msdn.microsoft.com/en-us/library/ms693148(VS.85).aspx
Windows Data Access Components (Windows DAC) 6.0 is included in Windows Vista. It is not distributed separately and cannot be redistributed. Similarly, Microsoft Data Access Components (MDAC) 2.8 was included with Windows XP and Windows Server 2003. However, there is also a redistributable version of MDAC, MDAC 2.8 Service Pack (SP) 1.Note that this redistributable version should only be installed on Windows 2000. It should not be installed on any later versions of the data access components
Period.
You CANNOT install any DAC components on Vista/Win7. Try repair system files on problem machine (sfc /scannow from command prompt under admin rights). Try recompile project using msado27.tlb - AFAIK it's the last OS independent version

PS. Just a thought - remove any MDAC from your insatllation package.
0
 
CSI-Windows_comCommented:
Posted this from my phone last night, but it didn't' take.

What ever gets you a reliable extract of all the registry keys is great.  Don't forget to change them to HKCU.

If the machine is internet connected then teamviewer.com might save you a drive.  It is a remote control solution that doesn't require installation.

64-bit is likely to arrive without you knowledge - good to be ready ahead of time if possible.
0
 
VB6chuckAuthor Commented:
Thanks.  Roger HKCU.  teamviewer.com sounds like copilot.com which I use regularly for some clients.  Violates this client's security rules.  I understand the 64 bit problem, however it's much like MS's next move, except I can tell the client to avoid 64 bit.  May not help, but it's worth a try.  Thanks again - should have some results soon.
0
 
VB6chuckAuthor Commented:
I'm getting a bit confused between CSI and Ark here.  If I understand Ark correctly, Windows Resource Protection will prevent my registering any ADO dll's on Windows7.  If that is the case, then I'm in a very bad place here since the client has a mixed XP and Win7 network of workstations migrating to all Win7 as time progresses.  The XP workstations will need the current install package, but in order to use msado27.tlb I will need to 1) Install Visual Studio 6.0 and updates on a Windows7 system, and get it working properly, then alter my updating process where a value in the database can prompt the running program to replace itself with a new .exe, so that it choses the proper .exe for the current OS, and 3) recompile and test my app on Windows and build a different install package for Windows7 using msado27.tlb

And finally,. present the "two different install packages" solution to the client who has been hoping for a fix to his current problem.  Client's IT department will want weeks before they will approve the new install package.

Why is Microsoft, in all it's wisdom, using and altering ADO at all?  What were they thinking?
0
 
CSI-Windows_comCommented:
I mentioned Windows Resource Protection (WRP) with a fairly thorough explanation quite a ways back on the thread.

The WRPMitigation shim is on regsrv32.exe and msiexec.exe and setup.exe.  So when either of those EXEs is running and calls DllRegisterServer on a DLL it is going through this Shim (DLL Detours through aclayers.dll) and the shim sees that the registry key is protected and masks the access denied message and tells the caller (regsrv32/msiexec/setup)  that everything went fine.

The reason an HKCU registry key tweak should work is two fold:
1) HKCU\Software\Classes keys are NOT under WRP protection.
2) Using a .REG rather than a formal call to the DLLs DllRegisterServer function prevents the WRPMitigation shim from masking the import.

It should be a very quick test.  

Acquire the COM registry keys (regspy2 on an Xp system to register the desired DLLs may be the quickest).

Search and replace HKEY_LOCAL_MACHINE with HKEY_CURRENT_USER and HKEY_CLASSES_ROOT with HKCU\Software\Classes.

Import on Windows 7 and test.
0
 
VB6chuckAuthor Commented:
Small snag with the very quick test.  As reported before and re-confirmed by repeating the entire process.  Running RegSpy2 on the XP system gives me something undesirable -

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\ADOR.Recordset]
@="ADOR.Recordset"

[HKEY_CLASSES_ROOT\ADOR.Recordset\CLSID]
@="{00000535-0000-0010-8000-00AA006D2EA4}"

[HKEY_CLASSES_ROOT\ADOR.Recordset\CurVer]
@="ADOR.Recordset.2.8"

[HKEY_CLASSES_ROOT\CLSID]

[HKEY_CLASSES_ROOT\CLSID\{0000051A-0000-0010-8000-00AA006D2EA4}]
@="ADO 2.8"

[HKEY_CLASSES_ROOT\CLSID\{0000051A-0000-0010-8000-00AA006D2EA4}\ExtendedErrors]
@="Extended Error Service"

[HKEY_CLASSES_ROOT\CLSID\{0000051A-0000-0010-8000-00AA006D2EA4}\ExtendedErrors\{00000542-0000-0010-8000-00AA006D2EA4}]
@="ADO Error Lookup"

-- that's it.

If I run it on a Win7 system where the App is working, I get even less -

Administrator: Command Prompt  <-- running as admin

E:\RegSpy\RegSpy2\Release>Regspy.exe "C:\Program Files\Common Files\System\ado\msado15.dll" /RegServer > msado15_dll_testWin7.txt

E:\RegSpy\RegSpy2\Release>type msado15_dll_testWin7.txt

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\CLSID]


E:\RegSpy\RegSpy2\Release>

-- no search and replace appears necessary.

However . . . RegDllView gives me a lot to work with on the Win7 system, it's just not in .REG file format at all, but I can write a program to change that and I'll do that tomorrow and hopefully get a test in on Tues or Wed.  I'm far enough down this road I might as well be following it.
0
 
ArkCommented:
Try to register your own tlb instead of WDAC ones. Not sure it'll work though.
1. Locate HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib\{2A75196C-D9EB-4129-B803-931327F72D5C} and set it's owner to Admin(if it's not).
2. Run regtlibv12 -u "%CommonProgramFiles(x86)%\system\ado\msado28.tlb"
3. Copy your msado28.tlb (from XP SP3 or win7 RTM without SP1) on target machine  - use other location than CommonProgramFiles(x86)%\system\ado folder
3. Run regtlibv12 "{your_28_tlb_path}\msado28.tlb"
(regtlibv12 can be found at C:\Windows\Microsoft.NET\Framework\version_number\")
0
 
VB6chuckAuthor Commented:
I don't follow the concept of "my own" tlb.  For a start, there is no msado28.tlb under XP SP3 and I'm not clear if you're suggesting a recompile there or on Win7 (RTM?) where there is one.  Don't presently have Win7 RTM computer.  version_number? I have 2 and 4 on XP SP3.
I'm suspicious that I'll find this route runs into WRPMitigation as has happened before.  

I'll try the no-recompile option first.
0
 
VB6chuckAuthor Commented:
Another hitch in the saga.  Wrote a program to reformat RegDllView output into a .REG file.  Did that.  Took the .REG file (all HKCU keys) to the client's.  Received the error "Registry Editing has been disabled by your administrator".  Will try again tomorrow with assist from administrator, however IF it works I cannot add it to my program, but only to the Radius distribution package.  Which means if the fix is undone by future updates the Radius package will need to be re-applied, which should work out ok . . .
0
 
CSI-Windows_comCommented:
I believe Radia packages can be configured to self-heal - you could as the packagers to set the registry keys up for self-healing
0
 
VB6chuckAuthor Commented:
Latest news from the client.

After further Windows 7 rollouts it was discovered that the latest batch was not affected with the Runtime error 429 problem, but found to be fully functional, even though the registry entries for msado15.dll were limited to the single error entry according to RegDllView.

Further investigation has revealed that the problem machine had a several months previously generated Radia package applied instead of the current package containing the tested Windows 7 compatable version.

Difficult to express my reaction to this, but it seems to explain everything except why I couldn't isolate the problem.  

Further confirmation today and in the next few days should close this thread at long last.  Thank you for all your patience and helpful advice.
0
 
CSI-Windows_comCommented:
I didn't realize we were dealing with a single instance here.

If I were you I would establish and expectation with your client that if a problem is limited to one machine and cannot be reproduced on a newly loaded machine that they would simple reload the entire machine.

This is what they would do if they had a single instance problem that affected the software they were responsible for.

Now that you have this use case on your hands you have the leverage to show how much time you (and other who helped you) put into a single instance problem.

This is an especially reasonable expectation if the client has the ability to quickly re-image workstations.
0
 
VB6chuckAuthor Commented:
A great deal of time and thought was put into what turned out to be an issue caused by client's misidentification of software being loaded which was not caught until many potential solutions were tried and failed.  I've learned a great deal and tried several useful tools and I cannot thank those who contributed to this enough.
0

Featured Post

Get free NFR key for Veeam Availability Suite 9.5

Veeam is happy to provide a free NFR license (1 year, 2 sockets) to all certified IT Pros. The license allows for the non-production use of Veeam Availability Suite v9.5 in your home lab, without any feature limitations. It works for both VMware and Hyper-V environments

  • 49
  • 33
  • 17
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now