Fatal Error: C0000094 on Windows 10 PC 1

[bobmpalmer]

Hi, I have over 300 users across the country using my app on all flavours of Windows without issue but this one has me flummoxed.

The app is quite a big SQL base client server compiled exe built in VFP9 SP2.
I have one client who's PC's are all Windows 10 and their installations are no different to anybody elses with a standard VFP9 runtime libraries, Windows Common Controls and a few other dependables for various features in the system.

The system has been running fine for some months and then recently they started to get Fatal Exceptions not when launching the app but when they try and open a form within the app after log in.

If I reinstall the app it works again for a short while (few days) then starts to crash again.

Logic implies it's a conflict with another app using a shared resource that is changing when that application is run that then upsets VFP but I'm guessing.. No other sites have the issue. This is the Error:

Anyone any clues?

Bob Palmer

http://www.resisystems.co.uk

The most common solution is H2O!

 

[Mike Gagnon]

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

Mike Gagnon

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

 

[bobmpalmer]

Yes Mike, thanks but I've been through all these.. I've also Googled the Error all over the place.

It's not Reports.. not reporting when it occurs.
It's not Fonts.. tried that they are all present and correct.
It's not video driver, it's occurring on 4 out of 6 different machines.
It's not Index's as I'm using views populated from SQL which are built and indexed fresh every time they log in and anyway 2 machines running the same data are working fine.

It's only this one client. I can only assume a conflict with something else they run that others don't.

I posted in case someone else had had this recently.




Bob Palmer

http://www.resisystems.co.uk

The most common solution is H2O!

 

[Olaf Doschke]

Well, take the error message seriously, not only the error number.

What is line 36 of "fileopenform"?

Bye, Olaf.

 

[bobmpalmer]

Hi Olaf

its a form manager function in Menuprocs to allow diferent forms to be opened with or without passed values
Line 36 is
DO FORM (tcForm) WITH tnFlag,tuPrimary

Where
tcform is the form name
tnflag is 1 or 2 where 1 is Open with the first record 2 is open with the passed ID
tuPrimary is the passed ID
The click is from a sidebar based on Outlook.vct




Bob Palmer

http://www.resisystems.co.uk

The most common solution is H2O!

 

[Olaf Doschke]

