Partilhar via

Mailbag: Temporary files can be left behind after running .NET Framework 3.0 or 3.5 setup

  • Artigo

Question:

I have tried to install the following versions of the .NET Framework on various different computers running Windows XP or Windows Server 2003:

  • .NET Framework 3.0
  • .NET Framework 3.0 SP1
  • .NET Framework 3.5
  • .NET Framework 3.5 SP1

In some cases, I have noticed that a folder gets left behind on the root of one of my drives.  The folder has a randomly generated name, and it contains a copy of the setup files used to install the .NET Framework.

I do not see this behavior for the .NET Framework 1.0, the .NET Framework 1.1 or the .NET Framework 2.0.

Why is this folder left behind at this location after installing these versions of the .NET Framework?  Can I safely delete this folder after I install the .NET Framework?

Answer:

The installers for the .NET Framework 2.0 and earlier uses a legacy self-extracting EXE technology called IExpress.  That technology creates a folder in the %temp% directory named something like IXP000.tmp (it will increment the number if a folder with this naming pattern already exists).  Then it extracts the contents of the EXE to that folder and runs the setup EXE from within that folder.  After the setup EXE completes, it will attempt to delete that folder.

The installers for the .NET Framework 3.0 and later use a different self-extracting EXE technology, which is why you have observed different behavior depending on what version of the .NET Framework you are trying to install.  The self-extracting logic for these versions of the .NET Framework does the following:

  1. Find the drive on your system with the largest amount of free disk space
  2. Create a randomly named folder on that drive
  3. Extract the contents of the EXE to that folder
  4. Run the setup EXE from within that folder
  5. After the setup EXE returns, attempt to delete that folder

One of the prerequisite packages for the .NET Framework 3.0 and higher - the XML Paper Specification (XPS) Shared Components Pack 1.0 - has a problem that causes the randomly named folder that it creates to fail to be deleted in step 5 above.  Those files are temporary and only needed during the initial installation of this component, so it is safe to delete this randomly named folder if it ends up getting left behind on your system after .NET Framework installation completes.

I have heard of a few cases where attempting to delete the randomly named folder fails with a permission problem.  I am not sure what causes that type of permission problem in the first place, but you will need to manually update the permissions on that folder in order to be able to delete it.  Tools such as Cacls or SubInAcl could be useful to update these permissions if you run into this issue.

The XPS component is only installed by the .NET Framework setup package on Windows XP and Windows Server 2003, so the issue where this folder gets left behind at the end of .NET Framework setup will not affect newer operating systems such as Windows Vista, Windows Server 2008 or Windows 7.

<update date="12/21/2009"> Added more specific information about the root cause of this problem (the XPS setup package that is chained in during .NET Framework 3.0 and higher setup on Windows XP and Windows Server 2003). </update>

