Vfp App in Windows Server 2012 - "This App can't run on this PC"

[KALP1]

My App was working fine in Windows Server 2008 and 2012. Few days back, I had to format server due to some technical problem and reinstalled Windows Server 2012. After this,above said error appears once in a while in a day and I have to ask my users to either use another executable with diff. name or ask them to leave that particular instance of Exe.When none of the users use that particular instance,it is then available for reuse. What might be reason for this as before installation, my EXE was working perfectly fine even in Windows 2012.

 

[GriffMG]

That is an uncommonly 'relaxed' error message - is there any chance it is coming from your application - rather than the operating system?

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 this is a windows message, for example see

https://www.youtube.com/watch?v=ApA6tVypI2E

I assume its that same form of message band across the desktop.

In this video it's due to running a 64bit application on a pure 32bit system. For VFP apps the opposite would be a hurdle, i.e. you installed a pure 64bit server version and can't run a 32bit VFP app.
Does Windows Explorer find a %WinDir%\SysWOW64 folder? Then you have a 32bit subsystem and you have other reasons for it not to work, like policies. I don't suspect the VFP runtimes are missing, or are you really just copying a folder over?

Bye, Olaf.

 

[KALP1]

GriffMg,
This msg. is coming from OS itself and same as shown in the Video suggested by Olaf.
Yes Olaf, I have SysWOW64 folder in my C Drive.
This error occurs in a day or two if users don't log off from server.

 

[Olaf Doschke]

If this only happens in conjunction with too many sessions, there is a resource leak, perhaps or simply insufficient resources. Then all you can do is educate users to log off.
You don't have any code or technical problem at all in that case. Just a resource problem.

Are you using SYS(3050) actively instead of passively let VFP allocate half available memory? Putting this to a reasonble size might allow more concurrent user sessions.

Bye, Olaf.

 

[KALP1]

I am not setting sys(3050) explicitly.
If there is any resource problem, then my other instances of same exe with diff. name should also not work. It occurs for that particular instances only and that too at any moment randomly even when just 1 or 2 users are using it.

 

[Olaf Doschke]

What's the name?

Names with UPDATE or SETUP in them cause UAC to start an EXE elevated and that might cause your problems.
See

https://technet.microsoft.com/en-us/library/cc709628(v=ws.10).aspx

"Installer Detection Technology"

Applications without a requestedExecutionLevel

VFP9 embeds a manifest with requestedExecutionLevel "asInvoker", so your EXCE might not contain one, is VFP8 or earlier.

It would really help to update to VFP to have a minimum compatibility with Vista and Higher also Windows Server 2008 and higher. This is not just an optional thing anymore.

Bye, Olaf.

 

[KALP1]

There is DEP - Data execution Prevention under security tab in advanced settings in Windows 2012 which is enabled by default.
This setting was problem. Turning it off solved my problem.

 

[Olaf Doschke]

OK, are you using Calvin Hsia's multithreading hack in your application? AKA MTmyVFP? That is doing data execution by "poking" some ASM bytes into memory and executing them. I already mentioned this isn't working with DEP earlier. It just proves DEP to work.

Bye, Olaf.

 

[KALP1]

No, I am not using MTmyVFP , just using ParallelFox for multithreading.

 

[Olaf Doschke]

Afaik ParallelFox is just starting further processes, maybe unusual enough behaviour to disallow it, or Parallelfox also uses the multithreading method now. Anyway it's a bad situation you need to turn off DEP for your application to get it up and running.

Bye, Olaf.

 

[KALP1]

Turning Off DEP also not worked as I thought before. The same error popped up this morning. I think to note is that DLL which I have to register for parallel fox gets unregistered as soon as this error pops up.

 

[Olaf Doschke]

ParallelFox install.prg registers a COM SErver class ParallelFox.WorkerMgr, that's part of parallelfox.exe, not any DLL. I don't know what you talk about.

Bye, Olaf.

 

[KALP1]

Its not DLL,its a class which gets unregistered . Actually, As soon as Msg "This App can't run on this PC " comes , OLE Error - "Class not unregistered" and "oWorker is not found" starts coming thereafter.

 

[Olaf Doschke]

ParallelFox.WorkerMgr is a class most likey instanciated and maintains workers (processes). OLE classes don't necessarily are defined in DLLs, in this case its in the EXE, in other cases it can be OCX files.

