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.
Related
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
I am currently trying to install my vb6 app on a Windows 8.1 computer via TeamViewer (it's kind of like remote desktop). However, the installation always hangs up after all the files are copied and this message is displayed:
Setup is updating your system
We've tried it on our own Win8.1Pro desktop (via Remote Desktop this time) and Win2008Server(both via Remote Desktop), and it installed just fine.
Right now, we've narrowed it down to one culprit - MyProjectInfo.exe the actual ActiveX .exe. Whether it is me trying to run the .exe for the first time to register it to DCOMCNFG or whether it is the setup.exe running the script $(EXESelfRegister) it just freezes up.
What differences should i look for between 1) our win8.1Pro and win2008server and 2) their win8.1? If it some coding/reference/dependency issue, what could be the cause for why it doesn't error in our desktops?
Thank you for all the help.
Uhmm... this is getting embarrassing.
Avast (present in the other person's Win8.1) was blocking MyProjectInfo.exe from running (which is basically what is does with $(EXESelfRegister).
To properly proceed with registering my ActiveEXE program, I had to turn Avast off for a while. And that was that.
This problem may also occur with other anti-virus scanners as well.
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.
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 have a setup project created by Visual Studio 2005, and consists of both a C# .NET 2.0 project and C++ MFC project, and the C++ run time. It works properly when run from the main console, but when run over a Terminal Server session on a Windows XP target, the install fails in the following way -
When the Setup.exe is invoked, it immediately crashes before the first welcome screen is displayed. When invoked over a physical console, the setup runs normally.
I figured I could go back to a lab machine to debug, but it runs fine on a lab machine over Terminal Server.
I see other descriptions of setup problems over Terminal Server sessions, but I don't see a definite solution. Both machines have a nearly identical configuration except that the one that is failing also has the GoToMyPC Host installed.
Has anyone else seen these problems, and how can I troubleshoot this?
Thanks,
I had LOTS of issues with developing installers (and software in general) for terminal server. I hate that damn thing.
Anyway, VS Setup Projects are just .msi files, and run using the Windows installer framework.
This will drop a log file when it errors out, they're called MSIc183.LOG (swap the c183 for some random numbers and letters), and they go in your logged-in-user account's temp directory.
The easiest way to find that is to type %TEMP% into the windows explorer address bar - once you're there have a look for these log files, they might give you a clue.
Note - Under terminal server, sometimes the logs don't go directly into %TEMP%, but under numbered subdirectories. If you can't find any MSIXYZ.LOG files in there, look for directories called 1, 2, and so on, and look in those.
If you find a log file, but can't get any clues from it, post it here. I've looked at more than I care to thing about, so I may be able to help
Before installing, drop to a command prompt and type
CHANGE USER /INSTALL
Then install your software. Once the install has completed, drop back to the command prompt and type:
CHANGE USER /EXECUTE
Alternatively, don't start the installation by a double click but instead go to Add/Remove Programs and select "install software" from there.
Good luck!