>>>Question 1: Does that look ("feel") normal to you? Any suspicions?
>>>Question 2: Since I uninstalled these completely, shouldn't these keys have disappeared?
>>
>>No idea. You've got more patience or Merlot than me. I would have formatted that sucker hours ago.
>
>Haha! I laughed out loud when I read your last reply. After a long day of head scratching, I needed it. I think I have both -- lots of patience and lots of Merlot. Or course, any red will do.
>
>I said I'd do it and so here it is ... what I did to make the problem go away. I don't know who else will read this but hopefully, the next soul that runs into anything like what I just did will at least be able to read to the end of this thread and arrive at some kind of resolution ... however correct or incorrect it may be.
>
>Thanks again Evan.
>
>Here's what I did to get rid of the inability to run my on EXE's.
>
>1. Deinstalled Visual Studio completely.
>2. Defraged disk.
>3. Ran regedit and searched for all instances of "Visual.Foxpro.Application.6" or "VisualFoxpro.Application.6" (without the period between "Visual" and "Studio") and determined the CLSIDs. Then, deleted all references to CLSID 008B6020-1F3D-11D1-B0C8-00A0C9055D74. That corresponded to "Visual.Foxpro.Application.6"
>4. Changed value of HKEY_CLASSES_ROOT\Visual.FoxPro.Application\CLSID to VFP5's (0002C401-0000-0000-C000-000000000046)
>5. Searched for all instances of VisualFoxPro.Runtime.6 and determined its CLSID to be 008B6021-1F3D-11D1-B0C8-00A0C9055D74. Then deleted all references to this CLSID and the test "VisualFoxPro.RunTime.6.
>6. At this point, I ran into a little problem when the registry couldn't delete a couple of references but closing regedit and reopening it made the problem go away. Specifically, I couldn't kill two references to VisualFoxPro.RunTime.6 occurring in HKEY_LOCAL_MACHINE\SOFTWARE\CLASSES\VisualFoxPro.Runtime.6 I'm beginning to suspect that ONE of these Runtimes got in via a dummy project I created and installed for the express purpose of getting the runtime engine in place. I ran it. Later, and I don't remember how much time passed, *something* got crosswired and that's sort of when things starting acting funny. My suyspicion is that the registry got out of sync.

What you encountered was probably behavior due to using the wrong registry tool for NT. HKEY_CLASSES_ROOT is actually duplicated under HKEY_LOCAL_MACHINE\SOFTWARE\CLASSES - the two seemingly separate registry subtrees are actually just references to the same hive - HKLM\SOFTWARE\CLASSES is an alias. You used REGEDIT, which doesn't properly handle hive aliasing under NT - there's a separate tool, REGEDT32, which should be used with NT and Win2K. The choice of tool is very important in situations where remote registries or roaming hives are involved; REGEDIT does not fully implement ACL services for the registry.

>7. After all of this, miraculously, my EXE could run again ... although I had deinstalled Visual Studio completely before I started all of this, VFP6r.dll, VFP6rend.dll and VFP6run.exe were left in \WINNT\SYSTEM32 by the uninstalled. (I would have thought that uninstaller would have taken these out.)
>8. Reboot.
>9. Reinstall Visual Studio. Reapply Service Pack 3.
>10. Checked registry again and the CLSID I manually deleted in Step 3 is back again (008B6020-1F3D-11D1-B0C8-00A0C9055D74).
>11. Try to run own EXE's.
>12. Life is good again. Champagne starts to flow.
>
>I'm not sure which bit of what madness did the trick, but if this happens again, I'll be sure to try this before biting the reinstall Windows bullet. I've not fully tested every proper working of VFP but am satisfied that this part is done now. If anything starts acting weird, I know I'm on my own. Still, this may benefit someone else. Thanks again for all your help.