Has anyone seen the following bizarre startup problem with Visual Studio
.NET (2002)?

I'm not looking for educated guesses, since I've already tried them.  I'm
looking for someone who has actually seen this problem and knows its cause.

Symptom:

On launching Visual Studio, you get to the opening screen, but the toolbars
at the top are not fully populated with icons.  Instead, there are about
five little windows open in front of it, with no content in particular (one
of them seems to be a row of toolbar icons and the rest are little squares).
If you persist, you find that you can't read the help files.  We have not
had anyone actually try to compile a program.

Circumstances:

This happens only to *roaming* users on our XP client workstations.  Any
local user account can use Visual Studio without any trouble.  If a roaming
user is added to the local Administrators group, Visual Studio works just
fine, but this is obviously not a safe thing to do routinely.  Adding a
roaming user to the local Users group is not sufficient.

Local users do *not* have to be Administrators in order to use Visual Studio
effectively.  Even Guest can do it.

The problem apparently has to do with permissions, but I can't tell what's
going on.  I can't even find a significant difference in the group
memberships of the local and roaming users!  So how could there be any
difference in permissions?

The only difference is that the local users belong to a group called "\None"
that is visible when you type "ifmember /list" (a Resource Kit tool) but not
visible in Active Directory Users and Computers.

When the problem appeared:

When we installed Visual Studio .NET Professional (2002) (1/8/2002 date on
directories).  (We also installed Office XP Professional at the same time,
from what we thought was a newer distribution, but it may have been older.
Then we updated Office on line.)

Previously, I had installed VS .NET Academic (2002) (1/31/2002 or somesuch
date) on one workstation and it worked fine with roaming users (see also the
items noted before).

I am now in the process of going back to that installation, to see if it
fixes things.  I hope it does!

Some non-cures:

- We already set Local Intranet to FullTrust.  That was necessary with the
previous setup, so that roaming users can run .NET executables on the server
disk drive.

- We already made domain\Authenticated Users a group member of
local\Debugger Users, so that roaming users can run the debugger.  This,
too, worked with the previous setup.

- Service Pack 2 for .NET 1.0 didn't have any effect on the problem.

Has anyone seen this exact problem, or something *very* closely resembling
it?  Note that there is NO ERROR MESSAGE when Visual Studio starts up
incorrectly -- just a strange and defective IDE.

Thanks,

Michael A. Covington - Associate Director
Artificial Intelligence Center, The University of Georgia
http://www.ai.uga.edu/~mc