Throwing this out to the collective wisdom.
I've recently rolled out a hosted environment for my application. So I'm in the cloud... I've been observing random hard application errors, particularly around running reports. Of course, it's not consistent. A user will be able to run a report with no errors just fine one time and then other times the same report will just result in an application crash. What I'm seeing in the Windows application log when this happens are mainly C6 errors. The Google gave me some recommendations about setting the EXE and the runtime DLLs read-only but I'm hoping that out there in Profox land this might ring some bells.
TIA
--
rk
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---
On Tue, Apr 11, 2017 at 7:30 AM, Richard Kaye rkaye@invaluable.com wrote:
Throwing this out to the collective wisdom.
I've recently rolled out a hosted environment for my application. So I'm in the cloud...
It's hard to see clearly with your head in the clouds...
Which cloud? I'm guessing multiple WIndows X VMs hosted on... something. Azure? Amazon? Hosted server? What brand/version of all?
I've been observing random hard application errors, particularly around running reports. Of course, it's not consistent.
Which VFP? Reports using VFP9 or VFP8 compatibility? New Report listeners or old "classic" FRXs?
How was VFP installed? Are all the runtimes the same version? Are they patched up to Sedna + service packs?
Install vFoxRun if you haven't already. This is a *GREAT* tool for debugging (Thanks, Ed!) Then you can test things like VERSION(), and REPORT FORM right from the commandline, in your runtime environment.
One owner of our vertical-niche app runs virtualized, using RDP and TS to run multiple workstations on a hosted WInServer2008. There are lots of kinks with TMPFILES and sharing...
A user will be able to run a report with no errors just fine one time and then other times the same report will just result in an application crash. What I'm seeing in the Windows application log when this happens are mainly C6 errors. The Google gave me some recommendations about setting the EXE and the runtime DLLs read-only but I'm hoping that out there in Profox land this might ring some bells.
*ding*
-- Ted Roche & Associates, LLC http://www.tedroche.com
Thanks, Ted. And I apologize for the initial vague description.
This is a Windows 2012 R2 VM in our own corporate "cloud". There is also another VM running SQL 2014 which it connects to via ODBC. No VFP installation, per se. It's just my EXE and the appropriate DLLs/FLLs. VFP9 SP2. All proper versions of DLLs to match. Using REPORTENGINE 90. Using XFRX previewer instead of the native previewer. Not using a ton of report listeners in general but of course, the XFRX previewer does. I have a back door built into my EXE. It's not as slick as VFOXRUN but it gets the job done. Yes, the TMPFILES/sharing stuff is definitely a bit on the tricky side. Our app config is typically set to a local folder on the C drive but when run via RDP we redirect to a unique location for each user logged in. Having said that, you've given me an idea to try out. I also just added the R attribute to the 3 report*.app files. Since the majority of the crashes seem to revolve around reporting, maybe that will be the magic bullet. I also just cleaned out any saved printer environments.
--
rk -----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Ted Roche Sent: Tuesday, April 11, 2017 8:13 AM To: profoxtech@leafe.com Subject: Re: VFP EXE and RDS random crashes
On Tue, Apr 11, 2017 at 7:30 AM, Richard Kaye rkaye@invaluable.com wrote:
Throwing this out to the collective wisdom.
I've recently rolled out a hosted environment for my application. So I'm in the cloud...
It's hard to see clearly with your head in the clouds...
Which cloud? I'm guessing multiple WIndows X VMs hosted on... something. Azure? Amazon? Hosted server? What brand/version of all?
I've been observing random hard application errors, particularly around running reports. Of course, it's not consistent.
Which VFP? Reports using VFP9 or VFP8 compatibility? New Report listeners or old "classic" FRXs?
How was VFP installed? Are all the runtimes the same version? Are they patched up to Sedna + service packs?
Install vFoxRun if you haven't already. This is a *GREAT* tool for debugging (Thanks, Ed!) Then you can test things like VERSION(), and REPORT FORM right from the commandline, in your runtime environment.
One owner of our vertical-niche app runs virtualized, using RDP and TS to run multiple workstations on a hosted WInServer2008. There are lots of kinks with TMPFILES and sharing...
A user will be able to run a report with no errors just fine one time and then other times the same report will just result in an application crash. What I'm seeing in the Windows application log when this happens are mainly C6 errors. The Google gave me some recommendations about setting the EXE and the runtime DLLs read-only but I'm hoping that out there in Profox land this might ring some bells.
*ding*
-- Ted Roche & Associates, LLC http://www.tedroche.com
[excessive quoting removed by server]
What I'm seeing in the Windows application log when this happens are mainly C6 errors.
C6 errors occur when VFP opens a file using memory mapping (APP, EXE, DLL, mostly), accesses a part of the file that is mapped into memory and the file isn't accessible. Usually this happens when the network was briefly disconnected and the SMB session became invalid. Typical reasons are flaky WiFi connections, slow VPNs or virus scanners suddenly detecting a heuristic pattern.
Thanks for the details, Christof. Greatly appreciated. I had mentioned to my IT team that this appeared to be some kind of network related issue. I will pass this info on to them.
--
rk -----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Wollenhaupt, Christof Sent: Tuesday, April 11, 2017 9:19 AM To: profoxtech@leafe.com Subject: Re: VFP EXE and RDS random crashes
What I'm seeing in the Windows application log when this happens are mainly C6 errors.
C6 errors occur when VFP opens a file using memory mapping (APP, EXE, DLL, mostly), accesses a part of the file that is mapped into memory and the file isn't accessible. Usually this happens when the network was briefly disconnected and the SMB session became invalid. Typical reasons are flaky WiFi connections, slow VPNs or virus scanners suddenly detecting a heuristic pattern.
On 2017-04-11 09:19, Wollenhaupt, Christof wrote:
What I'm seeing in the Windows application log when this happens are mainly C6 errors.
C6 errors occur when VFP opens a file using memory mapping (APP, EXE, DLL, mostly), accesses a part of the file that is mapped into memory and the file isn't accessible. Usually this happens when the network was briefly disconnected and the SMB session became invalid. Typical reasons are flaky WiFi connections, slow VPNs or virus scanners suddenly detecting a heuristic pattern.
To that point--would copying the FRX/FRT locally and running from there be a better option to avoid that?
To that point--would copying the FRX/FRT locally and running from there be a better option to avoid that?
It would depend on which file is causing the problem... It certainly would be worth a try. If the EXE or any of the REPORT*.APP files is on the network it also would help to copy those to a local drive. Same is true for any DLL or OCX you use.
Another issue that causes crashes mostly when printing, but usually wouldn't result in a C6 exception, is the floating point problem. 15 years ago HP printers where notoriously famous for changing the exception handling for the floating point unit so that a division by zero caused a crash instead of returning NaN (not a number).
To work around this, we have
DECLARE _fpreset in MSVCR71.DLL _fpreset()
everywhere in our program where we access a printer driver. So before and after printing a report, selecting a printer, listing printers, etc.
IMO in general with multiuser applications the safest approach is to programmatically copy the report FRX\FRT to the user's temp location with unique filenames, run the report using the copied files, and delete them afterward.
On Wed, 12 Apr 2017, at 10:58 AM, Wollenhaupt, Christof wrote:
ago HP printers where notoriously famous for changing the exception handling for the floating point uni
Now they're famous for their PCL6 drivers *still* being a pile of crap.
I recently had to set up an HP laptop for a friend and was reminded why I don't like them! The recovery partition is set to be drive D: and cannot be changed .
John
John Weller 01380 723235 07976 393631
Now they're famous for their PCL6 drivers *still* being a pile of crap.
I have vague memories of the floating point bug and will look at getting that in place as suggested.
Just to clarify here, all users are accessing the EXE using RDP. There is no "local" C drive as far as they are concerned. And while there is a drive mapped to a share, it is all self-contained on the same VM. So it seems odd that it might drop the network connection to itself but...
--
rk -----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Wollenhaupt, Christof Sent: Wednesday, April 12, 2017 5:59 AM To: profoxtech@leafe.com Subject: Re: VFP EXE and RDS random crashes
To that point--would copying the FRX/FRT locally and running from there be a better option to avoid that?
It would depend on which file is causing the problem... It certainly would be worth a try. If the EXE or any of the REPORT*.APP files is on the network it also would help to copy those to a local drive. Same is true for any DLL or OCX you use.
Another issue that causes crashes mostly when printing, but usually wouldn't result in a C6 exception, is the floating point problem. 15 years ago HP printers where notoriously famous for changing the exception handling for the floating point unit so that a division by zero caused a crash instead of returning NaN (not a number).
To work around this, we have
DECLARE _fpreset in MSVCR71.DLL _fpreset()
everywhere in our program where we access a printer driver. So before and after printing a report, selecting a printer, listing printers, etc.
The plot thickens. I've been able to reproduce the crashes if I am logged in with a domain account that has the privileges of my end users. Both attempting to preview or print reports as well as using function keys as hot keys go kaboom.
--
rk -----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Wollenhaupt, Christof Sent: Wednesday, April 12, 2017 5:59 AM To: profoxtech@leafe.com Subject: Re: VFP EXE and RDS random crashes
To that point--would copying the FRX/FRT locally and running from there be a better option to avoid that?
It would depend on which file is causing the problem... It certainly would be worth a try. If the EXE or any of the REPORT*.APP files is on the network it also would help to copy those to a local drive. Same is true for any DLL or OCX you use.
Another issue that causes crashes mostly when printing, but usually wouldn't result in a C6 exception, is the floating point problem. 15 years ago HP printers where notoriously famous for changing the exception handling for the floating point unit so that a division by zero caused a crash instead of returning NaN (not a number).
To work around this, we have
DECLARE _fpreset in MSVCR71.DLL _fpreset()
everywhere in our program where we access a printer driver. So before and after printing a report, selecting a printer, listing printers, etc.
Richard Kaye wrote on 2017-04-12:
The plot thickens. I've been able to reproduce the crashes if I am logged
in with a domain account that has the privileges of my end users. Both attempting to preview or print reports as well as using function keys as hot keys go kaboom.
--
rk
Richard,
You mentioned using XFRX or FoxyPreviewer before. I have used FoxyPreviewer, and it creates a table, and writes some DLLs out it needs. If your previewer does this type of thing, file rights on those files may be your problem.
Tracy Pearson PowerChurch Software
Thanks, Tracy. I will see what I can find out about how XFRX does its temp work. My instinct is it uses the temp location for the profile but...
--
rk -----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Tracy Pearson Sent: Wednesday, April 12, 2017 5:26 PM To: profoxtech@leafe.com Subject: RE: VFP EXE and RDS random crashes
Richard Kaye wrote on 2017-04-12:
The plot thickens. I've been able to reproduce the crashes if I am logged
in with a domain account that has the privileges of my end users. Both attempting to preview or print reports as well as using function keys as hot keys go kaboom.
--
rk
Richard,
You mentioned using XFRX or FoxyPreviewer before. I have used FoxyPreviewer, and it creates a table, and writes some DLLs out it needs. If your previewer does this type of thing, file rights on those files may be your problem.
Tracy Pearson PowerChurch Software
[excessive quoting removed by server]
I was able to preview a report using the native engine so it's possible that something in the XFRX previewer is not happy.
--
rk -----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Richard Kaye Sent: Wednesday, April 12, 2017 5:32 PM To: profoxtech@leafe.com Subject: RE: VFP EXE and RDS random crashes
Thanks, Tracy. I will see what I can find out about how XFRX does its temp work. My instinct is it uses the temp location for the profile but...
--
rk -----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Tracy Pearson Sent: Wednesday, April 12, 2017 5:26 PM To: profoxtech@leafe.com Subject: RE: VFP EXE and RDS random crashes
Richard Kaye wrote on 2017-04-12:
The plot thickens. I've been able to reproduce the crashes if I am logged
in with a domain account that has the privileges of my end users. Both attempting to preview or print reports as well as using function keys as hot keys go kaboom.
--
rk
Richard,
You mentioned using XFRX or FoxyPreviewer before. I have used FoxyPreviewer, and it creates a table, and writes some DLLs out it needs. If your previewer does this type of thing, file rights on those files may be your problem.
Tracy Pearson PowerChurch Software
[excessive quoting removed by server]
I'll add a little to Christof's post about running _fpreset() in that you must run it before processing any "Set Date" command when using HP printer drivers. No idea why but it is the only way to make the drivers play properly and HP have never fixed this after 18 years to my knowledge.
What makes it more annoying is that the errors occur randomly which made tracking them down even more difficult than it should have done until I discovered _fpreset()
Dave
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Wollenhaupt, Christof Sent: 12 April 2017 10:59 To: profox@leafe.com Subject: Re: VFP EXE and RDS random crashes
To that point--would copying the FRX/FRT locally and running from there be a better option to avoid that?
It would depend on which file is causing the problem... It certainly would be worth a try. If the EXE or any of the REPORT*.APP files is on the network it also would help to copy those to a local drive. Same is true for any DLL or OCX you use.
Another issue that causes crashes mostly when printing, but usually wouldn't result in a C6 exception, is the floating point problem. 15 years ago HP printers where notoriously famous for changing the exception handling for the floating point unit so that a division by zero caused a crash instead of returning NaN (not a number).
To work around this, we have
DECLARE _fpreset in MSVCR71.DLL _fpreset()
everywhere in our program where we access a printer driver. So before and after printing a report, selecting a printer, listing printers, etc.
-- Christof
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---
[excessive quoting removed by server]
mbsoftwaresolutions@mbsoftwaresolutions.com wrote on 2017-04-11:
On 2017-04-11 09:19, Wollenhaupt, Christof wrote:
What I'm seeing in the Windows application log when this happens are mainly C6 errors.
C6 errors occur when VFP opens a file using memory mapping (APP, EXE, DLL, mostly), accesses a part of the file that is mapped into memory and the file isn't accessible. Usually this happens when the network was briefly disconnected and the SMB session became invalid. Typical reasons are flaky WiFi connections, slow VPNs or virus scanners suddenly detecting a heuristic pattern.
To that point--would copying the FRX/FRT locally and running from there be a better option to avoid that?
Mike,
No. Even in a network condition, what I found was most beneficial was moving the EXE local.
But using Remote Desktop, everything is local to the server hosting the program.
Tracy Pearson PowerChurch Software
-
Alan Bourke -
Dave Crozier -
John Weller -
mbsoftwaresolutions＠mbsoftwaresolutions.com -
Richard Kaye -
Ted Roche -
Tracy Pearson -
Wollenhaupt, Christof