"Visual FoxPro 9.0 executable file has stopped working" 1

[Eylon]

Hi guys,
I am a user of a prepackaged software written in Visual FoxPro (working under Windows 8.1).
Whenever I run this software it crashes with "Visual FoxPro 9.0 executable file has stopped working".
Support personnel of the software vendor are clueless...

After browsing several FoxPro forums, I made sure the application's folder contains the 4 essential "runtimes" (actually gdiplus.dll was missing, so I copied it from the Windows\System32 folder).
However, the software would still not run.
Does anyone have a clue what am I missing?
I appreciate any comments or help.

 

[Scott24x7]

Maybe its a corrupt file (runtime .DLL)
Do you have a backup of the application that you can restore just the runtime files from?


Best Regards,
Scott
MSc ISM, MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

You should have a setup that installs the EXE with runtimes. Don't just copy around an installation folder of a software, that's not working very generally, not only for FoxPro based application.

If the gdiplus.dll is not in the working directory it's taken from syswow64, taking it from system32 means taking the 64bit version, that doesn't help.
Any way it is, copying a runtime directly into the application folder from a system directory where it's found any way won't make a difference.
If it would be the gdiplus.dll there was a hotfix once, as the gdpiplus.dll had a security issue.

You talk of 4 essential runtimes. Are you sure you didn't miss something else?

http://fox.wikis.com/wc.dll?Wiki~VFP9RuntimeFiles

Bye, Olaf.


Olaf Doschke Software Engineering

https://www.doschke.name

 

[Eylon]

Olaf, looking at the list at fox.wikis.com, I realize that I am missing actually 2 files which are on the “minimal set” list:
1. vfp9t.dll: which is nowhere to be seen
2. gdiplus.dll: which I “transplanted” from The System32 folder.

I should note that I do not have any control over the installation process, as the software maker provides an Installer, which is supposed to do all the work. Apparently some parts are missing from the installation process.
What can I do to get over this?

Scott24x7, I think the DLL is not corrupt because the software was able to install and run on an older machine.

Thank you.

 

[Olaf Doschke]

vfp9t.dll only is necessary for VFP DLLs having a COM Server, this isn't necessary for you.

gdiuplus.dll: Well, this should be in C:\Windows\syswow64. If a gdiplus.dll is missing from there you can't use the system32 dll, as that is a 64bit dll.

This dll should be the correct gdiplus.dll:

https://www.microsoft.com/en-us/download/details.aspx?id=8905

With a grain of doubt, as much time has passed since then and the normal Windows gdiplus.dll should have the security patch in it already and be usable with VPF9.

There might be something else missing like an OCX, and if your vendors' installer doesn't provide that, is there some dependency with MS Office, for example? Using office automation or Outlook automation.

Bye, Olaf.





Olaf Doschke Software Engineering

https://www.doschke.name

 

[Eylon]

I have copied the correct gdiplus.dll from the SysWOW64 but the symptom is unchanged. “..Executable file has stopped…”

In the application’s directory there are 5 OCX files
COMDLG32
Cttree
FlpGrf
Ctcalc
REPCDLG

All of them seems kind of antique as they are dated to the years 1998-2000.

I have no knowledge of any dependency with Office, though that might not indicate there isn’t one.
I guess the software should allow users to export stuff to Excel (or other office applications) but I am not sure this qualifies as “Dependency”.
I don’t think the software includes any Office automation modules.
Any ideas?

I would be happy to post here any error logs, if there are any. I found:

ERRORLOG.DBF
ERRORLOG.FPT

Are they of any use?!

 

[Olaf Doschke]

I don't think the errorlog.dbf is of use, as this "stopped working" message likely comes before the main code of the exe runs.
Are the OCXes registered? It's insufficient for OCXes to just be in the same folders to work.

What type is the installer, is it a cmd batch file or an executable or msi file? I get the impression it didn't run with eleveation and wasn't able to do all necessary setup steps.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Eylon]

You may be onto something, because the Vendor’s support also asked me once if the installation process had Administrator privileges.
I started the installer (more than once) with a right-click and then chose “Run as Administrator”. Maybe this was not enough?!

I had the impression the installer had to start other installation sub-processes (such as updating “Redistributable” stuff from Microsoft.com), but I am not sure these “Daughter-processes” or all installation stages inherited the elevated privileges I gave to the installer file.
Does any of this make sense?

The installer is an .exe file.
I have no idea about registration of the OCXs. How can I check that?

 

[Olaf Doschke]

It sounds like secondary setup processes started by the main setup don't run elvated. You might get this going, when you first start cmd.exe in adminstrator elevetion and run the setup from there.

