--
Lady Dungeness
Crabby, but Great Legs!
You can delete these update uninstall folders/files -
Folders that have uninstall as part of the name (for example $NtUninstallKB282010$ which
reside in C:\windows (hidden folders) are Window Hot Fix Update folders/files) can be
safely deleted (providing you never wish to uninstall the updates). I would recommend
leaving these folders for a period of at least a month to make sure the update is working
correctly.
These updates can be deleted individually or in multiples. To find out more about the
update/s go to:
http://support.microsoft.com/?kbid=XXXXXX
NB: XXXXXX = the actual number not including the "Q" or "KB"
Once you have deleted the uninstall folders/files, then go to Control Panel, Add/Remove
Programs. Select the matching Windows Hotfix Title relating the update folder/file you
have just deleted and select remove. You will get a Windows error. This is because you
have deleted the uninstall folder/files. Just choose OK and the entry will be deleted from
the Add/Remove Programs Listing.
--
====================================
TaurArian [MS-MVP] 2005-2008 - Australia
====================================
How to make a good post: http://www.dts-l.org/goodpost.htm
Defending your machine: http://defendingyourmachine2.blogspot.com/
http://taurarian.mvps.org/index.htm
Emails will not be acknowledged - please post to the newsgroup so all may benefit.
"Lady Dungeness" <lady.du...@DavyJonesLocker.net> wrote in message
news:OE2u%231nvH...@TK2MSFTNGP03.phx.gbl...
Lady D
"TaurArian [MS-MVP]" <taurarian...@gmail.com> wrote in message
news:uyR7FXo...@TK2MSFTNGP05.phx.gbl...
--
====================================
TaurArian [MS-MVP] 2005-2008 - Australia
====================================
How to make a good post: http://www.dts-l.org/goodpost.htm
Defending your machine: http://defendingyourmachine2.blogspot.com/
http://taurarian.mvps.org/index.htm
Emails will not be acknowledged - please post to the newsgroup so all may benefit.
"Lady Dungeness" <lady.du...@DavyJonesLocker.net> wrote in message
news:O92VTk5v...@TK2MSFTNGP05.phx.gbl...
Joey
Suggest you delete the $NtUninstallKBxxxxxx$ folders as Taurarian
suggested and clean out the %temp% folders of each User Account.
Delete Temporary Internet Files via Internet Options in the Control
Panel on the General page, too. And, limit the amount of space the TIF
folder holds and have IE delete the TIF after closing the browser.
How to Delete the Contents of the Temporary Internet Files Folder
http://support.microsoft.com/kb/260897
How to Adjust Cache Size for Temporary Internet Files
http://support.microsoft.com/kb/155353
Or, buy a bigger Hard Drive as they are relatively inexpensive
nowadays <w>
MowGreen [MVP 2003-2008]
===============
*-343-* FDNY
Never Forgotten
===============
Moving it temporarily I think will work for me.
Thanks,
joey
If your Windows version is installed on a NTFS partition, maybe you can
create a NTFS junction for the <$hf_mig$> folder to another NTFS drive,
so that you won't have to move it every time. I don't know when the
junction is activated by the system, and especially, if some updates
need to alter the system during boot time, the junction may not work yet.
Can someone confirm it won't bring any problem using a junction for that
folder please ?
--
Tey'
"antanelli" wrote:
>
Description of the contents of Windows XP Service Pack 2 and Windows
Server 2003 software update packages
http://support.microsoft.com/kb/824994
> When a security update, critical update, update, update rollup, driver, or feature pack installs GDR
> version files, the hotfix files are also copied to the %windir%\$hf_mig$ folder. This supports
> migration to the appropriate files if you later install a hotfix or service pack
that includes earlier
> versions of these files. For example, consider the following scenario:
> 1. You apply a security update that installs a GDR version of File.dll with a version number of
> 5.2.3790.1000 and copies a hotfix version of File.dll with a version number of 5.2.3790.1000 to the
> %windir%\$hf_mig$ folder.
> 2. You apply a hotfix that includes a hotfix version of File.dll with a version number of
> 5.2.3790.0000.
> In this scenario the hotfix installation in step 2 installs the hotfix version of File.dll
> (version number 5.2.3790.1000) from the %windir%\$hf_mig$ folder instead of the hotfix version of
> File.dll (version number 5.2.3790.0000) from the hotfix package.
If you need to reclaim disk space, see this:
I want to Save Space and delete unnecessary files after installing a
Windows Update patch or Service Pack.
http://www3.telus.net/dandemar/spack.htm
MowGreen [MVP 2003-2008]
===============
*-343-* FDNY
Never Forgotten
===============
"MowGreen [MVP]" wrote:
> NEVER delete nor compress $hf_mig$. The subfolders contained therein
> determine the branch of an update:
I came across this thread rather belatedly!
I am surprised that no-one has pointed out that many of the files in
$hf_mig$ _can_ be deleted perfectly safely, since they are only duplicates
(apart from different versions) which serve no useful purpose:
$hf_mig$\KBnnnnnn\
spuninst.exe
spmsg.dll
$hf_mig$\KBnnnnnn\update\
update.exe
spcustom.dll
updspapi.dll
eula.txt
- as well as all 'KB*.log' files in the Windows directory and 'KB*.cat' in
system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\
Together with %systemroot%\$NTUninstall KBnnnnnn$\ and _all_ the files in
%systemroot%\SoftwareDistribution\Download, that clears a lot of wasted
space: I have often gained over 600MB on an uncleaned system with ~180
updates.
"Buy a bigger disk" to store more wasted space is a pretty silly suggestion!
Clean up and uninstall everthing you never use* - that lets me fit a
complete ASR backup of my XP SP2 Pro with a very wide range of programs on 1
DVD.
* for example all of the following can be removed (see my site for details):
Movie Maker
Netmeeting
Outlook Express
Microsoft Frontpage
Windows Media Player
Windows Messenger
MSN
Voice synthesis
Microsoft Agent
Wordpad
Communications (unused components)
Games
Accessibility
> NEVER delete nor compress $hf_mig$. The subfolders contained therein
> determine the branch of an update:
I came across this thread rather belatedly!
I am surprised that no-one has pointed out that many of the files in
$hf_mig$ _can_ be deleted perfectly safely, since they are only duplicates
(apart from different versions) which serve no useful purpose:
$hf_mig$\KBnnnnnn\
spuninst.exe
spmsg.dll
$hf_mig$\KBnnnnnn\update\
update.exe
spcustom.dll
updspapi.dll
eula.txt
- as well as all 'KB*.log' files in the Windows directory and 'KB*.cat' in
system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\
Together with %systemroot%\$NTUninstall KBnnnnnn$\ and _all_ the files in
%systemroot%\SoftwareDistribution\Download, that clears a lot of wasted
space: I have often gained over 600MB on an uncleaned system with ~180
updates.
"Buy a bigger disk" to store more wasted space is a pretty silly suggestion!
- one should learn to manage better the space available.
The problem with it is, if a naive User reads it and follows your ABSURD
MISINFORMATION, their XP system will ***NEVER*** be able to install
updates again !!!
In XP, the files in $hf_mig$ are used to determine which *Branch* of an
update should be installed.
" When a security update, critical update, update, update rollup,
driver, or feature pack installs GDR version files, the hotfix files are
also copied to the %windir%\$hf_mig$ folder. This supports migration to
the appropriate files if you later install a hotfix or service pack that
includes earlier versions of these files. For example, consider the
following scenario:
1. You apply a security update that installs a GDR version of
File.dll with a version number of 5.2.3790.1000 and copies a hotfix
version of File.dll with a version number of 5.2.3790.1000 to the
%windir%\$hf_mig$ folder.
2. You apply a hotfix that includes a hotfix version of File.dll
with a version number of 5.2.3790.0000.
In this scenario the hotfix installation in step 2 installs the hotfix
version of File.dll (version number 5.2.3790.1000) from the
%windir%\$hf_mig$ folder instead of the hotfix version of File.dll
(version number 5.2.3790.0000) from the hotfix package. "
Source: http://support.microsoft.com/kb/824994
The Catroot subfolder contains the Security Catalog database which
determines if system binaries are digitally signed. The *lack* of signed
system files is what is causing some XP systems to fail to install
KB971486, the October Kernel update. The KBxxxxxx.cat file is the
digital cert of Security Updates, which is then referenced by the
CatRoot2 subfolder:
Vulnerabilities in Windows Kernel Could Allow Elevation of Privilege
(971486): MS09-058
http://www.microsoft.com/technet/security/Bulletin/MS09-058.mspx
NO XP system should *EVER* have *ANY* contents of the CatRoot subfolder
deleted. *** EVER ***
CatRoot2 can become corrupted and that is the ONLY catroot subfolder
that should *EVER* be deleted.
> (see my site for details)
Why wouldn't anyone believe that when you obviously are *completely
ignorant* on how XP updates ?
MowGreen
===============
*-343-* FDNY
Never Forgotten
===============
banthecheck.com
"Security updates should *never* have *non-security content* prechecked"
"Jim" wrote:
> Leave $hf_mgt$ alone.
Why? - provide specific, concrete reasons other than those already given.
I have done exactly what I said since XP was released and never had a single
problem.
You're post is EXTREMELY DANGEROUS, bitwyse, as it contains INCREDIBLY
WRONG MISINFORMATION !
The problem with it is, if a naive User reads it and follows your ABSURD
MISINFORMATION, their XP system will ***NEVER*** be able to install
updates again !!!
In XP, the files in $hf_mig$ are used to determine which *Branch* of an
update should be installed.
" When a security update, critical update, update, update rollup,
driver, or feature pack installs GDR version files, the hotfix files are
also copied to the %windir%\$hf_mig$ folder. This supports migration to
the appropriate files if you later install a hotfix or service pack that
includes earlier versions of these files. For example, consider the
following scenario:
1. You apply a security update that installs a GDR version of
File.dll with a version number of 5.2.3790.1000 and copies a hotfix
version of File.dll with a version number of 5.2.3790.1000 to the
%windir%\$hf_mig$ folder.
2. You apply a hotfix that includes a hotfix version of File.dll
with a version number of 5.2.3790.0000.
In this scenario the hotfix installation in step 2 installs the hotfix
version of File.dll (version number 5.2.3790.1000) from the
%windir%\$hf_mig$ folder instead of the hotfix version of File.dll
(version number 5.2.3790.0000) from the hotfix package. "
Source: http://support.microsoft.com/kb/824994
The Catroot subfolder contains the Security Catalog database which
determines if system binaries are digitally signed. The *lack* of signed
system files is what is causing some XP systems to fail to install
KB971486, the October Kernel update. The KBxxxxxx.cat file is the
digital cert of Security Updates, which is then referenced by the
CatRoot2 subfolder:
Vulnerabilities in Windows Kernel Could Allow Elevation of Privilege
(971486): MS09-058
http://www.microsoft.com/technet/security/Bulletin/MS09-058.mspx
NO XP system should *EVER* have *ANY* contents of the CatRoot subfolder
deleted. *** EVER ***
CatRoot2 can become corrupted and that is the ONLY catroot subfolder
that should *EVER* be deleted.
> (see my site for details)
Why wouldn't anyone believe that when you obviously are *completely
ignorant* on how XP updates ?
MowGreen
===============
*-343-* FDNY
Never Forgotten
===============
> For example, consider the following scenario:
Yeah, I've read all that before.
So consider the following scenario:
KB123456 has been installed, then
%systemroot%\$NTUninstallKB123456$\ has been deleted, together with the
information in the registry at
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
and
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppManagement\ARPCache
So why would
%systemroot%\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\KB123456.cat
ever be needed again? It no longer signs anything at all!
Actually, all the confused ideas in this thread tempt me to go even further.
Supposing (in general terms) that the files (version 1000) installed by
KB123456 have since been replaced by later versions (1001) of the same files
by KB234567. According to the arguments already repeated, if ever version
1000 is proposed again, it will be instead the later version 1001 from
$hf_mig$\KB234567 which will actually be used. So in fact $hf_mig$\KB123456
is no longer needed.
And so on... If KB345678 replaces KB234567 in turn with version 1002, there
is even less need for the older version.
So by carefully analysing successive versions of the same files replaced by
later updates (taking account of the branch), we could also delete the older
versions in $hf_mig$ which have become totally redundant.
For example, in my scenario, the obsolete (because already replaced twice)
versions 0998 and 0999 from previous KBnnnnnn would never be needed again.
Presumably Windows Update isn't that stupid? (mind you anything is
possible...). If indeed it is - it's past time to update the programming team!
"bitwyse" wrote:
>
> So why would
> %systemroot%\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\KB123456.cat
> ever be needed again? It no longer signs anything at all!
Correction - it still signs what remains in $hf_mig$.
I changed the order of what I wrote and anticipated the following train of
thought which would eliminate that as well.
"Joey Officer" wrote:
>
> Moving it temporarily I think will work for me.
Another idea to try - NOT YET TESTED.
At the key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\WindowsXP\SP3\KBxxxxxx\Filelist\y
there is often a value like
"Location"="c:\\windows\\$hf_mig$\\KBxxxxxx\\update"
Now what if we move the folder and change the location - for example to
"d:\\$hf_mig$\\KBxxxxxx\\update"
To check: is this location also recorded elsewhere?
> Supposing (in general terms) that the files (version 1000) installed by
> KB123456 have since been replaced by later versions (1001) of the same files
> by KB234567. According to the arguments already repeated, if ever version
> 1000 is proposed again, it will be instead the later version 1001 from
> $hf_mig$\KB234567 which will actually be used. So in fact $hf_mig$\KB123456
> is no longer needed.
This is probably true, although I'm not certain that there isn't a subtle catch
somewhere. In any case the very small amount of space you could save by this
approach is unlikely to be worth the effort and risk involved.
Harry.
MowGreen [MVP] wrote:
> NEVER delete nor compress $hf_mig$. The subfolders contained therein
> determine the branch of an update:
> * for example all of the following can be removed (see my site for
> details): Movie Maker
> Netmeeting
> Outlook Express
> Microsoft Frontpage
> Windows Media Player
> Windows Messenger
> MSN
> Voice synthesis
> Microsoft Agent
> Wordpad
> Communications (unused components)
> Games
> Accessibility
bitwyse wrote:
> Let's try to analyse things objectively instead of just mixing up
> everything we read superficially.
>
> Yeah, I've read all that before.
>
> So consider the following scenario:
> KB123456 has been installed, then
> %systemroot%\$NTUninstallKB123456$\ has been deleted, together with
> the information in the registry at
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
> and
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppManagement\ARPCache
>
> So why would
> %systemroot%\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\KB123456.cat
> ever be needed again? It no longer signs anything at all!
>
> Actually, all the confused ideas in this thread tempt me to go even
> further.
> Supposing (in general terms) that the files (version 1000)
> installed by KB123456 have since been replaced by later versions
> (1001) of the same files by KB234567. According to the arguments
> already repeated, if ever version 1000 is proposed again, it will
> be instead the later version 1001 from $hf_mig$\KB234567 which will
> actually be used. So in fact $hf_mig$\KB123456 is no longer needed.
> And so on... If KB345678 replaces KB234567 in turn with version
> 1002, there is even less need for the older version.
>
> So by carefully analysing successive versions of the same files
> replaced by later updates (taking account of the branch), we could
> also delete the older versions in $hf_mig$ which have become
> totally redundant. For example, in my scenario, the obsolete (because
> already replaced
> twice) versions 0998 and 0999 from previous KBnnnnnn would never be
> needed again.
> Presumably Windows Update isn't that stupid? (mind you anything is
> possible...). If indeed it is - it's past time to update the
> programming team!
bitwyse wrote:
> Correction - it still signs what remains in $hf_mig$.
> I changed the order of what I wrote and anticipated the following
> train of thought which would eliminate that as well.
Harry Johnston [MVP] wrote:
> This is probably true, although I'm not certain that there isn't a
> subtle catch somewhere. In any case the very small amount of space
> you could save by this approach is unlikely to be worth the effort
> and risk involved.
Agreed - my time is better spent on something worthwhile.
I wouldn't probably even consider the risks - as the 'benefits' wouldn't
even tempt me into it originally. hah
A few MBs in a TB world just isn't high on my list. ... And if I made a bad
decision and/or just kept the machine so long that it is legitimately
running out of space - I think I can afford the $20-$100 for
double/triple/10+ times the space it originally had and/or move the stuff
that shouldn't be on that drive/partition elsewhere with the time I would
waste trying to reverse-engineer the mysteries of an 8-year old OSes
'updating system quirks'. ;-)
--
Shenan Stanley
MS-MVP
--
How To Ask Questions The Smart Way
http://www.catb.org/~esr/faqs/smart-questions.html
"bitwyse" wrote:
> > So why would
> > %systemroot%\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\KB123456.cat
> > ever be needed again? It no longer signs anything at all!
>
> Correction - it still signs what remains in $hf_mig$.
...and additionally there is still a copy of the 'KB*.cat' in the same
sub-folder!
How many duplicate files do we need? - if I shouldn't delete the CatRoot
copy, then I can delete the $hf_mig$ copy...
(but I'm now working on how to get rid of everything that is obsolete - so
any precise, detailed information will be much appreciated)
--------
Next scenario (generalised and ultra-simplified so as to be understandable
by anyone):
KB000001 to KB000010 install successive versions 1 to 10 of 'file.dll'.
KB000011 comes along and proposes to install version 9 - so version 10 from
'$hf_mig$\KB000010' is used instead.
So why do I need to keep '$hf_mig$\KB000001' to '$hf_mig$\KB000009'?
Logically, Windows update should check versions in reverse order (latest
first). Must I believe that that isn't the case?
Anyone interesting in seeing the entire 2 year + ~4 month old post?
http://groups.google.com/group/microsoft.public.windowsupdate/browse_frm/thread/2d1c8c86a76744b3
(Enjoy!)
bitwyse wrote:
> (BTW - this stupid forum management program doesn't allow you to
> edit your own contributions; 9 times out of 10 you can't log in
> directly but have to do it elsewhere; and the e-mail reply
> notification loops infinitely and simply doesn't work - but then
> maybe it uses some trick that my configuration/firewall won't allow
> - quite rightly.)
<snip>
You are mistaken in your belief this is a web forum...
It's a web interface (horrible one) to a news server - not a web forum. If
you want to use these groups as they were originally intended to be used -
you need a newsreader of some sort. ;-)
http://www.microsoft.com/communities/guide/newsgroups.mspx
Shenan Stanley a ï¿œcrit :
>
> It's a web interface (horrible one) to a news server - not a web
> forum. If you want to use these groups as they were originally
> intended to be used - you need a newsreader of some sort. ;-)
Thanks for the information. It's certainly much easier in a newsgroup.
I just found the web interface while searching Internet for more
precise, detailed information than KB824994; and hoped to get some
insider tips.
Why bother? - see my reply to Harry ;-)
(I found a solution to the login problem: when invited, delete all the
cookies planted by microsoft.com and live.com: go to MSN and log in,
then return directly to the original page. It works most times.)
Regards
--
bitwyse [PGP KeyID 0xA79C8F2C]
http://www.le-maquis.net
C'est comme au CNRS: des chercheurs qui cherchent on en trouve
mais des chercheurs qui trouvent on en cherche.
Harry Johnston [MVP] a ï¿œcrit :
>
> This is probably true, although I'm not certain that there isn't a
> subtle catch somewhere. In any case the very small amount of space
> you could save by this approach is unlikely to be worth the effort
> and risk involved.
I'm not particularly bothered personnally by $hf_mig$ (600MB) - although
I _do_ clean up a lot of other stuff (including '$NTUninstall KBnnnnnn$'
folders). I don't like keeping a lot of totally unused programmes and
data on my hard disk, and all that lets me keep complete ASR backups of
the 'C:' system and programmes partition of a very wide-ranging
professional system (XP SP2 with Visual C++, DreamWeaver, PhotoShop and
many other database, spreadsheet, graphics, publishing, video editing
and multimedia programs) all on one DVD. Since I keep 4 such backups in
rotation that's worthwhile.
Good housekeeping typically reduces the total disk space used by around 50%.
(I should have put Windows and the programmes on separate partitions,
but since everything started from 3.11 then Win95 it was too much effort
to change.)
I got interested in reducing the 'footprint' of '$hf_mig$' when a second
client asked me what could be done (for their own reasons) - like 'Lady
D' and 'Joey O'. There are clearly many people interested and we always
try to find solutions (even if only workarounds) for good clients ;-)
I'm pretty sure I will find one (we rarely fail) - and people that just
say "it isn't possible" only encourage our efforts!
Here's a detailed, outstanding article on the intricacies of deleting
content of the $hf_mig$:
How to delete unused folders and files located within the $hf_mig$
folder – Part 1
http://www.pagestart.com/hfmigpart1.html
How to delete unused folders and files located within the $hf_mig$
folder – Part 2
http://www.pagestart.com/hfmigpart2.html
Pay special attention to JS' conclusion:
" With PCs purchased within the last 5 years hard drive sizes range from
160GB on up to 500GB or more. The exceptions being laptops and entry
level desktop computers where a PC only a few years old may still have a
40GB or smaller hard drive. For users who are limited by smaller size
hard drive sizes freeing up 2GB or more space can make a difference. For
the rest of us who have one or more large hard drives it most likely not
worth your time or effort. "
The Typical Home User does not have the technical acumen required to
delete content from the $hf_mig$ subfolder.
And, they should never touch content in CatRoot. Ever.
MowGreen
===============
*-343-* FDNY
Never Forgotten
===============
banthecheck.com
"Security updates should *never* have *non-security content* prechecked"
CriCri wrote:
> Hi
>
> Harry Johnston [MVP] a écrit :
I'm trying to clean my hard drive up since I installed XP about 8 years ago
on a 12 gig partition (BIG mistake!). Anyway, I'm down to about 300megs free
on C: with hibernation enabled and need space BAD!
I'm a little tired and trying to understand what folders I can delete out of
my $hf_mig$ folder. I've provided a screen shot of my folder and highlighted
what folders seems to be duplicates. Which their weren't many. I'm assuming
any updates that are older aren't needed anymore by the branch or whatever?
Let me know if you would. Thanks. Can I delete the folders I have highlighted
without messing up windows updating system?
http://home.comcast.net/~dublife/hfmigfolder.JPG