Ageing 32 bit OCX control fails to load in .NET

Question

I am in the process of developing a .NET application which relies on an ageing OCX control. This control provides a terminal interface allowing user interaction to an airline booking system. It has already been used 'successfully' in several VB6 applications, but going forward we need/want to use it in .NET applications.

So on a Windows XP (x86) box using .NET 4 and Visual Studio 2010 I have created both Winforms and WPF applications which use the control which has been correctly registered. I have implemented Reg Free COM and using both XCOPY and Click-Once, both projects can be successfully deployed to Windows XP (x86) machines and both work as expected without having to register the control. Unfortunately the same cannot be said for deployment on Vista (x86) and Windows 7 (x64), where the app starts but no control is rendered.

In an attempt to understand the problem I have tried to register the control on my Windows 7 (x64) development environment. I have tried both:

• registering the control using the normal regsvr32 (x64 registry)
• registering the control placed in the SysWOW64 directory using the SysWOW64 version of regsvr32 (x86 registry)

In both cases the control appears to have registered successfully, and in a brand new Winforms project I can add the control to the toolbox (icons appears etc). However as soon as I drag the control to the form it appears as a tiny box in the corner of the form (rather than terminal window as seen on XP), even the Interop files are generated in the same way as per XP?!

The control as seen in XP

The control as seen in Windows 7 when selected

I have spent ages trawling the net for any kind of solution or similar problems to no avail. Any suggestions welcomed!

Update 1:

As suggested by @DanielHilgarth, I have created a basic application in VB6 using the control and run it on Windows 7 (x64) and annoyingly it picks up the registered COM component and works as expected even though the .NET application or project can be run alongside and no control is seen!?

Update 2

If I create a basic Winforms app on my XP box using the control (but requiring the control to be registered i.e. not reg free). When this is run on my Windows 7 (x64) machine, if will fail to start (as expected) without registering the control. It doesn't seem to matter to the app whether the control is registered in the x86/x64 registry either way it will start but no control is seen!?

Update 3

I have noticed that if I run a Winforms project (created in XP and COM reg free) on my Windows 7 environment that the form designer will fail unless the control registered (as expected) again doesn't seem to care which registry the component is registered. Once registered the form designer will be seen (with no control) and when build the following warnings are seen:

Researching this warning has been futile, it seems to indicate that Visual Studio is looking in the wrong registry path, but I cant find a way to resolve this?

Answer 1

Well it seems as though the problem was with DEP (Data Execution Prevention). I assume that the OCX is doing stuff that isn't allowed!?

Its still puzzling that there weren't any exceptions etc when running various test Windows applications, or anything when registering the control.

In order to rectify the situation I have editted the post build as per this blog. This now means I can debug and see the control and when published via ClickOnce the control is now seen on all OS's i.e. XP/Vista/Windows 7.

Unfortunately the control is still not seen at design time, however I can live with that!

Answer 2

I don't think I'm able to provide an answer to your question but perhaps I can give you some ideas for troubleshooting.

I'm just guessing but the source of your problem could be 32 bit registration issues on 64 bit Windows or perhaps permission problems because you are running using UAC. To troubleshoot the last part you can turn off UAC and see if that helps.

32 bit COM on 64 bit Windows

I sense a bit of confusion around 32 vs 64 bits. There is only a single registry on 64 bit Windwos. However, a COM component is either 32 bit or 64 bit. This means that there need to be separate area for 32 bit registrations in the 64 bit registry so the same registration can have two different implementations (the Wow6432Node).

Now the important part is that a 32 bit process will see a modified version of the registry without knowing about it. When a COM component registers a CLSID it uses the path HKCR\CLSID not knowing that it is mapped into HKCR\Wow6432Node\CLSID. On the other hand, if you want to inspect a 32 bit registration using 64 bit Regedit you need to look there. However, it is often easier to troubleshoot 32 bit registration problems on 64 bit using the 32 bit Regedit at %systemroot%\syswow64\regedit.exe where you see the registry as the 32 bit process sees it.

The control you want to use is a native 32 bit control and will not load or run in a 64 bit process. You write that you are "registering the control using the normal regsvr32 (x64 registry)" but that's not possible. You should make sure that both the control and all it's dependencies are registered correctly from a 32 bit perspective. If you look at the registration from a 64 bit perspective you need to fully understand how Windows remaps the registry for 32 bit (or just switch to the 32 bit Regedit).

You obviously want to use registration free COM but before attempting that you should perhaps try to see if you can solve your problem using "old school" registration.

Registration-Free COM

I would recommend reading the section Troubleshooting in the article Registration-Free Activation of COM Components: A Walkthrough:

When troubleshooting registration-free COM issues, the Event Viewer [...] is your friend