Ok, so I tried this again within Virtualbox (which for some reason won't allow me to install guest additions so got around that...) and install option 3 from the install updates menu worked perfectly, right through . This is on a clean install with UAC turned off. Not sure what is causing the issue then for you, it must be something anomalous caused by iso alternations. Its probably triggering the 'failsafe' feature I put in there so you don't end up in an endless install cycle. That is, if there are updates that won't install, since it checks for updates that aren't installed, if certain updates don't install, it will always cause them to try and be installed. The cab option 3 gets around this. Ideally you have none, or worst case only a few. It sounds like for you its hitting the 50 mark, so the install process is being halted. Why you're ending up with 50 non-installing updates I don't know... note that it triggers by list comparison, so if two process lists are the same it triggers. That means when proper installation is finished and you are left with say, 30 non-applicable updates, on the next reboot the same 30 updates will be identified, and the install process is cancelled. For you, if for a particular boot, 50 updates don't apply for some reason (but are meant to), the next boot the install will identify the lists as the same and cancel. I hope that makes sense, because I sucked at explaining it! EDIT: Actually I see what you mean lol will try and fix it (least if/when it is fixed I won't need to explain how it works again!)
No. Just on the old place. All missing updates can now be downloaded by my new KUC version. also they can be found @ kuc.mattern.it/hotfix To autodownload the updates it was nessesay to move to a new web-site for direct download.
Added a new folder "SatisfyWU" (satisfy Windows Update) with the Updates: KB2545698, KB2556532 and KB2644615. After some new fresh installations of Windows 7 Ultimate, Windows Update still shows those Updates.
Ironically: dotNetFx40_Full_x86_x64.exe - 48.1 MB x86 Net 4 UPDATE NDP40-KB2600211-x86.exe - 42.4MB x64 Net 4 UPDATE NDP40-KB2600211-x64.exe - 67.1MB If you didn't know about LDR/GDR and the x86/x64 system etc, you'd presume something is a little fishy when the combined original installer is 48.1MB and an update that doesn't cover all the files and for just x64 is 67.MB! Note sure what updates it replaces, but keep in mind it is a GDR/LDR thing, so you may need another update to force install the LDR branch, unless you're using ricktendo64's modified installer. It would have to replace KB2544514 directly, since that is 4.0.2.
Yes, realistically Microsoft should have released the 4.0.1, 4.0.2, and 4.0.3 updates as actual original installers. Their size would be close to the original installer size, and nothing stopping Microsoft setting it up so they can do an in-place upgrade. Makes more sense than installing at outdated framework, then installing all these updates which make bigger downloads, that effectively replacing most of it.
Microsoft.Runtimes\DotNet Framework 4 Client + Extended March 5 Added NDP40-KB2600211 Removed NDP40-KB2544514.msp
You explained it perfectly; I understand, it makes sense. All of the updates are applicable because they all slipstream perfectly.
After installing KB2600211, KB2534366 shows up on MS update-just to inform; I just hide those. Update: I used Komm's KUC to add/update LDR and mum files for KB's: 2446710 2478662 2525835 2556532 2607496 2644615 2646886 Now no updates appear as required on M$ update.
Microsoft.Runtimes\DotNet Framework 4 Client + Extended March 5 Added NDP40-KB2600211 Removed NDP40-KB2544514.msp NDP40-KB983182.msp NDP40-KB2544514.msp NDP40-KB2605597.msp NDP40-KB2652319.msp NDP40-KB2656351.msp Updated Compressed file Microsoft.Runtimes to version Microsoft.Runtimes-03.05.2012.7z
Like I said, it was an 'anomalous' thing with the errorlevel function, hopefully the test 2 I linked earlier works. Try the following: - Make 3 files, file1.txt, file2,txt, and file3.txt - file1.txt and file2.txt should have the same content, something simple like: --> yep --> test - file3.txt should be different, such that the second line could read 'test2' instead of 'test' - run each of the following: --> fc file1.txt file2.txt >nul a --> echo %errorlevel% b --> if errorlevel 0 echo errorlevel result is 0 c --> if errorlevel 1 echo errorlevel result is 1 - repeat the 'fc' command as above, except replace file2.txt with file3.txt - repeat steps a, b, and c. So, in the above comparing file1,txt and file2.txt will result in the correct behavior, the errorlevel is 0, echo %errorlevel% will show as 0, and if errorlevel will show 'errorlevel is 0' for errorlevel 0 and nothing for errorlevel 1. Now, on the second test comparing the two different files (file1.txt, file3.txt), echo %errorlevel% will show as 1, which is correct (the compare doesn't match). However this time if errorlevel will show errorlevel is 0 and errorlevel is 1. Obvisiouly errorlevel shouldn't be both 0 and 1, but for some reason both will work! This is where the script is fowling up on with the install option 3. The compare says the files are the same (errorlevel 0) where the errorlevel should be 1 (compare is different, so there are still more updates to install). So, why not use if %errorlevel% equ instead of if errorlevel? I tried that, putting the above in a batch file. Result? the first time it ran, the %errorlevel% was wrong, but if you run the batch again %errorlevel% is correct... I'm assuming this is not how it is meant to behave? if it is, explain why so!