PDFCreator and VB6 on 64-bit: ActiveX component can't create object - vb6

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.

Related

Vb6 component on Windows 2003 R2 won't register

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.

VC++ app fails to start — but there's no error

I made a minor change to a legacy Visual C++ / MFC app built with VS 2008. I changed some UI resources in the .rc file and compiled without any problems, then deployed it on my client's system. However, the program which was previously doing fine now fails to run on exactly one of their servers. It works fine on my laptop and on their other servers, many of whom are basically identical to the one having the trouble.
The weird thing however is that there is absolutely no error message whatsoever. No message box, no errorlevel set (when run on command prompt), no Dr. Watson entry, no nothing.
It's an MFC app that does not really comprise anything very special. It does link in some external libraries – e.g., some old version of the Xerces C++ XML parser. But this is probably not too relevant, right?
The program has a class derived from CWinApp, and I tried to add some logging in its constructor. Based on this, it looks like not even this constructor is reached.
The server in question is running Windows Server 2003 Standard Edition Service Pack 2, and we are trying to run the program in a Remote Desktop session. (Because of the client's environment, I cannot easily test in a console session right now.)
I reverted my changes from version control, which did not help – but I do not know if I had built myself the previously installed version (which ran just fine even on this server) or if it had been built by someone else.
Have also tried to reinstall the Visual C++ runtime libraries and of course reboot Windows, but neither helped. Now I'm really running out of ideas... Any clues on what I could try or check?
Probably some error occurs but is surpressed e.g. empty catch() statement or similar.
You could try and install Debugging tools for Windows WinDbg to see if you could get more info when trying to run it. Since the download is rather small 25Mb maybe it is possible to install it on your client's PC.
But first check the eventview log for your app, maybe there is something in there that can shed some light.

Unable to load VB6 OCX in Windows 7 Error 372

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.

VB6 + componentone developed application in Windows7

This is trouble shooting question.
Our application's development environment is VS2005 C/C++, VB6 based GUI.
we use also componentone for ActiveX control(vsflexgrid8).
application performed well in Windows XP, but in Windows 7, there is some problem in GUI.
rebuilded almost all C/C++ code and VB6 code in Windows 7
our build system is so poor and because I joined this team a month ago, building all codes are a bit hard
But this (maybe) last problem is not related to build, I think.
all other processes and GUI process are start well. but when click some menu in GUI, all user controls become invalid.
error message seems like this:
'-2147417848 (80010108)' occured
runtime error.
Automation error.
Invoked Object disconnected from
client.
above message is not identical to real message since real message is our native language(Korean).
when googling with this message, I'm able to gather some informations.
the most possible case is when using OLE Automation for Microsoft Office Objects.
But our GUI(VB6 developed) does not use Microsoft Office Objects.
And problem-causing page/control's are commonly use componentone modules.
So, if experienced similar problems, please help me.
In Virtual Machine Windows XP mode, there is no problem. But I'm strongly willing to develop in this environment.
Thank you for your help.
'Automation Error' just means that an error was raised from within the ActviveX control, but that the developpers did not add a description to it. So the cause could be anything.
A common source for this kind of errors are write errors to protected folder (The Program Files folder for instance) or forbidden Registry Read/Write actions. You could try installing the program to another location or to run it elevated.
Hope this helps at least a little.
As Dabbler says, this means there has been an error in the ActiveX component.
Does any of your C or C++ code run before this error happens?
Are you using the latest version of the ComponentOne control? Perhaps it's worth checking whether it is supported on Windows 7, and contacting their technical support?
You could debug the VB6 and C/C++ on Windows 7 to track down which bit of code triggers this problem. This is possible with Visual Studio 2005, which you say you have, or WinDbg which is free.
I solved this problem by Windows Updates.
Since about 20~30 updates are performed at once, I can't know what update solves this.
I guess Visual Studio 2005 security updates may the reason for this trouble.
Anyway, my application runs well in my Windows 7 machine.
Thanks to All.

VB6 application requiring comdlg32.ocx, running on windows server 2008

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

Resources