>Using ProcMon and starting the app at different times during logon,I have now confirmed that the difference is when a few Logon operations toward the end of logon processing are not yet completed, then the app pops up in about 2 seconds. After these operations, which take about 0.5 seconds to complete and are REALLY hard to catch manually, the app comes up like a lazy dog. After logon seems to finish, the app takes about 33 seconds to load. (ProcMon adds a lot of overhead. Without ProcMon, running on a bare-bones system with MSConfig disabling everything possible, I can only estimate the times to be about 0.5 seconds before the "deadline" and about 13 seconds afterward, a ratio similar to that measured via ProcMon.)
>
>What I can see from ProcMon logs is that the winlogon.exe process seems to do some things with COM and OLE at the end of the logon process. I don't know what else it might do in that bit of time that I can't see in ProcMon. There is also a lot of security processing by the lsass.exe processes and an as-yet-unidentified svchost.exe process in that same brief time frame. The winlogon process appears to finish its startup very shortly after this.
>
>I have spent a lot of time now with ProcMon and Excel analyzing two runs, one fast one before winlogon finishes and one slow one after winlogon finishes. To get ballpark figures on timing for the app, I took the time between recorded ProcMon events for the app as the time to process the operation. Since the startup of the app in both cases had very few events from other processes during the app startup and those were clustered rather than distributed, I think this is a good rough estimation for comparison purposes of how long various operations took.
>
>To my surprise, one operation alone appears to account for essentially the whole difference. "CreateFile" operations appear to take about 48 times as long on average for the slow start as for the fast start, accounting for approximately the full 30 second difference! Further examination of those operations reveals that a disproportionately large share of operations that result in "PATH NOT FOUND" accounts for nearly all of that time, over 92%, averaging 90 times as long for the slow start compared to the fast start.
>
>"NAME NOT FOUND" results take about 10 times as much time, but accounts for only 7% of the difference. "NAME INVALID" takes about twice as long. "SUCCESS" results take 15% less time.
>
>Looking at the ProcMon log in greater detail, it appears these "PATH NOT FOUND" results are VFP searching its usual paths for files that are in the exe, such as libraries and programs. (Apparently the "CreateFile" operation occurs when VFP is looking for existing files/directories, not necessarily creating them. Perhaps this represents attempts to create file HANDLES, rather than create files?) The only slightly more numerous "ReadFile" operations actually took 18% less time for the slow load compared to the fast, which is reasonable since the disk is much less active at that time.
>
>It is still a mystery to me why NOT finding a file or path would take SO MUCH longer after logon processing finishes when actually finding and reading takes noticeably less time.
>
>...Jim

A nonexistent directory in your path setting can slow down a system like you mention. Or if one of the directories has a huge number of files.