Yeah, another MS fiasco they updated the RTM's winhstb assembly which originally has null winhlp32.exe file that doesn't support opening old .hlp files so i guess they need to release a "refresh" KB917607 package that has higher assembly version in order to be active
In the mean time, here is a temporary workaround save as .cmd file (or get it from attachment), and put the KB917607 .msu file next to it, then run as admin Spoiler Code: @echo off %windir%\system32\reg.exe query "HKU\S-1-5-19" >nul 2>&1 || goto :eof set arch=x86 %windir%\system32\reg.exe query "hklm\software\microsoft\Windows NT\currentversion" /v buildlabex | find /i "amd64" 1>nul && set arch=x64 cd /d "%~dp0" if not exist Windows8.1-KB917607-%arch%.msu ( echo Windows8.1-KB917607-%arch%.msu was not found in the current folder echo. echo Press any key to Exit pause >nul exit ) if not exist "%windir%\servicing\packages\*Winhelp*.mum" ( Windows8.1-KB917607-%arch%.msu /quiet /norestart ) mkdir .\temp expand.exe -f:*Windows*.cab Windows8.1-KB917607-%arch%.msu .\ >nul expand.exe -f:* Windows8.1-KB917607-%arch%.cab .\temp >nul del /f /q Windows8.1-KB917607-%arch%.cab >nul if /i "%arch%"=="x86" ( copy /y temp\x86_microsoft-windows-winhstb_31bf3856ad364e35_6.3.9600.16398_none_bd9f041c2504e85c\ftlx0411.dll %windir%\system32 copy /y temp\x86_microsoft-windows-winhstb_31bf3856ad364e35_6.3.9600.16398_none_bd9f041c2504e85c\ftlx041e.dll %windir%\system32 copy /y temp\x86_microsoft-windows-winhstb_31bf3856ad364e35_6.3.9600.16398_none_bd9f041c2504e85c\ftsrch.dll %windir%\system32 icacls "%windir%\winhlp32.exe" /save "%temp%\AclFile" >nul takeown /f "%windir%\winhlp32.exe" >nul icacls "%windir%\winhlp32.exe" /grant *S-1-5-32-544:F >nul copy /y temp\x86_microsoft-windows-winhstb_31bf3856ad364e35_6.3.9600.16398_none_bd9f041c2504e85c\winhlp32.exe %windir% icacls "%windir%\winhlp32.exe" /setowner "NT Service\TrustedInstaller" >nul icacls "%windir%" /restore "%temp%\AclFile" >nul del /f /q "%temp%\AclFile" >nul ) if /i "%arch%"=="x64" ( copy /y temp\amd64_microsoft-windows-winhstb_31bf3856ad364e35_6.3.9600.16398_none_19bd9f9fdd625992\ftlx0411.dll %windir%\system32 copy /y temp\amd64_microsoft-windows-winhstb_31bf3856ad364e35_6.3.9600.16398_none_19bd9f9fdd625992\ftlx041e.dll %windir%\system32 copy /y temp\amd64_microsoft-windows-winhstb_31bf3856ad364e35_6.3.9600.16398_none_19bd9f9fdd625992\ftsrch.dll %windir%\system32 copy /y temp\x86_microsoft-windows-winhstb_31bf3856ad364e35_6.3.9600.16398_none_bd9f041c2504e85c\ftlx0411.dll %windir%\syswow64 copy /y temp\x86_microsoft-windows-winhstb_31bf3856ad364e35_6.3.9600.16398_none_bd9f041c2504e85c\ftlx041e.dll %windir%\syswow64 copy /y temp\x86_microsoft-windows-winhstb_31bf3856ad364e35_6.3.9600.16398_none_bd9f041c2504e85c\ftsrch.dll %windir%\syswow64 icacls "%windir%\winhlp32.exe" /save "%temp%\AclFile" >nul takeown /f "%windir%\winhlp32.exe" >nul icacls "%windir%\winhlp32.exe" /grant *S-1-5-32-544:F >nul copy /y temp\amd64_microsoft-windows-winhstb_31bf3856ad364e35_6.3.9600.16398_none_19bd9f9fdd625992\winhlp32.exe %windir% icacls "%windir%\winhlp32.exe" /setowner "NT Service\TrustedInstaller" >nul icacls "%windir%" /restore "%temp%\AclFile" >nul del /f /q "%temp%\AclFile" >nul ) rd /s /q .\temp >nul echo. echo Done. echo. echo Press any key to Exit pause >nul exit
Yes I did used dism to integrate the WU.Satisfy Updates to wim image but only KB3008188 failed after 100% saying this update is not applicable. Edit: Just found out that it was KB2978742 and not KB3008188 in the WU.Satisfy Updates folder which was causing the error and the reason is that the update KB2978742 is for Pro WMC Edition and I was using Pro VL Image.
one thing i noticed about 2959977 even before this november cumulative update, 2959977 was superseded and i did several tests with it either slipstreamed offline with dism or not and then when i installed windows 8.1 in several VMs, everytime i ran /resetbase it would get removed and then WU complained about not being installed the thing is though, even if in that case i let WU install it and then run /resetbase, it gets removed again and WU complains again, so it ends up being a neverending cycle with this update there were others that needed to satisfy WU, but those were never removed by /resetbase after WU installed them (i assume because of some manifests but not the components themselves), but 2959977 gets removed everytime so i am not sure, but i think the best way is to not slipstream it and just hide it when WU shows it (as 2919355), if you plan on using /resetbase
Yes, it was superseded by 2956575 + 2989542 i learned to live with and not care about WU since windows 7
yeh i know, but its funny how its the only one that gets removed by /resetbase, all the others needed to satisfy WU, are not, they show in /get-packages list too lol it is really weird what's happening with this updated
After Nov rollup there are more will be uninstalled: 2978668, 2998174, 2980654 (show under 2962409), 2965500 (shows under 2955164)
Hi abbodi1406! I have one question: In Instructions-ReadMe.txt you said: - The updates in this main category are intended for Windows 8.1 with Update Systems/ISOs (released in April) - You need to install these updates first before other categories - These KB's must be installed in the following order: 1. KB2989647 2. KB3000850 3. KB2934018 4. KB3014442 Do we have to install KB2975061 before installing KB3000850 as recommended by Microsoft? Regards
no need .... for Windows 8.1 with Update Systems/ISOs released in April is no need install KB2975061 , because the Windows 8.1 with update is include this update .... so is no need to install the KB2975061 to the update ISO , just install KB2989647 , KB3000850 , KB2934018 and KB3014442 for the baseline update ....
~ same with it .... sine Windows 7 i not care about the WU , on Windows 8.1 i also not install the WU in my system (because all update in WU is superseded by other update)