VFP 9 with Windows 10 ?
I have several VFP applications running at few customers. As time went by some of them were "forced" to switch to windows 10.
Unfortunately those who switched encountered "file access denied" popup every 5-10 min while using the system.
While other users (on Windows 7 ) did not encounter any issue -using the same app.
I need to say that the app is on a windows 2008 (or 2012) server. and the users are accessing the app over the network.
The database used is the native DBF of VFP.
The problem would only popup when the app is idle.
I had posted already this here and one of the recommended solution was to check for Network Card going to sleep. It was not the case.
I also saw another post that was talking about OpLocs
https://support.microsoft.com/en-us/help/296264/configuring-opportunistic-locking-in-windows
Tried it but again it did not work.
I also tried tweaking the NIC but again did not work.
My problem is that nowadays Windows 7 is becoming less and less supported when it comes to hardware (many new PC chipset are not compatible with Windows 7).
Now another added layer of complexity is that the Application is sitting in a Hyper-V VM - Host and guest are both Win2008 or 2012 Server.
I know that VFP is obsolete, but I still have tens of applications out there and moving them to another platform is taking time...
Anybody experiences these problems ? what is the solution ?
Thanks
Unfortunately those who switched encountered "file access denied" popup every 5-10 min while using the system.
While other users (on Windows 7 ) did not encounter any issue -using the same app.
I need to say that the app is on a windows 2008 (or 2012) server. and the users are accessing the app over the network.
The database used is the native DBF of VFP.
The problem would only popup when the app is idle.
I had posted already this here and one of the recommended solution was to check for Network Card going to sleep. It was not the case.
I also saw another post that was talking about OpLocs
https://support.microsoft.com/en-us/help/296264/configuring-opportunistic-locking-in-windows
Tried it but again it did not work.
I also tried tweaking the NIC but again did not work.
My problem is that nowadays Windows 7 is becoming less and less supported when it comes to hardware (many new PC chipset are not compatible with Windows 7).
Now another added layer of complexity is that the Application is sitting in a Hyper-V VM - Host and guest are both Win2008 or 2012 Server.
I know that VFP is obsolete, but I still have tens of applications out there and moving them to another platform is taking time...
Anybody experiences these problems ? what is the solution ?
Thanks
The normal troubleshooting process would be to see what access denials are happening. Download procmon, a monitoring freeware from Microsoft. Run it at the client and filter the output for "access denied" and share the results.
ASKER
Dear Gary2Seven
The thing is that if it is not over the network windows 10 has no issues.
Also over RDP (which is eventually no more over network!)
The problem is always replicable.
How do you suggest we troubleshoot ?
I can fairly easily create a test environment with windows server and windows 10 PC and replicate the error.
What tools must I use ?
Thanks
The thing is that if it is not over the network windows 10 has no issues.
Also over RDP (which is eventually no more over network!)
The problem is always replicable.
How do you suggest we troubleshoot ?
I can fairly easily create a test environment with windows server and windows 10 PC and replicate the error.
What tools must I use ?
Thanks
McKnife has made a good suggestion with procman. I would also use the coverage function in VFP which will log all activity
SET COVERAGE TO <filename>
SET COVERAGE ON
If you can find an old copy there is a tool, coverage profiler (CVP) which makes the coverage file easier to read. If you can't find I may have an old copy somewhere.
SET COVERAGE TO <filename>
SET COVERAGE ON
If you can find an old copy there is a tool, coverage profiler (CVP) which makes the coverage file easier to read. If you can't find I may have an old copy somewhere.
ASKER
I don't have that tool.(coverage profiler reader).
Care to share it ?
Thanks
I will set up a test environment as soon as I can and revert back.
Will also set the coverage profiler on
My problem with procmon is how to use it ?
Coz the problem does come randomly ( but always) and not in a specific module.. so when the error pops then I need to check Procmon ? Supposedly I keep it open and the user works normally for 2-3 min then the error pop ups .. then I check Procmon "for access denied" ?
Thanks
Care to share it ?
Thanks
I will set up a test environment as soon as I can and revert back.
Will also set the coverage profiler on
My problem with procmon is how to use it ?
Coz the problem does come randomly ( but always) and not in a specific module.. so when the error pops then I need to check Procmon ? Supposedly I keep it open and the user works normally for 2-3 min then the error pop ups .. then I check Procmon "for access denied" ?
Thanks
Procmon has a filter icon. Filter for result "access denied" and keep it running.
I still don't understand why customers tend to the combination of obsolete tool running under the newest operating system... I know VFP apps are great and they will be running for a several more years but customers should modernize the software the same way as they do for operating systems.
Yes, ProcMon is a good start. Please let us know what file reports access denied.
To fix the issue will be another and possibly big task. I would add a few hints what to do next:
VFP applications are still reliable when accessing data on local computer. Shared remote DBFs are less and less supported under newer operating systems. The application itself should not run from remote folder. You should copy it to the local computer first and also r/o data should be on the local computer.
RDS is a good solution. Shared data can reside on the same server where all the RDS sessions are running and problems are gone for both your customers and even Microsoft obtains license fees for each connected user...
More work would mean to upsize all the DBFs to SQL Server or to another C-S architecture. VFP fully supports such step but it also means a lot of work which is not worth to do in VFP app today.
One more hint is based on the fact the access denied happens after certain idle period only. So add a timer to your app and keep reading/writing data in some table on the server each 10 seconds or in a different period.. Of course, to have the app on local computer is still a must.
Yes, ProcMon is a good start. Please let us know what file reports access denied.
To fix the issue will be another and possibly big task. I would add a few hints what to do next:
VFP applications are still reliable when accessing data on local computer. Shared remote DBFs are less and less supported under newer operating systems. The application itself should not run from remote folder. You should copy it to the local computer first and also r/o data should be on the local computer.
RDS is a good solution. Shared data can reside on the same server where all the RDS sessions are running and problems are gone for both your customers and even Microsoft obtains license fees for each connected user...
More work would mean to upsize all the DBFs to SQL Server or to another C-S architecture. VFP fully supports such step but it also means a lot of work which is not worth to do in VFP app today.
One more hint is based on the fact the access denied happens after certain idle period only. So add a timer to your app and keep reading/writing data in some table on the server each 10 seconds or in a different period.. Of course, to have the app on local computer is still a must.
ASKER
What is weird in this is that while the user is working there is no problem at all.
Only when the PC seems to be idle for few minutes then this message will pop up !!
Only when the PC seems to be idle for few minutes then this message will pop up !!
That really does sound like hard disk or network card going into 'sleep' mode.
Make sure you have no power save options affecting disk or network and that there is no disk cache turned on.
Make sure you have no power save options affecting disk or network and that there is no disk cache turned on.
ASKER
I did check the network card .
What about disk caching ? The disk are SSD. Does it matter ?
What disk caching has to do with the problem ? Could u pls explain ur concern ?
Thanks
What about disk caching ? The disk are SSD. Does it matter ?
What disk caching has to do with the problem ? Could u pls explain ur concern ?
Thanks
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hi Pierre,
could yo please tell what was the final solution and the root cause? Delayed write or Power saving options?
Symptoms were pointing to antivirus or network share disconnection.
could yo please tell what was the final solution and the root cause? Delayed write or Power saving options?
Symptoms were pointing to antivirus or network share disconnection.
I don't have an immediate solution for you, but I can tell you that we have 100+ installations of VFP9 applications out there on stand alone Windows 10, peer to peer networked Windows 10 and accessing Azure servers over RDP and we don't experience this issue.
Can you always replicate? Could you setup a test machine with coverage turned on so you get a log of exactly where this occurs? That would tell you if it's same place each time.
Have you tried posting your problem in hyper V section (without mentioning VFP) to see if it could be a hyper V issue?