.Net Framework 3.5 SP1 leftover folders

  • Thread starter Thread starter Lars918
  • Start date Start date
L

Lars918

During installing the .Net Framework 3.5 SP1 package, a folder on the root of
C:\ is created that does not get removed after installation. This folder
name is a long random string of characters that varies from machine to
machine but includes an AMD64 folder and an I386 folder which include
MSXPSINC files. I will be deploying this to a large number of XP SP2 clients
and will need this folder to be removed after installation. Any idea why
this folder does not get removed?
 
This is a temporary folder created during the install process and is located
on the drive or partition with the most available disk space.
It is normally deleted during the final stages of the install process, but
when the installer says it has completed it really has not and is still in
the process of finishing up.

Suggestion: When the Installer has completed and if you are or are not asked
to reboot, wait until
a process named "NGEN" has completed before rebooting the PC. Use Windows
Task Manager to monitor the CPU usage and when Ngen has completed it's task
the "System Idle Process" should be at or near 99%. Hard disk activity will
also be heavy until Ngen has finished. After Ngen has completed installing
..Net then reboot the computer.

For more info see: Framework Tools: Native Image Generator (Ngen.exe)
http://msdn.microsoft.com/en-us/library/6t9t5wcf(VS.80).aspx

Newer versions of .Net make use of a process named "mscorsvw.exe" during the
installation of .Net. The mscorsvw process like NGEN also continues to run
for a minute or two after you have received the prompt to reboot or a notice
that the installation has completed. You will find that "mscorsvw" uses a
significant percentage of your CPU resources and hard disk activity remains
high until mscorsvw completes its task. After your PC settles down and is
basically idle then reboot if required.

What is mscorsvw.exe and why is it eating up my CPU?
http://blogs.msdn.com/davidnotario/archive/2005/04/27/412838.aspx

mscorsvw.exe and 100% CPU
http://www.dotnetjunkies.com/WebLog/johnwood/archive/2006/04/09/mscorsvw_cpu.aspx
 
After installation, mscorsvw.exe does still show some CPU activity but
waiting for it to complete and then rebooting still leaves the temporary
folder on the root of C:. I also tried running the "ngen.exe
executequeueditems" command and rebooting. This removed mscorsvw.exe from
Task Manager but the folder remains.
 
Have you verified that .NET installed properly?

Temporary files can be left behind after running .NET Framework 3.0 or 3.5
setup
http://blogs.msdn.com/astebner/archive/2008/12/09/9188755.aspx

..NET Framework Setup Verification Tool:
http://blogs.msdn.com/astebner/pages/8999004.aspx
"This .NET Framework setup verification tool is designed to automatically
perform a set of steps to verify the installation state of one or more
versions of the .NET Framework on a computer."

..NET Framework Cleanup Tool:
http://blogs.msdn.com/astebner/pages/8904493.aspx
"This .NET Framework cleanup tool is designed to automatically perform a set
of steps to remove selected versions of the .NET Framework from a computer,
It will remove files, directories, registry keys and values and Windows
Installer product registration information for the .NET Framework. The tool
is intended primarily to return your system to a known (relatively clean)
state in case you are encountering .NET Framework installation,
uninstallation, repair or patching errors so that you can try to install
again."

I used this tool after using the Add or Remove Programs uninstall feature.
After using the Cleanup tool only a few folders and files still remained, so
I deleted these manually.
 
The 3.5 SP1 installation shows as "Product verification succeeded!" when
running the .Net Framework Setup Verification Utility.
 
OK, I'll see if I can duplicate the problem if you can provide the following
information,
1) What Service Pack of Windows are you using (SP2 or SP3)
2) Was NET Framework 3.5 (Without the service pack installed)
3) Any other versions of .NET Redistributables installed.
4) The link to where you obtained .NET 3.5 SP1
I am assuming that you downloaded the full Redistributable and not the
Bootstrapper (Yes/No)
 
I'm assuming the you're installing the Redistributable and not the SDK.
And it's a local PC install and not a network push.
 
Yes, redistributable and local PC install.

JS said:
I'm assuming the you're installing the Redistributable and not the SDK.
And it's a local PC install and not a network push.
Click to expand...
 
..NET Redistributable 3.5 SP1 Results:
Several temp folders remain after Setup has completed
but before you click the 'Exit' button.

After pressing the 'Exit' button in the Setup window,
you will be prompted to restart the PC.
These temp folders (3) remain until you click on
the 'Restart Now' button.

After rebooting one of the three folders is still
present and is not deleted as you originally observed.
The contents are also as you mentioned.

Note: These temporary folders are created on the drive
or partition that contains the most free space. In my case
this was my K: partition.

