|
Post by daryl on Sept 19, 2019 8:47:50 GMT 1
Page fault errors have been around since vDos supports virtual memory paging in protected mode as used by FoxProX (PharLap DOS extender). It means the program is referring a virtual memory address for which no directory or table entry is setup by the program. The vDos download page states: “Long awaited fix of the occasionally (and illusive) Page Fault errors with FoxProX”. And I thought they were finally fixed with version 2019.05.01. It surely doesn’t occur as frequent as before, but you’re the third to report they still exist. I did meanwhile find an extremely rare situation that could cause a page fault. But fixing that didn’t resolve it either (for the one who tested). A page fault forces vDos to shut down since it can’t resolve the given virtual address to a linear one. When vDos is restarted, it (of course) has no knowledge of previous page fault errors in a different instance. So there’s no vDos related “Once it occurs it happens every time after. For now you simply have to live with that error. I suppose you don't start a second FoxProX program from inside the first one. Jos I see, is there any way that I can provide any help with diagnosing the issue or finding the source? seeing as it seems to be rather random as to when it occurs and nothing is being logged in the log file other than "Unable to open file" when it is trying to write data to a CSV of about 1.4MB in size?
|
|
|
Post by Jos on Sept 19, 2019 9:19:15 GMT 1
Thanks for the offer to help finding that (last?) page fault error. But a first condition for low level debugging would be that the error can be reproduced in a consistent manner. Even then it would be extremely hard, if not impossible, to track down the cause the program addresses an illegal/incorrect virtual address. The actual trigger could be millions instructions before the offending one.
The only thing you could try is to add some environment variable that ‘eats’ away at least 16 bytes of environment space. For instance SET SOMETHING=SOMETHING. That often fixed the page fault error in the past, though those were already supposed to be fixed with 2019.05.01, so it’s a longshot.
Jos
|
|
|
Post by daryl on Sept 20, 2019 8:28:11 GMT 1
It certainly seems to happen more often than not, any time I press the menu item the application crashes from tests. I'll try your suggestion and see if it helps.
Suggestion did not help, it worked once out of 20+ attempts all others had page fault, interestingly the app creates .tmp files after the crash with the majority of the data once I click OK and vdos closes so it still finishes up half the process, unfortunately this is not a workable solution at the moment as this component is required for their day to day work.
|
|
|
Post by herman on Sept 21, 2019 8:41:14 GMT 1
Maybe a hint to get ahead?
I think I recognize a few things from previous problems with my dBase application, that was long ago.
I often call the cmd from the DOS application and the application did not work properly with the work path on C: with
USE C: C:\GENEALOG in autoexec.txt configuration file from vDos.
The application itself works at the points where cmd was not called.
When I used USE C: C:\ and from there went to the GENEALOG workbook everything worked fine.
Regards Herman
|
|
|
Post by Jos on Sept 21, 2019 9:02:36 GMT 1
darylWell, it was a longshot that worked in the past. Those page faults seemingly had another origin than yours. The moment vDos encounters a page fault it just exits immediately. Any further file activity/update comes from Windows as the open files are closed. If it’s important to get the application working, you could contact me directly. Jos
|
|
|
Post by Jos on Sept 21, 2019 9:07:13 GMT 1
hermanYou have to realize CMD.EXE is a Windows program. So it works with the Windows drive letters, not those of vDos. C: in CMD.EXE will always be Windows C:, no matter what the C: in vDos is set to. Jos
|
|
|
Post by daryl on Oct 16, 2019 11:04:55 GMT 1
daryl Well, it was a longshot that worked in the past. Those page faults seemingly had another origin than yours. The moment vDos encounters a page fault it just exits immediately. Any further file activity/update comes from Windows as the open files are closed. If it’s important to get the application working, you could contact me directly. Jos To be honest with you it's for a customer of ours, we work as an MSP and they need it for invoices in one of their apps. Everything seems to be fine except this one menu item which creates the files and lets you save as CSV/PDF, at this point it crashes with page fault before they get the option to choose to save it. They are not too happy with the upgrades to windows 10 however technology is progressing and the application is not, so anything that can be done to find a solution would be brilliant. You have to understand that I would need to contact the customer for access to their system to get any information you require so it wouldn't necessarily be instant communication but anything that can be done is better than nothing.
|
|
|
Post by Jos on Oct 16, 2019 15:06:56 GMT 1
Just a thought: The program calls external executables. Are those DOS programs directly using extended memory (not by XMS) and messing with the virtual paging directories?
Jos
|
|
|
Post by daryl on Oct 17, 2019 8:31:02 GMT 1
How would I best get the info you require?
|
|
|
Post by Jos on Oct 17, 2019 8:50:05 GMT 1
If you know what programs are started and those are freely available, the programs names and versions. Preferable also how they are started, so the command lines.
Else you could start vDos with the logging option ("…vDos.exe" /log). That will create a vDos.log file, among others, listing the programs that are started. The log file would end premature if one of the programs indeed messes up the virtual paging directories. The main FoxProX program will cause a page fault error after it gets control back and switches to protected mode and virtual memory paging.
Jos
|
|
|
Post by daryl on Oct 18, 2019 9:09:22 GMT 1
I can certainly run /log options and grab this for you. The application is not something that can be downloaded/accessed easy and is used for logistics purposes.
|
|
|
Post by Jos on Oct 18, 2019 11:33:28 GMT 1
Ok, start vDos.exe /log at a workstation and post (or email me) the vDos.log file. Mind, it’s a hunch to why/how those page fault errors get triggered. FoxProX reserves some starting extended/XMS memory when running in NTVDM, so that WOULD explain how an external program can mess up (overwrite) virtual paging directory tables in vDos, but doesn't in NTVDM.
Jos
|
|
kerry
I need to start 2 different programs at different times in same directory. How do I config autoexec.
|
Post by kerry on May 5, 2021 18:59:57 GMT 1
Page fault errors have been around since vDos supports virtual memory paging in protected mode as used by FoxProX (PharLap DOS extender). It means the program is referring a virtual memory address for which no directory or table entry is setup by the program. The vDos download page states: “Long awaited fix of the occasionally (and illusive) Page Fault errors with FoxProX”. And I thought they were finally fixed with version 2019.05.01. It surely doesn’t occur as frequent as before, but you’re the third to report they still exist. I did meanwhile find an extremely rare situation that could cause a page fault. But fixing that didn’t resolve it either (for the one who tested). A page fault forces vDos to shut down since it can’t resolve the given virtual address to a linear one. When vDos is restarted, it (of course) has no knowledge of previous page fault errors in a different instance. So there’s no vDos related “Once it occurs it happens every time after. For now you simply have to live with that error. I suppose you don't start a second FoxProX program from inside the first one. Jos I see, is there any way that I can provide any help with diagnosing the issue or finding the source? seeing as it seems to be rather random as to when it occurs and nothing is being logged in the log file other than "Unable to open file" when it is trying to write data to a CSV of about 1.4MB in size?
|
|
|
Post by Jos on May 5, 2021 19:37:47 GMT 1
Page fault errors should be a thing of the past. You’re experiencing this with what vDos version?
Jos
|
|