"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.

 

[Eylon]

Olaf- I moved the “runtimes” that were still in “C:\Program Files (x86)\Stock Investor\Professional” from this directory to another drive.
The runtimes I tampered with were:
msvcr71.dll
GdiPlus.dll
vfp9r.dll
VFP9RENU.dll

I did this one step at a time.
After I moved the first three files, there was no change in the computer’s behavior, i.e “Executable has stopped”.
Only after I removed VFP9RENU.dll did I get a new message from Microsoft Visual FoxPro saying: “Visual FoxPro cannot start. Could not load resources.”.
IMHO that message should sound strange, as another version of VFP9RENU.dll exists now in “C:\Program Files (x86)\Common Files\Microsoft Shared\VFP” (I double-checked that). I should note though, that although this DLL’s name is basically the same, in one directory was it named “VFP9RENU.dll” and in the other it is “VFP9renu.dll”. I don’t know if that means anything.

File Comparison:
1. foxhelp9: Same name, same size. In the “Stock Investor” folder it is dated 5 years earlier than in “C:\Program Files (x86)\Common Files\Microsoft Shared\VFP”.
2. foxhhelpps9.dll: Same name, same size. In “Stock Investor” it’s 5 years older.
3. gdiplus.dll: Same name. In “Stock Investor” it’s older and bigger (I copied this file myself previously to “Stock Investor”, as I noticed it was missing there).
4. VFP9r.dll: Same name, same size. In “Stock Investor” it’s older.
5. VFP9renu.dll: Name differs a bit- “VFP9RENU.dll” vs. “VFP9renu.dll”. Size is the same. Dates also differ a bit: in “Stock Investor” it’s newer 15/10/2007 vs. 21/09/2007 in “C:\Program Files (x86)\Common Files\Microsoft Shared\VFP”.

Koen- I shared with you the installation file from my Drive.

I appreciate very much the time you put in trying to help me sort out this mess.

 

[Olaf Doschke]

Whether the name is upper or lower case won't matter. File dates simply change when files are zipped/unzipped, when they really have a difference a checksum like md5 would differ, the same size already is a strong indicator they are same files.

I assume if you put the VFP9RENU.dll from “C:\Program Files (x86)\Common Files\Microsoft Shared\VFP” into “C:\Program Files (x86)\Stock Investor\Professional” you'll be back to the “Executable has stopped” error. Then I guess it's that EXE itself, that's defect. If a new download of the software setup doesn't work, I wonder if Koen will get the same error. If not, the only other vector left over is OCXes, but I don't remember missing OCX registrations to cause such a fatal error, in the worst case you get a message you can ignore and a form runs without that control, which can cause a lot of follow up errors, but no fatal error and all-in-all nicely points out which OCX isn't registered.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Koen Piller]

Eylon,
I have downloaded and installed with following result:
on my desktop I have 3 shortcuts:
1) StockInvestorPro___Data Updater for "C:\Program Files (x86)\Stock Investor\Professional\si_start.exe"
this starts and requires a Username plus Password
2) StockInvestorPro No Data Update for "C:\Program Files (x86)\Stock Investor\Professional\si.exe"
this does not start. It seems to search for an ActiveX component. (check with your vendor which ActiveX components si is using)
3)Stock Investor Pro Utilities for "C:\Program Files (x86)\Stock Investor\Professional\si_util.exe"
This seems to work, it opens a prompt from which you can select actions to perform

My advise to you:
delete all, repeat all vfpruntime files or if you are afraid rename them to "old"+original name
delete all files from your folder where you have installed s1_start, s1, and s1_util exe (use windows uninstaller)
use a search file like e.g. "everything" to be sure you have renamed and removed all files.
When you HD is cleaned, than use the installer again and let it install in the default directories.

Regards,

Koen

 

[Eylon]

Koen- I’d like to get a little bit specific. I hope you’re Ok with that.
By “repeat all vfpruntime“, do you mean re-run the Installer Olaf recommended?
Should the Runtimes in “C:\Program Files (x86)\Common Files\Microsoft Shared\VFP” be uninstalled first? Could they be uninstalled, or normal “delete” should do?
Should I uninstall (or delete) the Runtimes before or after I uninstall Stock Investor Pro? The same question goes for reinstallation. Would the order of uninstall and reinstall matter at all?
By “search everything” do you mean search for specific folders (like “Stock Investor”)? Otherwise there may be too many files and file types to look for and delete. Or did mean exactly that?
Another issue is privileges: should reinstallation be done with elevation?

By the way, if my user and password are needed to ascertain the software works on your side, I’d be happy to provide them.

Thank you Koen and Olaf once more.

 

[Mike Gagnon]

Right-mouse on the icon and change the compatibility to a lower version of Windows.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[Koen Piller]

Eylon,

By “repeat all vfpruntime“, do you mean re-run the Installer Olaf recommended?
I mean to delete all, without exception, the vfp runtime files, which are:

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