Aha, so when the error handler is reporting an error on a DO FORM (or also on a CREATEOBJECT("formclass"), then, of course, it's not that line, but the error handler could only report a line number of a method in the form, if that was running. The first code, that could run next is a line in form.Load. Next thing would be init-code of controls, then of the form. Since nothing of that is reported, the error is still within the form, but not in code.

What do you think is a DO FORM causing? There's a lot of things going on before the first line of form or control code runs. First, the form is loaded, there could be any corruption with the file. It could be about fonts, as the wiki says, it could be about any form or control property expression being evaluated. When ActiveX controls are involved, even another runtime needs to be started, depending on what language the control is originally implemented in.

There is no error like "record X of Y" of the form reported, also it's a C runtime exception, no VFP code itself errors. More specific this error is having to do with divide by zero, what could be the root cause? Some anchoring calculation is done on a control you set to width or height 0? It could be very esoteric things as calculating with such dimensions, a corrupt font file or 0kb file might also cause such an exception caused by the unexpected condition of not being able to load some info and thus having a struct prefilled with 0, then causing a division by something, which normally can't be 0, like a font height.

Anyway, you know the form failing, one more likely error is a corruption in the form file itself. Rebuild that form, that's what you can do. Don't copy it, redo it. You can copy the code (text), but not the file itself nor drag&drop controls from it into a new form, that can copy such errors. Way back in vfp7 I had complex forms with many nested page frames, which I could repair with PACK, but which later repeatedly broke, it was reproducible, but unforeseeable how long it held. There are such bugs and in that case, a complete rewrite helped.

Bye, Olaf.

 

[bobmpalmer]

Thanks Olaf,

I Really can't see it as being the form and anyway, it's any form that they open that triggers it. (376 forms in this app)

The app is client server and the same .exe is being used on 6 other machines at that site and not failing.

The network install just installs the usual library files and one font, FOXPRINT.TTF We have a loader file that copies the .exe from the server so it's exactly the same file as the other machines are running.

Re installing the network install seems to fix it..

The only other apps they run are the latest version of Word/Outlook.

Thanks again.
Bob

Bob Palmer

http://www.resisystems.co.uk

The most common solution is H2O!

 

[Olaf Doschke]

>Re installing the network install seems to fix it..

You mean, if the local EXE is freshly copied from the network location, you don't get the error?

Well, doesn't that suggest some degrading of the local EXE. I can't imagine anything changing the EXE, but it seems like that, doesn't it?

Is it really any form? As you know the line it happens, add logging of what form is called before line 36 of fileopneform and see if it really is random.

Bye, Olaf.

 

[bobmpalmer]

No, the .exe doesn't change at all.
When we run the Network Install, the network install ONLY installs library files on the client.

Yes it's any form.. I don't have the computer this is erroring on or access to it to run tests.

We seem to be focusing on a problem in VFP or my code which is illogical as the system is running fine on all other PC's
It implies the problem is in the environment/files VFP is running with on this PC.

In my original question I said my thoughts were towards a windows file/shared resource etc etc that may be affecting the way VFP is behaving. You did say it was a C runtime exception so maybe some file in that set is changing from the files we install.

Either way, I raised it here just in case other developers get/or have had an issue like this on a client PC.



Bob Palmer

http://www.resisystems.co.uk

The most common solution is H2O!

 

[Olaf Doschke]

>Yes it's any form.. I don't have the computer this is erroring on or access to it to run tests.

Then:
1. How do you know? Are Users reporting that?
2. You HAVE control about anything you want, as you can compile a new EXE. Code can write out parameter values into a txt log file, etc.

You're not the first I experience THAT helpless. What's up today? Is nobody aware of possibilities of debugging and analysis anymore?
Do you now dependency walker?
Do you know processmonitor?
Are error handling and trace logging concepts you know?

Bye, Olaf.

 

[Nigel Gomm]

Bob,

are you saying that you're launching the .exe from the network drive?

Best to copy that too to the local client PCs.

hth

n

 

[bobmpalmer]

No nigel..
Have not done that since we went over to SQL 6 years ago..

I use a loader that compares the local .exe to the one on the server, if the server one is later its copied over to the local PC then run locally.

My point was the .exe is identical to the one being run on all the other machines! It can't therefore be a codeing error it has to be a local PC system problem.

Anyway, thanks all for the responses, it's obviously not a known issue that others have had, so we'll leave it at that.


Bob Palmer

http://www.resisystems.co.uk

The most common solution is H2O!

 

[Olaf Doschke]

I've had such setups, where the "clever" power users simply circumvented the loader start routine by pinning the running app to the taskbar or creating a start tile in Windows 8. Problematic in that case then is updates never getting to such "clever" users.

And once a user is off the update routine, which would fix a modified exe, such things can happen by virus or other malware, for example.

Since you have a runtime installer. Best way to avoid any conflicts is having the runtimes in app folder, not extra.

Bye, Olaf.

 

[bobmpalmer]

Yes Olaf.
Could well be worth a try.
Yes I have has the odd install where the desktop shortcut has been pointed at the .exe rather than the loader by 'I know better' users lol.

Thanks

Bob



Bob Palmer

http://www.resisystems.co.uk

The most common solution is H2O!

 

[bobmpalmer]

Ok we now have a bit more information.

Each of the PC's were upgraded to Windows 10 1703 update and it was after this that the Error started to occur.



Bob Palmer

http://www.resisystems.co.uk

The most common solution is H2O!

 

[Olaf Doschke]

OK, but a Windows update does neither change your EXE nor runtime DLLs. The only DLL the system could be involved with is the msvcr71.dll. Did/do you install this DLL into Syswow64 folder?

Bye, Olaf.

 

[bobmpalmer]

Indeed it looks as if we do Olaf..
Installshield installer is set to use merge modules default destination.

Bob

Bob Palmer

http://www.resisystems.co.uk

The most common solution is H2O!

 

[Olaf Doschke]

Well, the best practice about VFP runtimes including C runtime is to install within the app folder. Anything you install in system folders is, well, system managed and owned. I don't know of several versions of msvcrt71.dll, other c version runtimes have other names and wouldn't have an impact on what VFP9 apps use, but who knows what happens to these DLLs with Windows updates.

The runtimes installers I also pointed to in the recent thread184-1778394 are also installing into the system folder, but they have no other choice to install runtimes for unknown applications.

See

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

MSVCR71.DLL distribution is covered in Microsoft Article ID 326922. It says (in part)
"Because it is no longer a system component, install it in your application's Program Files directory with other application-specific code."

(You find the mentioned article here:

https://support.microsoft.com/en-us...of-the-shared-c-runtime-component-in-visual-c

I don't know why a Windows update would touch a runtime DLL in system32 or SysWOW64 if it doesn't need this runtime for itself. If there is an older VS installed, that might be involved. If you get hands on, look at what happened to the DLL within their Windows 10 clients, but all this will not play a role if you do as MS suggests to solve DLL hell aside of not developing legacy applications: Put DLLs to the applications they use them. You have no problem with disc space or any other argument for installing such things into the system.

Bye, Olaf.

 

[SnyAc]

To correct my customer's issues with this fatal error I did follow Olaf's advice of having my apps copy all of the runtime dll's into the app startup folder and then uninstalling the app using the control panel. The app functioned fine after that. Just had to send the exe to the desktop as a shortcut.

Andy Snyder
SnyAc Software Services

http://www.snysoft.com

 

[Olaf Doschke]

Thanks for letting us know.

Then you install that way an unzip can work fine, as long as it does not need to go into %Program Files%, so there still is a good use of the InstallShield setup. I also think you could get it to install the runtimes within the destination folder of the application itself instead of system folder, thus not get in the way of any update mechanisms of any other software. And last not least any DLL or OCX needing registration should still be registered or won't work.

In regard to updates, lately I have the impression Windows Update is in a quarrel with AMD graphics drivers and each of them overwrites and "repairs" some DLLs. That has nothing to do with VFP at all, I just see a confirmation of some quirks in software/OS/driver/runtime updates. Indeed there are several vendors applying automatic updates not only Microsoft. Adobe is another player doing it's own updates and Java of course.

That aside, I think I can manage it. In regard of my software automatic updates a corporation decided to setup a specific folder for corporate software to simply allow installation from a central folder of all application files via a batch file making a robocopy call. That type of deployment also is well known as xcopy deployment (robocopy is just a later much better version of xcopy). There is a bit of a security risc, but group polilcies can limit what runs there by whitelisting of allowed software.

Bye, Olaf.