Microsoft .NET Framework 3.5 Service Pack 1 (SP1) Readme:
http://download.microsoft.com/downl...-4B66-9B31-9205C3F22252/dotNet35SP1Readme.htm

In the above article it mentions using 'Disk Cleanup'
to remove temporary files but did not work for me.

Looks like you have spotted a bug with 3.5 SP1
 
Here's additional info on what I found.

As you already know, there is an undeleted temporary folder
left behind after installing Net Framework 3.5 SP1

The folder name is a series of random letters and numbers
but it has readily identifiable subfolders:
C:\c8b4800dc02b4bb681\amd64
C:\c8b4800dc02b4bb681\i386
There are 7 files each folder all having the same name
but the version numbers for the .dll file are not necessarily
the same.

A search for these files in on the drive or partition where
Windows is installed shows that they are also found in
the C:\WINDOWS\system32 folder or subfolders and
the C:\WINDOWS\Driver Cache\i386 folder. The creation
dates match the time when .NET 3.5 SP1 was installed.
So the temporary folder can safely be deleted.

There is also a registry entry you can find if you enter
the name of the temporary file in the 'Find' field.
HKLM\SOFTWARE\Microsoft\Updates\Windows XP\SP4\KB954550-v5\Filelist

This is part of KB954550-v5
They are associated with the XPS (XPSEPSC) drivers.
For some reason Microsoft has no documents that I
could find for this KB number and there is not much
to find when searching the Internet either.

Also:
Scenarios where .NET Framework 3.5 setup
tries to connect to the Internet and how to avoid them
http://blogs.msdn.com/astebner/archive/2008/07/17/8745415.aspx
 
Hi,

I'm also getting the same problem... but in my case
the registry key where its located is named KB954550-v7

And by default I don't have permission to access the folder I386 and AMD64
in the "temp" folder.

I can always take ownership of the files and folders and delte them
afterwars....

But I was wondering if you found a more elegant way to fix this problem...
thanks
 
First off all of these answers are not the solution to the problem.

The .net 3.5 framework install contains a bug that doesnt allow it to remove temporary folders at the next reboot.

if you look at the pendingfilerenameoperations value:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations

you will see after installing the framework that only one entry is written to remove these files, assuming by M$ that it will remove the whole folder which it DOES NOT.

First problem is that the files have all rights removed to them except for 'SYSTEM' : Full Control.

What you need to do (presuming you are installing from a command line) is integrate the new TAKEOWN.EXE from Windows Server 2003 / Vista into your script (I copy it into the SYSTEM32 in our build)

Then I do a search for the file 'mxdwdrv.dll' to obtain the directory which it resides in off of the C drive (and I exclude the WINDOWS directory). Run TAKEOWN against that directory and then nuke the file structure.

Sample Code:
--------------
Dim WshShell : SET WshShell = CreateObject("WScript.Shell")
Dim oFSO : SET oFSO = CreateObject("Scripting.FileSystemObject")

'Launch the framework installer
WshShell.Run "dotnetfx35.exe /qb /NORESTART", 1, True

'Find mxdwdrv.dll
'not in C:\WINDOWS, mark that directory for deletion and reset the perms
'*********
Dim colFSOSubFolders
Dim DeleteFlag
On Error Resume Next ' this is set because the designated file may be locked from deletion
Set oFolder = oFSO.GetFolder("C:\")
Set colFSOSubfolders = oFolder.Subfolders
For Each objSubfolder in colFSOSubfolders
DeleteFlag = "TRUE"
'if it found it in WINDOWS then ignore it
if ucase(objSubfolder.Name) <> "WINDOWS" then
if oFSO.FileExists("C:\" & objSubfolder.Name & "\i386\mxdwdrv.dll") then
'ok this subfolder name is what I need to go after
WshShell.Run "takeown /f " & "C:\" & objsubfolder.name & " /r /a",1,True
WshShell.Run "Cmd /c del C:\" & objsubfolder.name & "/s /q",1,True
WshShell.Run "Cmd /c rd C:\" & objsubfolder.name & "/s /q",1,True
oFSO.DeleteFile "C:\" & objSubfolder.Name & "\" & FileToDelete,TRUE
end if
end if
Next

Not the most elegant solution but M$ obviously isn't going to go in and fix it.

NOTE: The code above was cut from a larger script so you should make sure that any variables are declared etc.
 
I found a very simple solution to removal of leftover files.
Drag & drop the files in c:\{random_string}\AMD64 & c:\{random_string}\i386 into SpybotSD's Secure Shredder then Chop 'em away!
After that c:\{random_string} with subfolder can be simply deleted within an Explorer window.

Worked for me on Win XP64 Pro & Win XP32
 
Back
Top