Comments

  • Anonymous
    May 29, 2009
    Hi, How can I delete those temp folders automaticly? I have around 600 servers in me environment so I won't do it manually on each server. Or, Is is possible do find a way to install .Net Framework 3.5 SP1 and not getting those temp folders. Thanks

  • Anonymous
    June 01, 2009
    Hi Blakedue - You would have to write a tool/script to clean up the folders afterwards if you need them to be removed.  The folders have randomly generated names, so your tool would need to look for folders at the root of the drive letter with the largest amount of free space, then check inside the folder to see if it is from .NET Framework 3.5 SP1 setup, and if so, delete the files and folder. If you would like to avoid the folder being created in the first place, you can pre-install the XPS package before running the .NET Framework 3.5 installer.  Here are the download locations: For the x86 XPS package - http://go.microsoft.com/fwlink/?LinkId=123098 For the x64 XPS package - http://go.microsoft.com/fwlink/?LinkId=123099

  • Anonymous
    November 26, 2010
    Hi, This randomly named folder is also referenced all over the registry... is it safe to delete the folder and leave all registry references to it? TH

  • Anonymous
    November 28, 2010
    Hi TH - There are a few different cases I know of where temporary files can be left behind like this.  What are the exact files that you see listed in your registry, and what locations do they appear at in your registry?

  • Anonymous
    November 28, 2010
    Hi astebner, So the folder is always randomly named... in one case it is: D:�9cb04b43b693cd9fa19 then when searching through the reistry this location is referenced in the following keys: HKLMSoftwareMicrosoftUpdatesWindows Server 2003SP4KB954550-v5Filelist� The key is:Location The value is: d:�9cb04b43b693cd9fa19update..amd64 HKLMSoftwareMicrosoftUpdatesWindows Server 2003SP4KB954550-v5Filelist1 The key is:Location The value is: d:�9cb04b43b693cd9fa19update..amd64 HKLMSoftwareMicrosoftUpdatesWindows Server 2003SP4KB954550-v5Filelist10 The key is:Location The value is: d:�9cb04b43b693cd9fa19update..i386 HKLMSoftwareMicrosoftUpdatesWindows Server 2003SP4KB954550-v5Filelist11 The key is:Location The value is: d:�9cb04b43b693cd9fa19update..i386 HKLMSoftwareMicrosoftUpdatesWindows Server 2003SP4KB954550-v5Filelist12 The key is:Location The value is: d:�9cb04b43b693cd9fa19update..i386 HKLMSoftwareMicrosoftUpdatesWindows Server 2003SP4KB954550-v5Filelist13 The key is:Location The value is: d:�9cb04b43b693cd9fa19update..i386 HKLMSoftwareMicrosoftUpdatesWindows Server 2003SP4KB954550-v5Filelist14 The key is:Location The value is: d:�9cb04b43b693cd9fa19update..i386 HKLMSoftwareMicrosoftUpdatesWindows Server 2003SP4KB954550-v5Filelist2 The key is:Location The value is: d:�9cb04b43b693cd9fa19update..amd64 HKLMSoftwareMicrosoftUpdatesWindows Server 2003SP4KB954550-v5Filelist3 The key is:Location The value is: d:�9cb04b43b693cd9fa19update..amd64 HKLMSoftwareMicrosoftUpdatesWindows Server 2003SP4KB954550-v5Filelist4 The key is:Location The value is: d:�9cb04b43b693cd9fa19update..amd64 HKLMSoftwareMicrosoftUpdatesWindows Server 2003SP4KB954550-v5Filelist5 The key is:Location The value is: d:�9cb04b43b693cd9fa19update..amd64 HKLMSoftwareMicrosoftUpdatesWindows Server 2003SP4KB954550-v5Filelist6 The key is:Location The value is: d:�9cb04b43b693cd9fa19update..amd64 HKLMSoftwareMicrosoftUpdatesWindows Server 2003SP4KB954550-v5Filelist8 The key is:Location The value is: d:�9cb04b43b693cd9fa19update..amd64 HKLMSoftwareMicrosoftUpdatesWindows Server 2003SP4KB954550-v5Filelist9 The key is:Location The value is: d:�9cb04b43b693cd9fa19update..amd64 For every server its a different random folder names and then its refenced in these registry keys... Let me know if it would help ou if I supplied the value of the FileName Key in each of the locations above. what I dont want to do is delete this random folder and have all these entries in the registry still there, referencing a location that I have deleted.... doesnt seem like good practice, especially on a Terminal Server. The other option I guess is too just run the XPS package before installing .Net 3.5 SP1?

  • Anonymous
    November 29, 2010
    Hi TH - If you want to eliminate these temporary files, I think the cleanest option would be for you to run the XPS installer before installing the .NET Framework 3.5 SP1.  If that isn't an option, I believe it would be safe to remove those registry keys in addition to removing the temporary files.

  • Anonymous
    November 29, 2010
    Hi astebner, thank you very much for your assistance... That is the plan then, to run the XPS installer beforehand :)