>Al,
>
>1. The DNS question: The machines in question are in a WinNT domain, and one of the machines in question is a laptop that is not currently in the domain. Do you still think that pursuing DNS is appropriate?
>
>2. I tried turning off write caching. And the error that I am seeing changed. In fact, that has been one of the confusing thing about this bug. When I do something like add some debug output, the error changes. But, this is very specific. The original error I had was in the txtbtns.setallprop method. This is the routine that goes through the entire form and enables/disables all of the controls. I was seeing a "Not an object" message from this method during form initialization, i.e. when the form was starting up. However, if I change something, that error goes away, and I get a different error but, from the same control, NavBtns. This time when the form is shutting down. An error from NavBtns.Destroy()about an alias not found.
>
>If this were a C/C++ program I would suspect an errant pointer. Or maybe a problem with insufficient stacksize. Seems to me that the code is getting corrupted somewhere.
>
>I certainly would appreciate any further thoughts on how to debug this.

IMO write caching is a bit of a red herring in your case. You're reading the .EXE from a local HD so there aren't any inter-machine synchronization issues. However, I don't know what to make of the fact you're getting a different error with caching disabled.

I think setting up DNS as per the KB article might be worth a try, if that's possible in your environment. Another thing to check would be that the server is the network "browse master" and that one or more of the WSs are not set to try to be the browse master. This would be evidenced by entries in the NT Server event log along the lines of:

"The browser has received a server announcement indicating that the computer computer name is a master browser, but this computer is not a master browser."
"The browser driver has forced an election on network parameter because it was unable to find a master browser for that network."

- If the app as running at this time was compiled on a non-Windows XP machine, try recompiling it on an XP box. I seem to recall some subtle problems with different OSs in the past - may not be present now but might be worth a try.

- Try a recompilation with "recompile all files" checked. Make sure the buttons class recompiles without error (and its parent(s), if appropriate). You can also do this with COMPILE CLASSLIB.

- Are all of your users running with Administrator-equivalent privileges on their workstations? If not, try running in that mode to see if it makes a difference.

- Check that your CONFIG.FPW file is pointing the Fox temp files to a folder where the user has full read/write privileges - preferably on the local HD.

- You might want to experiment with the Application Start folder if you're starting from a shortcut - try putting that to a local folder where the user has full privileges if it's not set that way already.

- I have sometimes seen intermittent problems when a workstation has hundreds to thousands of orphaned files in the temp folder (typically C:\Documents and Settings\UserName\Local Settings\Temp). Try cleaning out this folder.

- I assume you've been able to test with all AV disabled (both WS and server) and that you've scanned the problem machines for both viruses/worms and spyware.

- Are there any non-default settings in the XP SP2 firewalls on the WSs?

- If you're in a managed environment, is there any software like SMS present that could be automatically restoring a machine's configuration back to a "pre-VFP9" state, or otherwise undoing configuration or installation changes you've made to support your app?