>You may be logged in as Admin, but you DO NOT HAVE ADMIN rights. You still have to elevate to do anything in Windows or Program Files, install software, update primary registry. I think Lutz was exactly right. You need to put FoxUser in different location.
>
>>Hmmm... you may have put your finger on something there. But I'm the only user on the machine, logged in as Admin. Doesn't Windows reroute everything in "legacy" apps running in Program Files to Program Files(x86)? And if so, the foxuser file should get updated there, right?

OK, so the VFP desktop icon is set to "Start in" C:\Foxuser70\. The CONFIG.FPW file there has these lines:

SCREEN=OFF
resource=C:\FOXUSER70\foxuser.dbf
editwork=C:\FOXUSER70\
sortwork=C:\FOXUSER70\
tmpfiles=C:\FOXUSER70\
overlay=C:\FOXUSER70\ OVERWRITE
progwork=C:\FOXUSER70\
exclusive=off
default=C:\FOXUSER70
mvcount=65000
CATMAN=OFF
TITLE=CSST
DEFAULT="C:\PROJECTS\CSST\"
COMMAND=DO start

The Start program includes the line

SET RESOURCE TO C:\FOXUSER70\FOXUSER.DBF

I did a global search on the entire C: drive looking for other instances of CONFIG.FPW and edited all of them that could possibly have any relevance to the same "Resource=" line shown above. Starting and closing VFP sure enough updates the file date/time on the C:\FOXUSER70\FOXUSER.DBF file. But.... There is also a FOXUSER.DBF, _command.prg, foxcode.dbf, and foxtask.dbf in the C:\users\administrator\AppData\Roaming\Microsoft\Visual FoxPro\ folder. Those files remain after VFP has been closed. Copying the C:\Foxuser70 files to that folder and vice versa neither have any beneficial effect. Neither does deleting them altogether. I'm still not retaining Command window or debugger breakpoint history between VFP sessions. So I thought about uninstalling and reinstalling VFP in some folder outside of Program Files, but I hate to think about all the other possible places THAT could cause code to break. Anybody have a quick fix?