Even if you run an EXE "as administrator" you get the elevation prompt dialog (or admin login, if your account is no admin). You get that elevation dialog, when starting the admin shell, too, but processes you start from it run elevated.

A setup will ask for elevation itself if its name contains the word setup or update. That's a mechanism which was introduced for compatibility reasons, the official way for an executable to ask for elevation is via an embedded manifest declaring the need for elevation.

From what year is the setup and what target OS was it created for? You can't expect things to run forever, that also applies to setups themselves.

Checking OCX registration: Hardly doable without knowing the OLE Classnames, but in short, you would need to find registry keys in the HKEY_CLASSES_ROOT branch. OCXes might also need some support libraries, DLLs, if that all isn't known this sounds like the vendor has lost some knowledge they once had, is the original developer still working there? Is this software so old, that it's not maintained anymore?

You can run old OCXEes like the MS common controls even in Win10, but you likely need an additional C++ runtime dll even older than that for VFP9, not instead but side by side.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[GriffMG]

Sounds to me like you might do better logging in as administrator, then running the installation program - that way you are already properly elevated and less likely to run into problems.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Olaf Doschke]

No Griff, not since Vista, the difference of starting processes as administrative user is that an elevation prompt only asks you to confirm running the process, while a normal user gets a login prompt.

But processes started by an elevated process still don't get elevated themselves and if they have no embedded manifest asking for such elevation will run with normal elevation and not be able to register OCXes, for example.

Since Vista, so since over 10 years the adminstrative accounts - even the one named "Adminsitrator" are not automatically creating all the processes they start elevated, this is part of the changes introduced with UAC in Vista.

That's also a reason it's not enough to have a setup starting further subsidiary setups.

It sometimes can work to change UAC to the lowest level and then back, but changing UAC levels can also mean access to system folders and registry is not redirected at installations and later is again redirected, also rendering the installation result useless.

What you can try is look into the porerties of the main setup and change compatibility mode of it to XP and then start the main setup "as administrator".

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Eylon]

I did as Olaf suggested.
I looked up “cmd” in the windows search box and then right click “cmd.exe” from the list and “Run as Administrator”.
In the console windows that opened up I typed in the name of the Installer file, and let it do its thing.
Then I ran the software, but the same old messages appeared, i.e: "Visual FoxPro 9.0 executable file has stopped working".

I did notice however, that the installer did not perform any sub-processes like last time.
Perhaps because the Installer recognized that they were not needed, as I already performed these steps before.
A clue to what these sub-processes may be is found on the vendor website:
“When installing Stock Investor Pro, you may be prompted to install additional support files. These files are for Microsoft Visual C++ and Microsoft .NET Framework. These are legitimate files from Microsoft that you need on your PC in order for the automatic updates to function properly. If you are prompted, click Install to download and install these files.”

“Stock Investor Pro” is the software name.

As I said in an earlier post, these steps were initiated on previous installations but I do not know whether they were successful, or if they needed elevated privileges.

The Installer file is dated September 30, 2018.

According to the software vendor System Requirements are “Windows 8 or newer” (my computer meets the requirements).

Any comments would be very much appreciated.

 

[Olaf Doschke]

First of all this software package then seems quite current. Usually a VFP application doesn't need any .NET framework unless it uses some assemblies, or the installer is made as a ClickOnce .NET installer as described in this article:

https://www.codemag.com/article/0703072/Welcome-to-the-Future-of-Deployment

FYI: Reading all this won't help you, I just point out a scenario where the installer itself would perhaps load a .NET framework just because the installing process needs it. It likely wasn't needing this on Win8, as the .NET framework already was there to run the ClickOnce installer. In very short, if that was configured wrong this could be a reason the installer worked on previous OSes and stopped working on Win10, i.e. the installer ran on Win8/Win8.1 as the prerequisites were already there and it fails in Win10 loading the wrong prerequisites.

Notice "Or later" always is a hopeful statement relying on Microsft designing their OS downward compatible and usually that's the case.

Another thing you could try is to run a VFP specific runtime installer from

https://github.com/VFPX/VFPRuntimeInstallers.

The vfp9sp2rt.exe is for VFP9 SP2.

Also, whether that works or not, you should really get back to the vendor and tell them their package doesn't install on Win10 and they need to repackage that. If running vfp9sp2rt.exe helps that's a big hint on their installer causing the wrong C++ runtime to load, I can't assume they embedded the wrong VFP9 runtime itself, but only succeeded on Win8 for the reason the right C++ runtime version already is present with the OS or Office and other software on Win8, but not in Win10.

If the VFP9 (and C++) installer doesn't work, I'm out of ideas what's causing that problem. The vendor of Stock Investor should have the installer project and be able to adapt it to Win10 as necessary. Might not even be their fault but anything incompatible Microsoft introduced with Win10, that causes ClickOnce installers to need an update to work in that OS version, too.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Tore Bleken]

