>I have a VFP application that runs fine on a wide variety of systems, mostly XP Pro, but one Vista and one Win7. The problem is that on one of the XP systems the application has gone from taking less than 2 seconds to load to taking over 12 seconds to load and as much as 30 seconds, then it is dead slow once it is running.
>
>It used to run fine on this machine which is a 2.53 GHz Dell Optiplex GX280 with 1 GB RAM and a Celeron processor. They have a nearly identical GX280 that has no problems, but has not been rebuilt.
>
>A nasty rootkit invaded the machine and trashed the system. I wiped the HD and reinstalled the system from scratch. A few weeks later the HD crashed and I installed a new HD, restoring the system from a recent backup. Since then the application has been dead slow. My client isn't sure whether the slowdown started before or after the new HD was installed, but my tests indicate the problem is not the HD. I spent a great many hours trying to figure this out to no avail. Everything else, even including QuickBooks, starts and runs just fine.
>
>They just bought a new system to replace this one and wanted to cycle this one down to replace an even older XP box that is maxed out at 512 MB of RAM, so I again reinstalled the system from scratch. Same problem. So, I reinstalled XP Pro SP3 again, installed no updates or drivers nor other software at all and did not join the domain. I put a copy of the FoxPro database on the local machine, installed the app and it is still dead slow.
>
>Now for the really weird part: I accidentally discovered during this process that if I log on as soon as possible during the boot and immediately start the app before the system finishes all its startup stuff, the application springs up in under 2 seconds like it does on all the other machines. If I exit and restart, it is slow again. If I reboot and wait for the boot and logon to finish accessing the HD the app is slow. Turning everything off in MSConfig changes nothing. If I run Task Manager while loading the app it shows the processor idle 98% to 99% for nearly all of the program startup. I've run ProcMon and see nothing unusual in the process and the profile looks very similar to the profile on yet another similar, but older GX280, although I have not compared the thousands of events line-by-line.
>
>The startup of the application is fairly simple and straightforward without any authentication or network access required in my test setup. Based on the icon appearing in the taskbar, the disapearance of the VFP menu, the appearance of the splash screen and the appearance of the app's menu, the whole process is slow. It is not a single bottleneck.
>
>Any suggestions would be appreciated. My clients have a lot of GX280's and I am now dreading rebuilding any of them.

A few things I can think of (in no particular order):

1. Many, if not most, Dells use drivers for motherboard chipset and/or IDE disk I/O. My understanding is that if you don't install these drivers, performance and reliability are reduced.

2. Somewhat related to the above - if you have time to try another rebuild, and your Dell came with a "system restore" CD, it might be worth restoring from that, then testing your VFP app. That restore would return the system to its "factory-fresh" configuration, including any Dell-specific tweaks.

3. Based on the "really weird" part you describe, it sounds like a process that gets loaded at system startup is causing the slowness. The two most likely candidates are:

a) Antivirus. If you have any installed, try uninstalling it completely (disconnected from the network if you're nervous about infection). If that fixes it, install Microsoft Security Essentials and see if the problem persists.

b) Malware infection. Some malware is so pernicious it loads from the boot sector of a HD, and in some cases can't even be removed by partition management tools. Now, if you've completely replaced a HD that *should* defeat malware, but I'm concerned you may have restored an infected backup. If you haven't already done so, I'd recommend downloading and running ComboFix from bleepingcomputer.com - it's the best single tool I know for checking for malware.

4. Does the VFP app require access to any resources that other programs don't? For example, maybe it's the only program that requires access to data files shared on a server. In that case, maybe your problem is a network configuration issue. Something as simple as setting the workstation's DNS server to be your ISP's DNS server(s) can cause massive slowdowns. For Windows domains, workstation DNS should always be the domain controller, and for peer-to-peer networks should probably be the router.

5. Do you notice any events occurring in either the System or Application event logs while your application is trying to start?

6. Hopefully you're not using wireless networking for a multi-user VFP application?

7. Are you setting your VFP app's temp files folder to a local folder, that actually exists?

8. (arcane) I think there are some circumstances where a VFP app will slow down/time out if an expected printer either isn't installed on the system, or is "offline". For example, previewing or printing a report, or *maybe* some graphics-related operations.