MS Critical Update #822925 Breaks Visual Studio .NET

[GOOD SOLUTION]

Here's a way to fix this. It does NOT require a reboot.
And it does NOT drastically reduce security as the other,
albeit useful, fix does.

SOLUTION (for now):

PROBLEM: The ASP.NET process runs under the "ASPNET"
local user account. After installing the updates, it is
required that the ASP.NET process have read access to the
folder:
\Documents And Settings\LocalService\Local
Settings\Temporary Internet Files

I don't know why it needs those rights, or if it will in
the future, but for now, here's the fix.

SOLUTION:
1. Yes, you can have the ASP.NET process run as SYSTEM,
but this is a SERIOUS security issue.
2. Better, and simpler, is to give the ASPNET account the
permissions it requires. Below I will outline how to
implement this.

FIX:
1. Open Windows Explorer, navigate to
\Documents and Settings
2. If the "LocalService" directory is NOT visible, you
need to choose "Folder Options" from the "Tools" menu.
Then you need to ensure that under the "View" tab,
protected OS files are NOT hidden!
3. Continue on to
\Documents and Settings\LocalService
4. Right-click on the "Local Settings" folder, then
select "Sharing and Security".
5. In the "Security" tab, "Add" the "ASPNET" user, and
make sure it has "Read" and "List Folder Contents"
permissions.
6. "Apply", "OK", .... etc until all windows closed.
7. That's it.

 

[Peter Palmieri]

Here's a way to fix this. It does NOT require a reboot.
And it does NOT drastically reduce security as the other,
albeit useful, fix does.

SOLUTION (for now):

PROBLEM: The ASP.NET process runs under the "ASPNET"
local user account. After installing the updates, it is
required that the ASP.NET process have read access to the
folder:
\Documents And Settings\LocalService\Local
Settings\Temporary Internet Files

I don't know why it needs those rights, or if it will in
the future, but for now, here's the fix.

SOLUTION:
1. Yes, you can have the ASP.NET process run as SYSTEM,
but this is a SERIOUS security issue.
2. Better, and simpler, is to give the ASPNET account the
permissions it requires. Below I will outline how to
implement this.

FIX:
1. Open Windows Explorer, navigate to
\Documents and Settings
2. If the "LocalService" directory is NOT visible, you
need to choose "Folder Options" from the "Tools" menu.
Then you need to ensure that under the "View" tab,
protected OS files are NOT hidden!
3. Continue on to
\Documents and Settings\LocalService
4. Right-click on the "Local Settings" folder, then
select "Sharing and Security".
5. In the "Security" tab, "Add" the "ASPNET" user, and
make sure it has "Read" and "List Folder Contents"
permissions.
6. "Apply", "OK", .... etc until all windows closed.
7. That's it.

This one didn't work for me, unfortunately. Running the process as SYSTEM
does. This is only my local development machine, so I guess I'll leave it
that way until more info is available.