May I ask into which folder you have installed your program? Since only installer programs can write to C:\Program* folders, your VFP application can't write to these folders. This wasn't a problem with earlier Windows versions. With newer Windows versions you can install the program in c:\Program.. folders, but all the user data, including configuration files managed by VFP, must be in another folder.

 

[Eylon]

Thank you Olaf and Tore for your comments.

Olaf-
I went on and downloaded vfp9sp2rt.exe from GitHub and started installing. While I was going about this, this Installer asked me where do I want the files copied to. The Installer’s default was “C:\Program Files (x86)\Common Files\Microsoft Shared\VFP\”.
I wanted to be sure about this, so I halted the installation and checked if this folder exists at all. I found out there’s no such folder on my machine.
Does this mean anything?
Could it be that these files already exist on my machine in some other location?
(Had I known the file names to be extracted, I would have done a search without bothering about this).

Tore-
The software installed itself on “C:\Program Files (x86)\Stock Investor\Professional”.
I am not 100% certain, but I think that the software writes user-specific info (or at least is designed to do so) in:
“C:\Program Files (x86)\Stock Investor\Professional\User”
I think there was no problem with that on older machines of mine running Windows 7 or lower.

 

[Tore Bleken]

The folder “C:\Program Files (x86)\Stock Investor\Professional\User” (and all other folders in "C:\Program Files") are read-only except for installers. This is why you must always either install "as administrator" or the installer asks for permission to elevate to administrator level.

Try to install in another folder outside the c:\program* structure.

 

[Olaf Doschke]

The files don't need to be installed there, and indeed the best place is where the application is installed. But this installer registers this version of the runtime for every VFP9 SP2 application and in such a case that folder will be created and is the default path.

I already said what will be installed, just like the name of this setup tells you, it's the runtimes, I expect this to fix mainly the correct C++ runtime to be installed for your software to run.

So please just install there. Don't think too much about this and if you don't trust me, then why did you come here at all? Also, if you're asked with a default, that normally means you have free choice and the default is no bad idea.

Tore might have a good idea, but I don't see how insufficient write access into the program file folder would lead to your error, and as you tell the software is made for Win8 or later that would also have been a problem on Win8. But since Vista, the OS redirects writes (and reads) into read-only system folders like program files to a user profile folder, but that doesn't cause it not to work. Having the wrong C runtime could easily cause that Letting the EXE code jump to a wrong address in the C runtime DLL.

If that still doesn't work, the only other reason I can think of is having a bad setup download. The whole setup has corrupt files, maybe the application EXE or any DLL in it doesn't work.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Koen Piller]

Eylon,
your software was running smoothly before?
Have you now reinstalled on an other pc?
Did you check with the vendor under which version of VFP this software was constructed? And are you sure this is VFP9 or VFP9SP2?
Are you sure the runtimes tally with the version of your software?
Regards,
Koen

 

[Eylon]

I ran and vfp9sp2rt.exe and installed the runtimes to the default directory.
Then ran the software and got again the message “Executable has stopped”.
At this point I started fiddling with stuff that came with software, and ran an “Update Utility” that is part of it.
To my knowledge, this should have only updated the database and not the code.
Anyway, the Update Utility tried to perform something but crashed with a FoxPro message: “Fatal error 171 while attempting to report error 171”.

That’s where things stand at the moment.
Any thoughts about this?

Koen- The software ran smoothly on older machines of mine running Win 7.
I checked with the vendor: Support says the software was constructed under VFP9SP2.

 

[Olaf Doschke]

OK, the last shot on this: As you now installed VFP runtimes into the default directory given by the runtime installer, please delete them from the application installation directory C:\Program Files (x86)\Stock Investor\Professional. Especially delete the DLLs which now have their place in C:\Program Files (x86)\Common Files\Microsoft Shared\VFP\ so VFP really takes those and not any local ones, of which I assume some are broken. You may start only deleting the msvcrt71.dll within C:\Program Files (x86)\Stock Investor\Professional or C:\Program Files (x86)\Stock Investor\, but since the runtime installer registers the VFP dlls this'll let the Stock Investor exe find them, if there is no such dll in the software folder.

You may also compare the DLLs, do you see any differences?

Again for clarity as I was ambiguous previously: Keep the DLLs where the vfp9sp2rt.exe installed them, delete them from within C:\Program Files (x86)\Stock Investor\Professional or C:\Program Files (x86)\Stock Investor\ Even if there is no difference, the ones vfp9sp2rt.exe installed are also registered and I know this setup has the correct VFP and C++ runtime DLLs, too.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name