and of course vfp9.exe
the runtime files do not have to be 'uninstalled', run an uninstall of vfp9SP2 and after that delete any runtime files on your pc. delete also VFp9.exe from your HD.

By 'search everything' I mean your complete HD, all directories. Tool "Everything" is a fine tool to do this.
go to

https://www.voidtools.com/

No need for password a.s.o. programm works as expected. Or is it that your program errors with "Visual FoxPro 9.0 executable file has stopped working". on a certain place in the exe? In that case provide me with the username an pw and indicate where and when the error occurs on your side.

Regards,

Koen

 

[Olaf Doschke]

Koen, it's not really a good idea to just delete the files vfp9sp2rt.exe installed and registered, you will cause some orphaned registry keys pointing to missing files. Such actions cause more problems than they solve. It's true you sometimes need to go the cumbersome route, but as long as the software has a good entry in the system and an uninstaller, that should at least be able to remove all necessary stuff from the registry, too. Otherwise you'll need to advise to go through the registry, too.

I'd use available uninstallers first, that means pick the software from the list of installed programs for uninstallation and after that delete what remains after they ran.

I don't see how that can help a lot, the vfp9sp2rt.exe once installed would enable any exe compiled with vfp9 sp2 to run, unless it has more prerequisites than those covered by the runtimes it installs, and that's all the msxml versions needed for VFP specific xml commands, the vfp9 runtimes for both executables and DLLs (multithreaded dlls) and gdiplus and c++ runtime. And that's quite solidly working, unless some foxpro executable has a broken vfp9r.dll that overrides the usage of the centrally stored dll.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Olaf Doschke]

Eylon,

one last check, if you're not already in the process of uninstalling everything. If so, look at this after reinstallations:

Do you have the msvcr71.dll in C:\Windows\SysWow64? Notice, really exactly that name, there might be similarly named dlls with other numbers, that'll be C++ runtimes necessary for other software or even Windows itself, eg 100,110,120 are normally in there, too. Don't touch those.

You may look into it further using a right.cklick->Properties and looking for the product version in the details tab.

I have one with Version 7.10.3052.4 in SysWow64 and it's not in C:\Program Files (x86)\Common Files\microsoft shared\VFP, it's alos not necessary there, that VFP folder is for the DLLs and EXEs, that are registrable and which are registered.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Koen Piller]

Olaf,

I am sorry if I was unclear, but I said exe (use windows uninstaller) Of course an exe sould never be deleted by deleting but should be uninstalled, however it occurs that sometimes the uninstaller unstalls from the registry but not physicaly removes the file. That should also be done in this case, just to avoid there remain no old files on your HD.
Also ofcourse instead of removing, a renaming is more to be advised.

Koen

 

[Eylon]

Hi,
I haven’t done yet any deletions or uninstalled anything. Was planning to do that over the weekend.

I looked up msvcr71.dll on my computer and found there is one in SysWOW64 with Product Version 7.10.7031.4 and another one in “C:\Program Files (x86)\Stock Investor\Professional” with Product Version 7.10.3052.4.

Does this get us somewhere?

 

[Olaf Doschke]

Yes, that get's us somewhere, because likely the version you have in SysWow64, while being newer, is causing the errors. So rename the one in SysWow64 and see if that makes si.exe use the local DLL, then vice versa, rename the SysWow64 dll back to normal and rename the one in the Stock Investoer\Professional folder unusable.

Different versions of a DLL might have downward compatible classes and functions inside them, but at different entry point addresses, and that difference can cause a fatal error for entering a dll at the wrong addresses. The mechanism isn't that hard coded adresses, a DLL exports symbols for its entry points so two different versions are usable, but I only know for sure the older 7.10.3052.4 version is working in my system.

Now, there might be any other software which needs the 7.10.7031.4 version, so don't delete it. I'm almost sure the way you have it the local old version 7.10.3052.4 will be used, as the si.exe will need the c runtime even before looking for the vfp9r.dll Foxpro runtime, at its core the EXE starting point is still a c++ main() function that starts up the VFP runtime and then runs VFP code, so it matters where that part of the EXE looks for the msvcr71.dll first. If the renaming of the one in SysWow64 helps, that shows it looks there first, which means you could only run VFP9 applications on systems not having a later DLL in SysWow64. That would be a threat to VFP application. I can't really imagine that. But your situation doesn't work, so it indicates that already. Could be one of the tow DLLs is defect and not just the wrong version. That would complicate things.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Eylon]

Olaf- I renamed the two files (one at a time) but the software failed on both renames.
Oddly enough, the rename operation in “C:\Windows\SysWOW64” required elevation (which I granted) to complete.
In the other directory this was not required.
The end result was nevertheless the same.
Tough luck.

 

[Olaf Doschke]

That elevation need is not odd, when you act on a system folder you need elevation, that's the major resons installers need elevation to really install something and not just put files into redirected folders or virtual registry and "seem" to work.

It was my major concern, you could try one more thing and put the 7.10.3052.4 version into SysWow64. But I doubt it'll make a difference.

