>>>The only my guess is that for some reason your application cannot see the directory where this prg file resides. In your onerror routine check whether this directory is in the application set(“path”) , and if it is there, then check for existence of this file.
>>
>>The directory exists and so does the file. The only thing that doesn't exist is the drive. The correct drive and directory is on the path.
>
>You answered so quickly, and I am sort of puzzled: could you confirm here that after my last reply you modified your onerror routine in the application, then you rebuilt your application, and distributed it; and the client got an error you are talking about, and your onerror routine made a log file where among other information, the set(“path”) and the value of file() is documented exactly when the error occured? Could you show here all what is in this onerror log file?


No, I didn't change anything - my error routine already records the current path setting and it tries to verify that the file causing the error exists (or not). In this case, however, I'm not getting an error file.

But, we may be going somewhat afield here. A typical scenario is:
1. An error of some sort exists and gets passed thru the chain to the global error handler (I have yet to find out what that error is).
2. The handler calls aStackInfo() to get the program hierarchy.
3. VFP crashes with Suspend, Cancel, etc. buttons with the message "File not found" where the file name is an FXP name.
4. That file's name and path are OK -- only the drive letter is different on the client's system.
5. VFP is, by now, catatonic. If I "suspend" and debug, it's useless.

I'm presuming that, as the drive it displays is from my development system, it could only get that from within the FXP file itself (it's embedded there as a PRG and path). But, why would VFP read that embedded filename? I don't know but I presume there's a good reason. OK, but then, why does it tell me that that file doesn't exist? If it doesn't exist, how could it have read the embedded filename in the first place? Where else could it get a nonexistent drive from?