I have a vb6 application that runs fine when double clicking the .exe. When I right click the .exe and select 'run as administrator' (on a Windows 7 machine), I get an error: "Run-time error 429. ActiveX component cant create object"
What dll/com is missing?
This seems pretty clear.
One or more DLLs and OCXs you are using was not properly installed and registered. Most likely some of them have been virtualized, either in the filesystem and/or the registry. They can only be seen by that one user when running under its standard-user context because the admin context doesn't have virtualization applied. Log on as a second user and you'll see the same failure.
Installation needs to run under TrustedInstaller, or at least elevated. That's the only way libraries can be placed and registered globally as they need to be.
Have the same problem and in my case I solved in this way:
reference global system DLLs only from C:\Windows\SysWOW64 (ex. msxml6.dll)
run VB6 IDE as Administrator and compile your program
Related
I have a VB6 application I am trying to get working on a Windows 7 environment, however every time I start the application, I get the error:
"Component 'ComCt332.ocx' or one of its dependencies not correctly registered: a file is missing or invalid".
To resolve, I have tried to register the comct332.ocx file by running the regsvr32 in the Command Prompt in Administrator Mode but then I get the error:
"The module "comct332.ocx" was loaded but the call to DllRegisterServer failed with error code 0x80004005"
Other things I have tried include:
Deleting all parent nodes in the registry where 'comct332.ocx' exists
and running regsvr32 again in Admin Mode. Same result.
I granted admin permission to another user on the PC and I could register the
file successfully, and the application starts and runs successfully!
However when I log in as the previous user again, it fails miserably.
Any help, thoughts, other-things-to-try will be much appreicated. Thanks
If you have been keeping up on things as you must if you are to continue using VB6 successfully there are a number of things you'll be aware of.
One of these is the impact of UAC and per-user registry
virtualization.
Another is the impact of SysWOW registry redirection on 64-bit
systems.
You will understand that proper installation packages are more important than ever before. Windows has many auto-remediations for legacy software but some of them will not result in applications having all of the originally intended behaviors. Most of them will only be applied when your application "follows the right path" from installation to second run.
Here we have a case that is intended to be handled through use of a proper Windows Installer package, or at least a legacy setup recognized as such through Windows' "legacy installer detection heuristics." In general legacy scripted setups are deprecated but as long as they stay on the path Windows makes efforts to ensure they succeed.
Manually deploying by just copying over a bunch of files and randomly running regsvr32 on some of them has a reduced chance of success. This was never an approved method of deployment anyway.
You have most likely run afoul of some combination of registry virtualization and redirection.
The regsvr32 utility is a development tool, not a deployment tool. If you insist on trying to use it for deployment you must follow the same rules a developer must follow:
Run the correct version. On a 64-bit system there are both 64- and
32-bit versions of this utility. The 32-bit version which you must
use is located in the SysWOW64 folder.
Run it from an elevated command prompt. An easy
way to start one is to type <Winkey>cmd.exe<Ctrl-Shift-Enter> then
approve the UAC prompt or provide over-the-shoulder admin credentials
as needed.
There are many other things you need to know and handle in order to be successful. If you have ignored those most of them will only become apparent to you after your program gets installed and will run. A lot of them stem from filesystem virtualization.
Have a lot of older VB6 apps running at work and starting to bring in Win7 machine.
I run one and find an error of OCX registration along the lines of ...ocx is not registered.
RegSvr32 \\Uhsfp1\UserPrograms\sharedcomponents\UHSLineItems.ocx
and no errors when run as an admin from cmd prompt.
I run the app again and I read an error:
An error was encountered granting
access to certain features in this
application. ActiveX component can't
create object.
Really don't want users to see that.
Any ideas?
TIA
Is it a 64-bit machine? Try registering with C:\Windows\SYSWOW64\regsvr32.exe instead of the default which would be C:\Windows\System32\regsvr32.exe. The former is the 32-bit version which should make your components available to other 32-bit programs.
Try unregistering the OCX and then registering it again.
You need to make sure that the command prompt (or calling process) is running elevated in order for regsvr32 to succeed on Windows 7
I have made an application that copy the vb components to the system32 folder of the windows and register those components with “regsvr32”. It works well in Window XP, but in Windows Vista and Windows7 it can’t perform its task without right clicking the application .exe file and selecting “Run as administrator”. Is there any code in vb that automatically allows the application .exe file to run as administrator?
To do precisely what you ask you can add an application manifest that specifies an execution level of "requireAdministrator" within it. However this means the application will always run elevated, and the user will also have to provide admin credentials or approve elevated execution for every run (UAC prompt).
Please just do things the right way.
I'm going to second Bob's excellent comment above and suggest that you use a tool like Inno Setup http://www.jrsoftware.org (it's free) to build a proper installer. One of the benefits of using a proper setup tool is that the setup application can request to the OS to run with administrative privileges without using external files and manifests to make that happen. The setup.exe that you build will have the necessary code built in to ask the OS for elevated privilege.
In windows 7, we can go to the properties of the file or an application exe file and then "Compatibility" tab. Then check the "Run this program as an administrator".
It will force the application to be executed under the administrator privilege.
I used this and my problem was solved.
I have a VB6 app that formerly worked perfectly on a Vista machine as a scheduled task, but it will no longer open on the same machine. The app generates export files in a specified folder with no direct output on the screen. I get no errors, no missing references, just absolutely nothing.
The machine is running Vista Business 32-bit, UAC is disabled with a single administrator account, and automatic updates are turned off. The app resides in a non-protected folder, and the export files are put in a folder on the desktop. The client swears that the only change they made to that computer since I installed this app was installing Norton Antivirus, which has never caused problems before with our software.
In addition to the normal VB6 references, the app references Microsoft Scripting Runtime (scrrun.dll), and Microsoft DAO 3.6 (dao360.dll). Both of these files are present and registered on the target machine, along with all the other VB6 dependencies. I added MsgBox statements at the beginning of Sub Main() just to see if anything is being executed, and its not. Disabling Norton yielded no results, nor did reinstalling VB6 runtime to rule out any corrupted libraries. Not once did I get any messages, error or otherwise from my app.
I've never had an issue like this before and I'm completely stumped. Is there anything else that could be causing this?
Edit - The app does not run even when I run it manually, so the part about it being a scheduled task is irrelevant to my problem, sorry for including it.
The user has full administrator credentials, no compatibility mode was needed on the initial test which at the time, was done on this very machine I am having the problem on. For grins I tried compatibility mode for XP and 2000, still nothing.
Try to inspect - if you can access them - the Event Viewer messages. Maybe you will find some tell-tell signs in there...
You could try running the program in Windbg, a free standalone debugger from Microsoft. Compile your VB6 EXE into native code with symbols (create PDB files) and you will be able to debug your application in Windbg.
I would guess one of two things will happen.
Windbg will fail to load the EXE. Presumably with an error message that will identify your problem.
Windbg will load the EXE, and you can single-step through to see what happens.
Here's a 2006 blog post by a Microsoft guy about using Windbg with VB6, and 2004 blog post by another Microsoft VB guy with a brief introduction to Windbg.
Has the user changed their password? That will cause the scheduled task to fail until they re-enter the password on the task.
Have you tried running the process directly, instead of as a scheduled task? I'm far from an expert, but it may be that any errors being generated are not showing up because the program is running as a task.
I am trying to build a windows service that includes a Lua component, and links with Lua's shared libraries. I am building the code in Eclipse/CDT with MinGW. It builds fine, but when I run it, I get "Application failed to Initialize Properly (0x80000003). Click OK to terminate".
I am looking for clues as to what might be going on. A Hello World program compiles and runs fine, so there are no basic environment issues (I hope!). BTW, I am running on XP Home.
Update:
OK, I have figured out, by some guesswork, what was going on, and thought I'd post this for the benefit of others who might run into a similar problem - I think the lua DLL I was linking to, at runtime, was a different version than the one I built with. This caused the app initialization to fail I guess. When I made them to be the same file, things started working. I have not looked into why this would cause app init to fail, but I guess some symbol being at a different address or something? Or could it be that the DLLs were built with different tool chains?
This might be caused by not having permissions to access the DLLs required by the application. Are you logged in as an Administrator or member of the Administrator group?
Try logging in as Administrator to see if the problem goes away. This will help determine if it's a permissions issue, and then you can explore that further.
You could also try using the Dependency Walker (depends.exe) to see if this highlights any problems.
Cause of this problem is to try to run DOS programs, or 16-bit programs in Windows XP
To run DOS programs, or 16-bit environment in windows xp
To do so go to Start , Run and type gpedit.msc
And there go to:
User Configuration
Administrative Templates
Start Menu and Taskbar
And double-click on
Add "Run in Separate Memory Space" check box to Run dialog box
Select Enabled and then OK.
If the problem is not resolved, we will have to disable the Dr Watson , Do the following:
Go to the Start
Programs
Accessories
System Tools
System Information
Then go to:
Tools
Dr Watson
Or go to Start , Run and type drwtsn32
And disable:
Dump All Thread Contexts
And
Create Crash Dump File
And press:
OK
And then restart your computer .......
And then you will be able to run any game or program is running Dos or 16-bit, within Windows xp.