It's more like the error says "class not registered" than "class not unregistered". Have you installed Parallelfox prerequisites - made that install.prg run on the Server? Most likely that's what's missing.

On the other side, since you spawn many processes with parallelfox memory management is a big concern and again number one on my list of suspects after the registration of the necessary OLE class is mended. As you don't manage it by using SYS(3050) VFP uses its standard memory allocation mechanism, which I'm not sure about today, but once was taking half the RAM. Of course it takes 2GB at max, but even a 24GB server then would only host 11 VFP processes with 2GB each and the next processes will swallow half the remaining RAM, 1GB, 0.5GB and so on. If you start parallelfox with 10 worker threads a single user starting the app may already consume most RAM. You have to refine and do manual memory management, if you go for parallel processing.

Bye, Olaf.

 

[Olaf Doschke]

As side note: Why is it, most people only report the last error and behaviour of a failing application, if they know there always is a prehistory. The most interesting error happening always is the first one, because mending it will in most case also solve all follow up errors.

Bye, Olaf.

 

[KALP1]

Yes, Error was "Class not registered", it was my typo mistake. I have run Install.prg but as app can't run...error occurs, class gets unregistered. I run install.prg and restart server , then things become normal until again app can't run...error occurs.

Will I need to set SYS(3050) manually .

 

[Olaf Doschke]

Well, read the docs. You have to run install.prg elevated. Class registration is a process needing UAC elevation on top of being admin.

DO INSTALL to register ParallelFox.exe and install the IntelliSense scripts. See the "Installation" topic in the Help file for details.

The install program registers ParallelFox.exe on your machine. On Windows Vista/7, administrator elevation will be requested to perform the registration.

That's also valid for Windows 8,8.1, 10 and and all corresponding Server versions of Windows since Windows Server 2008.

And I'd suggest the easiest way to get your registration correctly once and for all time is to right click on VFP9.exe and start as admin to let VFP9.exe itself run elevated and then DO INSTALL.

Also notice the registration process will store location of the Parallelfox.exe most probably on a local drive. If you unzipped to a share you register a file most probably with mapped drive letter and that is not necessarily mapped for all terminal server users.

In regard of SYS(3050), let that rest as long as you still have "class is not registered" errors, you don't register correctly. The problem with unelevated registering is, registry entries are done redirected to your user registry key hive and then only work for you, but not for other users. Neither VFP nor the OS will tell you and error, though.

You only register something correctly, if you do so elevated. I especially doubt what the help says: "elevation will be requested". NO, the OS will just silently redirect registry entries and not say a word about it. This only works for a single user, yourself, not for others.

Bye, Olaf.

 

[Olaf Doschke]

Will I need to set SYS(3050) manually

In regard to that, though I said you may put this to rest until you eliminated the class registration process...

It never hurts to put a call into main.prg setting SYS(3050,1,N) and SYS(3050,2,N). Where N is a number of reasonable bytes.

What is reasonable depends on your application and database. One thing is rushmore bitmaps needing a bit per record of tables for every single (atomic) where condition you have. With complex where conditions of queries and tables with millions of records and multiple such queries you better offer enough MB RAM, still you need to balance this with number of concurrent sessions (users and parallel processing) and yet also give enough room for further things stored in that memory, all objects, classes, cached data, cursors....

Giving too less, rushmore optimization might swap to virtual memory, meaning writing to HDD rather than allocating more RAM, you set an upper bound with SYS(3050). I have seen this happening at a customer using a library with too low SYS(3050) setting, though sufficient RAM was still unused.

You can only make a good decision about N bytes, if you know your app inside out on the one side and know what VFP uses that memory for on the other side. Any rule of thumb can easily be broken depending on what you do and with parallel processing depending on number of workers you start you actually don't help multiple users on a terminal server, you still only have one host CPU with X cores and every user should rather only use one of them to profit from the multi core server CPU. If the first user already has all cores and hyperthreading cores used for his processes you don't gain performance via ParallelFox for any further user.

Bye, Olaf.

 

[KALP1]

As far as registration of class - parallelfox.exe, that is not an issue. Issue is the one with which thread started. I have to re-register class again as the above said error appears. Once registration is done it works for all users.