Can't debug ActiveX project after switch to Win 7

Originally posted in COM and ActiveX forum...

Thanks to this author I am running VB 6.0 on Windows 7 after my XP laptop's SSD failed. I can run ActiveX projects in VB 6.0 and call them from Microsoft Access VBA. http://www.fortypoundhead.com/showco...sp?artid=20502

However with one large project I can successfully call the compiled dll but when I run the project in VB, and reference it instead, I get a 429 error "ActiveX component can't create object" when I [Set obj = New ...]. The VB 6.0 project is set to Binary Compatibility with an earlier version of itself. If I change this to No Compatibility, Run it, and re-reference in Access, then I can call its methods without any problems.

This project is released as the Server part of a Client/Server pair. If I load them as a project group and reference the Client dll instead then I can call into the Client and the VB 6.0 debugger will flow from there into the Server! The Server implements many interfaces unknown to the Client though so that's not a satisfactory debugging strategy.

I have uninstalled and reinstalled the dll, tried running with and without UAC and running VB 6.0 and Access as Administrator, all to no effect. Releasing a new version of this (mission critical) project just so that I can run it in debug will require a major distribution effort that I'd prefer to solve if possible. I'm out of ideas. There is a little more detail at the bottom of the comments section on the above link.

Complus reports this error in the Windows Application log when running in VB but the component runs fine as a dll:
The system has called a custom component and that component has failed and generated an exception. This indicates a problem with the custom component. Notify the developer of this component that a failure has occurred and provide them with the information below.
Server Application ID: {57190151-39FE-49CB-B767-FFC3A3FAD7F2}
Server Application Instance ID:
{080B704D-0E9D-4F5A-91DF-B05AF6877E71}
Server Application Name: ABSvr30
The serious nature of this error has caused the process to terminate.
Exception: C00000FD
Address: 0x6A94682C

Has anyone faced this issue before?

It looks like you have broken binary compatibility (not a good thing, but sometimes you get backed into a corner). This in itself shouldn't be a problem if you can set a new reference in your client (some MS Access VBA script from the sound of it). However it should never happen spontaneously, and may be a hint that you broke something by carelessly falling on your keyboard while the IDE was open or something.

The funky part is why COM+ has its nose in there any place at all.

Is this a DCOM server ("ActiveX EXE") or something? Saying something like "ActiveX project" is pretty imprecise. Every VB6 project is an "ActiveX" project by nature.

I'll assume it is.

You need to clean up a mess in the DCOM configuration. While you'll be able to see the problem via the Component Services console (press the WinKey, enter DCOMCNFG, press Enter) you can't fix it from there.

As http://www.west-wind.com/webconnecti..._0421e7cqu.htm says:

Quote:

---

Cleaning up the registry and DCOMCNFG
If you do end up with multiple servers having been registered you can end up with multiple DCOMCNFG entries for the same server. The real server will always show as a Local Server and will have 4 or 5 (in Win2000) tabs of information available including the first page that contains the path to the server. All invalid references will show as Remote Servers. You have to clean up these entries in the registry and do so manually. Start by unregistering the server with <yourexe> /unregserver. Then go into RegEdit and find all reference to your ProgId and then clean up each of the subtrees that they are associated with by deleting them out of the registry. There will likely be a lot of references to be deleted (at least 4 per entry in DCOMCNFG). When you're done, go into DCOMCNFG and make sure the server listing is gone. Once that's done, recompile the project or re-register the server and make sure you always compile the same project for the final file that goes on the server. It's a hassle, but unfortunately that's how COM works.

---

Thanks to all who gave some thought to this issue.

It turns out that the solution involved running both VB 6.0 and Microsoft Access As Administrator. It's possible that deleting a COM+ version of the application also installed on the box contributed to the solution as well but I can't say for sure.

In any case, I am delighted to now be able to debug VB 6.0 apps from Microsoft Access on my Windows 7 64 bit machine.