I now think no matter what you do, the EXE itself, the si.exe is defect and there's nothing we can do in the environment and from outside to fix that.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Koen Piller]

Eylon,

please mail me the username and pw in order for me to check Olafs's assumption quote I now think no matter what you do, the EXE itself, the si.exe is defect and there's nothing we can do in the environment and from outside to fix that. unqoute Also please indicate on exactly which occurence the application errors.

Regards,
Koen

 

[Eylon]

Thank you Olaf.

Koen-
Your suggestion is sensible. This trial may indicate if the fault lies within the installation file.
I will send you the data over email for better security.

 

[Mike Gagnon]

Have you even tried my suggestion?

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[Koen Piller]

Eylon,

nothing wrong with the software it can be installed on Win10 64bits. I think there is something 'rotten' on your pc.

Is this the only .exe built with VFP running on this pc?

Regards,

Koen

 

[Olaf Doschke]

Eylon, Koen,

OK, one thing I didn't yet think of is a broken external file like the foxuser.dbf. Actually, something too often causing problems, that we shouldn't overlook that. But because I also don't have much use of it in my projects I add a config file suppressing the generation of that DBF and I often forget about its existence.

Koen, you know what I mean, you don't need to read the rest, just if your getting back to this before Eylon you could simply see whether a foxuser.dbf is created.

A corrupt fioxuser.dbf could also make the EXE fail in a very early stage with a fatal error. An EXE compiled from VFP source code does create such a DBF, and that happens even before the first line of VFP code executes, so just like loading the C runtime and loading the VFP runtime and starting these things up to be able to execute the compiled VFP code this happens before any VFP code of the EXE itself that could cause that fatal error is. The reason is of course not just the generation of such a file but reading it. There is a way to configure this to not be created, but we don't yet need to get there, it would also suffice if it's regenerated because you delete a corrupted file set and the next one likely will not be broken.

In the simplest case you find two files foxuser.dbf and foxuser.fpt in the application directory or redirected by UAC into another folder, that will be:
C:\Users\yourwindowsaccountname\AppData\Local\VirtualStore\Program Files (x86)\Stock Investor\ProfessionalIt could also be in the more "normal" place, the application directory itself if the installer grants write permission into the installation folder
C:\Program Files (x86)\Stock Investor\Professional. It could also be in both when the vendor added a foxuser.dbf into the program files, but then you easily get into trouble when there still is only read permission and write operations create the file in the \VirtualStore\ folder. So please look in both places and delete the files in both places. The next step is you could create a text file and write RESOURCE=OFF into it, save that as config.fpw in the EXE folder, that'd prevent that files to be created. But before you do that, the software might make use of it, so there is no reason to avoid it, once it is generated correctly and works there always is the risk of it becoming broken again, but it will not happen so regularly and the fix will be to delete it. What you might win keeping it is the software remembering your window position or positions, that's one of the features stored in that table.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Koen Piller]

Olaf,
I have installed the software on my pc, had first deleted/renamed all foxuser.dbf
The installation did not construct a Foxuser.dbf in the installation directory.
The software is installed in the 'normal' place by the setup.
The software runs like a charm.
The error message "Visual FoxPro 9.0 executable file has stopped working" is not a VFP error to my opinion, it is more a WIN error.
The vendor did not add a foxuser.dbf to the installation files.
Let us wait what Eylon comment is on this situation.
Besides Eylon never indicated where / when the error occurs in his app.
Koen

 

[Olaf Doschke]

>The error message "Visual FoxPro 9.0 executable file has stopped working" is not a VFP error to my opinion, it is more a WIN error.

No, it just is the way a C000005 error is shown in Win8(8.1 and 10, it is a fatal error of the msvcr71.dll. I'm pretty sure abouit that C5 errors show up differently and yes, they are not VFP errors directly, they are a C++ runtime error, but in this case of an old C++ 7.1 runtime that's likely only installed for the VFP app. I assume the installer is a clickonce installer downloading the latest C++ 7.1 runtuime, this Eylon found the 7.10.7031.4 version.

C5 errors can occur from a defect foxuser.dbf or a corrupt frx, any table corruption can cause this, besides the less harmfule "is not a table" error. It would also perfectly explain why the error stays reluctant and only doe snot occur, if the VFP executable even doesn't start up the C++ runtime.

Here's an example showing the conjunction of "Application has stopped working" and C000005:

https://answers.microsoft.com/en-us...ing/62ed1dcc-2fbd-41df-80b8-aa3dfea73fa8?db=5

What I remember from a detail discussion about the difference introduced with Vista is, there is another level of error exception handling intended to give a user friendlier message, but as it is with such things, it hides details. There is the appcrash event and this also will be logged into the Windows Event log. That's a place Eylon could also look into, besides a vfp9err.log should also be created just as usual with C5 errors.

Did you look into the VirtualStore Folder for a foxuser.dbf, too, Koen?

Bye, Olaf.



Olaf Doschke Software Engineering

https://www.doschke.name