I'm having a difficult time explaining the following behavior:

A. User1 launches EXE (default "Hellow World!" C++.NET Console App) from a
Command Line on Computer1 and "Hello World!" is returned almost immediately.

B. User1 launches same EXE from Command Line on Computer2 and achieves same
results ("Hello World!" returns nearly immediately).

C. User2 (or any other user for that matter) launches same EXE from Command
Line on Computer1 OR Computer2 and the return of "Hello World!" is delayed by
3+ seconds.

What could be the cause of a single user achieving "fast" EXE launch times,
with all other users receiving slow launch times? What differences should I
be looking for? And, which is the expected "norm" (the immediate return of
"Hellow World!" or the delayed return)?


Some info about the test environment:
- Computer1 and Computer2 are both Intel dual-core of recent vintage w/ 1GB
RAM and no load to speak of. Both run Windows XP w/ all latest Service Packs
and hotfixes available from Windows Update. Both connect to same LAN and
participate in same 2003-based AD Domain. Installed software is same on both
computers, including .NET Framework 1.1 w/ latest updates from Windows Update.

- User1 and User2 are both AD Domain User accounts. Both have membership to
the same Domain and Local Groups. Both have same GPOs applied.

- Visual Studio 2003 is being used to compile test program. VS is isntalled
on both Computer1 and Computer2.

Performing some network traces under various conditions illuminated the
following:

User1 (experiencing "fast" EXE launch times) had access to the following
files: "security.config", "security.config.cch", and "security.config.old"
all at the following path: "%USERPROFILE%\Application Data\Microsoft\CLR
Security Config\v1.1.4322\".

Those files and that path were completely nonesxistent for all other users
(the ones experiencing "slow" EXE launch times). In those cases the
"%USERPROFILE%\Application Data\Microsoft" directory existed, but not "CLR
Security Config" and the directory or files below. Therefore, the "slowness"
was due to a timeout where the path/files did not exist.

Interestingly, disconnecting the user from the network (by unplugging the
Ethernet cable from the computer) resulted in an even LONGER timeout upon
first execution w/o the network, but after that execution speeds were as fast
as User1, because the system auto-built the missing path/files. Plugging the
computer back into the network showed the "slowness" problem to be completely
resolved.

Keep in mind we use roaming profiles, redirected folders, and offline
synchronization. Thus, our AD Domain policies might be considered complex.
Still, I have to scratch my head as to why the necessary CLR security config
path/files aren't created for each user upon first login??? I'm wondering if
this isn't a very subtle design flaw on MS's part??? If anyone at MS cares
to go over in more detail, I'm more than happy to explain additional details.

Thanks.

"mhetherington" wrote:

MS: Here's a link to a person having a similar experience:
http://www.msnewsgroups.net/group/mi...topic6676.aspx

"mhetherington" wrote: