I'm trying to deploy some Vb6 components on a Windows Server 2003 Standard x64 R2. I normally run these in a com+ application and I went through the normal routine of creating the COM+ application and adding all the components. Everything seemed to work fine until I actually tried to use any of the components. I would some kind of "ActiveX component can't create object" or "Application-defined or object-defined error" or something similar to that.
To remove as many variables a possible I created a very simple VB form to consume the simpliest of the components and tried that. Nope. So I created a simple install to install the component, and whooo hoooo it worked. So I tried one of the more envolved components with high hopes ... but no after the install I still can't call the component successfully. Using Dependency Walker I discovered that for some reason the msvbvm60.dll is not properly registerd.
I've downloaded VBRUN60.exe and VBRUN60SP6.exe and tried installing them. Even going so far as to do a run as with the administrator account and removing the check box for "Run this program with restricted access". I've tried to manually register the msvbvm60.dll in the SysWow64 directory.
Nothing seems to work. It just won't register. Does anybody have any suggestions? At this point I'll try just about anything.
Thanks
If you are registering the components manually you need to pay extra attention. As you are on a 64-bit OS there are two versions of regsvr32.exe. When registering VB6 components you must make sure to use the 32-bit version of regsvr32, which is located under the following location:
%WINDIR%\SysWOW64\regsvr32.exe
If you just type regsvr32 on the command prompt, normally the 64-bit version is chosen (because %WINDIR%\system32 is contained in the %PATH% environment variable), so please make sure to use the full path as above.
If you are using a 32-bit MSI to install your components, this version will be selected automatically and the registration should work just fine.
In case you haven't already done, you should give a try to Process Monitor - one of the best tools I have used on dll registering problems.
The following links will provide some usufull clues:
An excelent tutorial on using Process Monitor for problem solving;
ActiveX component can't create an object
RESOLVED! ActiveX Component Can't Create Object: Cube build failure against SQL Server 2005 Analysis Services
Hope it helps :D
I've had trouble with unregistered components for Visual Basic 6 - although not tried to use the same one as you are mentioning. Manually registering never resolved things, no matter which reg server was used
The problem (eventually) turns out to be Internet Explorer 10. Uninstalling that (due to the way Windows 7 handles IE as Windows updates, this meant unistalling newer versions first to expose the older ones) worked. Afterwards, reinstalling the latest IE brings no problem.
Related
I'm using PDFCreator to create PDFs in VB6. My VB6 development VM is Windows XP 32-bit. On that system PDF generation works both from a desktop app and from ASP (via VB web class runtime).
When I create an exe to run on Windows 7 or Windows Server 2008 R2 or use it in the web class runtime I get:
Run-time error '429':
ActiveX component can't create object
This is when using early binding. I add a project reference to "C:\Program Files\PDFCreator\PDFCreator.exe" and then in my code I do:
Public WithEvents mPDFCreator As PDFCreator.clsPDFCreator
Set mPDFCreator = New PDFCreator.clsPDFCreator
If I don't use a project references and use late binding instead, then it works on the desktop app but still not in the web class runtime. Late binding is done like so:
Set mPDFCreator = CreateObject("PDFCreator.clsPDFCreator")
I want to use early binding so that I can use the events, plus I need it to work in ASP/Web Class Runtime.
I realise I'm dealing with ancient technologies here and I should have tempered expectations when running such things on modern 64-bit Windows and IIS. If porting this legacy app to .NET were an option, I would.
On IIS I have set the Enable 32-bit Applications setting on my app pool. I have also tried running it as Administrator to rule-out security problems.
I've done everything I know how to debug this, but I'm stumped. I suspect it has something to do with PDFCreator being a 32-bit app and COM registration. I've also tried running regsvr32 out of SYSWOW64 but PDFCreator.exe can't be registered.
Windows 64-bit architecture does not allow the load of 32-bit dll into 64-bit processes.
But you can modify the configuration of your vb project to convert it from an in-process dll COM component into an out-of-process exe COM server. This will allow you to instantiate your 32-bit component from a 64-bit process.
See Process Interoperability
Since this is a VB6 question there aren't any 64-bit processes to worry about.
It seems far more likely than anything else that this library just isn't being registered properly. I haven't use it since I don't know whether its setup works properly. I do know that the download itself does not display with a UAC Shield on its icon, suspicious in itself. For all I know the setup program spawns a run of the wrong regsvr32.exe.
But it seems more likely you have misregistered the library manually after copying it naked over to these 64-bit Win7/Server 2008 systems.
In any case, going over all of the symptoms you describe, I'd guess it got registered as a 32-bit ActiveX library but registered in the per-user virtualized part of the registry for the user you were logged on as when you registered it.
This can be a hassle to clean up after. However you should, and then be sure to manually run the original setup once again with elevation.
These threads that include hand-wringing over "ancient technologies" really get old. It's a poor workman who blames his tools. In the future why not hire an experienced programmer to handle tasks like this?
I use PDFCreator in my accounting software written in VB6. Years ago, I noticed that after a certain update from the makers of PDFCreator, my software stopped working properly with it. The problem stopped after I re-installed the older version, and came back when yet another new update was released from them, so I have had my customers freeze at the version that worked. I don't know off the top of my head what version that was, but I can check my own web site since I made it downloadable for my customers if it would help, but it's likely many years old now.
I'm working on an application developed for Windows XP SP3, using VB6. I'm currently in the process of getting it to work on Windows 7, but am encountering a problem with one of our custom OCX files.
When attempting to load a form that contains an instance of the control contained in the problem OCX, the following error is produced:
Failed to load control 'x' from y.ocx. Your version of y.ocx may be outdated. Make sure you are using the version of the control that was provided with your application.
I've checked the version numbers and they're all correct and referencing the proper version. The OCX registers fine, and all the expected registry entries are present.
Inspection with DependencyWalker shows no missing dependencies.
The software works fine under XP, and this is (seemingly) the only issue when running on Windows 7.
Interestingly, if I run through the VB6 IDE using a VB6 group (with the offending OCX part of the group, and the application the startup project), I don't have the issue. Running the application on it's own through the IDE still presents the error.
Any ideas on what could be missing which would cause the application to throw this error?
Error occurs on both Windows 7 Professional and Home Professional, both 32 bit.
This is almost certainly an interface compatibility problem. COM interfaces are versioned entirely separately from your Major/Minor/Revision numbers, which are little more than comments except as used by Installer.
Somewhere along the line you broke binary compatibility, and you are trying to deploy a library with a newer interface than your application was compiled against.
These version numbers are found in keys such as:
HKEY_CLASSES_ROOT\CLSID\{class Id GUID}\VERSION
Your program needs to have its old reference to the OCX removed, a new one set, and then it must be recompiled. This also means deleting any instances of the control and adding them back one by one.
I doubt this is a Windows 7 issue.
I would suspect this is a UAC problem. Try turning UAC off to see if that solves the immediate issue. If it does then you have to regsiter everything using 'run as administrator' and/or create a manifest for you application.
Sounds like on of the controls included in your OCX is having issues loading, not a general registration error. Look at the constructors for x control, and see if they are doing anything that disagrees with UAC or such. One way you can debug this is put some kind of a break before the control is initialized, and debug the application from Visual Studio (remember to create the PDB's in VB6), and then carry on from the break to see why the control isn't initializing.
I'm adding some functionality to an old admin tool written in VB6. The tool uses a c++ activeX object. I haven't worked on the tool since I upgraded to windows 7 and now the active X object fails to load with the 429 "ActiveX component can't create object" error. I'm not knowledgeable about VB6 but I have registered the activex dll and type library and I can remove and add the object from the project via the project->references window (the program fails to compile when the reference is removed as expected). The VB6 ide is running in administrator mode and I get the same error if I run the exe directly as an administrator.
Has anyone else experienced a similar problem and found a way to sort it out?
Thanks,
Patrick
PS : I have also tried putting the dll in question in the working directory of the exe
EDIT: I've had no luck trying to sort this out and ended up remoting into a windows 2003 server to test the changes.
You might try using Mark Russinovich's regMon and FileMon to see exactly what files or regkeys are being requested during the load of that dll. That can often tell you if you've got a missing dependency.
Also the DEPENDS.EXE that comes with VS6 is sometimes good for that (though it doesn't necessarily get ALL the dependencies of a dll or exe).
COM is going to use the registry to map from the class name to the physical DLL file that has to be loaded.
Check the registry keys pertaining to your COM object... first under HKEY_CLASSES_ROOT, then the class name, which gets you the CLSID, then the HKEY_CLASSES_ROOT/CLSID section for the GUID of the object, and then see where the physical library lives.
A 429 could mean all sorts of different things. Many times, it means that there's a dependency missing, and the easiest way to figure out what dependency is missing is to use procmon to see what files/registry settings the app is trying to access and hopefully, catch where you get ACCESS_DENIED or FILE_NOT_FOUND or what have you.
The problem might also be with your browser. A couple weeks ago I upgraded my IE, since then I've had to make changes by opening IE, click tools, click custom, scroll to the activeX controls and enable, and/or click prompt. The same was needed for scripting and for me to use XMLHttprequest. Now everything is back to working, however the ActiveX warning alert sometimes takes over 2 minutes to pop-up, then when clicked everything works fine.
Do you have UAC enabled on that machine? Have you tried disabling it? I have seen some cases where it let ActiveX controls being registered but didn't let applications using them ran.
I have a VB6 Service that uses the standard NTSVC.ocx file to help manage all the NT service functions. The application has been running on Windows 2003 Server RC1 with no troubles. Our sales team asked if we could put this same application on a notebook that could be used as a live site demo. The only issue I am having is that the notebook is brand new, running Windows 7 and the manufacturer only has Windows 7 drivers for the devices.
There is no installer for this service. I manually load the ocx and supporting other dll's into the various Windows and System32 folder and then run regsvr32 from the command prompt to load the OCX. The service has a command line set of parameters to install and uninstall the service itself.
When I try to REGSVR32 the OCX I get the following error:
The module "C:\Windows\System32\ntsvc.ocx" failed to load. Make sure the binary is stored at the specified path or debug to check for problems with the binary or dependent .DLL files. The specified module could not be found.
One potential reason that might lead to your problem, is that the NTSVC.OCX is built with a fixed Base Address (in other words, the Image has been bound by the Linker with the /FIXED switch). Starting with Vista, the Windows Loader uses Address Space Layour Randomization (ASLR) mechanism.
Based on this ASLR feature the Windows Loader attempts to load the OCX component at another Base Address than the predefined one (the one hardcoded in the OCX image file). Since your OCX Address Base is hardcoded, the Loader will fail to load your OCX (which is technically just a DLL!).
See Snapshot below showing these fields of the NTSVC.OCX image using PeStudio:
I would first try Dependency walker. If that doesn't give you a clue as to what you need you may be SOL. Also you will have to run regsvr32 as an administrator so you should get the little UAC popup.
this ocx (an also other ocx such as vbwheelscollfix.dll) to register ist very easy.
First Step:
copy this OCX into the Folder C:\Windows\SYSWOW64 (on 32 bit, i suspect its SYSWOW32).
Second Step:
Open a CMD with administrative rights.
Last Step:
Now you can register / unregister the file from the SYSWOW path.
As ich said:
in an administrative shell:
regsvr32 C:\Windows\SYSWOW64\NTSVC.ocx did work for me. Note that \System32 did not work, as it gave me an error. It might work in a x86 environment, though.
I now have no errors in my project but did not try if it works properly.
I have a legacy vb6 application that needs to run on a server 2008 machine.
I have been unable to get comdlg32.ocx to register, which the application depends on. Any suggestions?
Hmm, does this link help you at all?
My only other suggestion is that often dependency walker is useful in these sorts of situations, in particular if you are running this vb6 application on a 64 bit OS then pay attention to whether or not comdlg32.ocx has all of its dependencies present as 32 bit libraries.
The obvious, but are you running Regsvr32 as an Admin?
If you do not want to bother about copying and registering the comdlg32.ocx file (for which you might need administrator rights anyway), check out following project, that shows how you can use the common dialog box (open and save) without using the ocx file and thus without need of registering it. It uses the comdlg32.dll directly with APIs, which is installed already on windows!
http://www.soft-hummingbird.com/Tutorial_VB_ComdlgAPI.php?lang=en
The File Backupper is a nice peace of software, that uses exactly this:
http://www.soft-hummingbird.com/File_Backupper.php?lang=en