• jelson

    jelson

    @jelson

    Viewing 15 replies - 46 through 60 (of 72 total)
    Author
    Replies
    • in reply to: What do you know/think about KB 2952664? #31856

      I’m wondering if MS brought a copywriter or two into their Update Dept?

      Any end-user who’s WU isn’t set to Automatic now see only a few updates now… and they’ll be reassuringly told that update goofs are a thing of the past… they’re “Quality” now. 😉

    • in reply to: Windows 7 scan speedup #31944

      Wow… very cool.

      How did you determine the command line for the verification (Step 2)?

      Any links where I could learn more about your technique?

    • in reply to: Windows 7 scan speedup #31908

      please DELETE both of my replies… for some reason, parts of it are not showing up 🙁 Thanks

    • in reply to: Windows 7 scan speedup #31906

      ^EDIT:^ a paragraph and a half got deleted; reply should read:

      FYI: more info on difference in WU scan speed between (Mar ’16 WU Client update) 3138612 and the June ’16 WUC update (3161608) in the July ’16 rollup update: 3172605

      Base: no W10 upgrade or Telemetry updates installed

      Yesterday -with Mar ’16 WUC installed- a scan in Windows Update (WU) took 5 mins.

      That indicates to me that there was some sort of “supersedence” slow-down with 3138612 during WUMT-scans eventhough WU-scans were still fast.

    • in reply to: Windows 7 scan speedup #31904

      FYI: more info on difference in WU scan speed between (Mar ’16 WU Client update) 3138612 and the June ’16 WUC update (3161608) in the July ’16 rollup update: 3172605

      Base: no W10 upgrade or Telemetry updates installed

      Yesterday -with Mar ’16 WUC installed- a scan in Windows Update (WU) took < 10 mins.

      Interesting, Windows Update MiniTool (WUMT) took 5 mins!!

      That indicates to me that there was some sort of “supersedence” slow-down with 3138612 during WUMT-scans eventhough WU-scans were still fast.

    • in reply to: In search of a post-patchocalypse block list #33478

      Nick, PKCano and abbodi86 put together great lists. There are 3 more from my list of “Telemetry” updates:

      KB2977759
      — Compatibility update for Windows 7 RTM
      https://support.microsoft.com/en-us/kb/2977759
      “This update performs diagnostics on the Windows systems that participate in the Windows Customer Experience Improvement Program. These diagnostics help determine whether compatibility issues may be encountered when the latest Windows operating system is installed.”

      KB3046480
      — Update helps to determine whether to migrate the .NET Framework 1.1 when you upgrade Windows 8.1 or Windows 7
      https://support.microsoft.com/en-us/kb/3046480
      “This article describes an update that has effect when you upgrade Windows 8.1 or Windows 7 to a later version of Windows”

      The 3rd one has been superseded and is no longer relevant, but is still in the Catalog:

      KB3139929
      — Security update for Internet Explorer: March 8, 2016
      https://support.microsoft.com/en-us/kb/3139929
      Contains “3146449 Updated Internet Explorer 11 capabilities to upgrade Windows 8.1 and Windows 7”

      There is another group of patches that I once considered “bad” — actually they’re just annoying — because they introduced the “z-order bug” (which I learned about from your article http://www.infoworld.com/article/2607451/microsoft-windows/microsoft-ships-replacement-patch-kb-2993651-with-two-known-bugs.html)

      KB2965768 / KB2970228 / KB2973201 / KB2975719 / KB2982791 / KB2993651

    • in reply to: In search of a post-patchocalypse block list #33477

      +1 Yep… KB3150513 doesn’t show up unless KB2952664 has been installed

    • in reply to: .NET Framework patch numbering screw-up? #33833

      +1

    • @ch100

      Quite right: SumatraPDF cannot fill forms… BUT since Adobe Reader Free doesn’t let you save filled-in PDF forms, you might consider Nitro PDF Free which does let you save filled-in PDF forms.

    • in reply to: Still no answer to the source of Win7 slow scanning #34557

      You’re right… you can even find support there as well: http://forums.mydigitallife.info/threads/64939-Windows-Update-MiniTool

    • in reply to: When does the Win7 scan for updates head south? #34599

      Interesting question indeed. There is a pattern to each of the last months’ “speedup patches”:

      April – MS Graphics component
      May – kernel-mode driver
      June – kernel-mode driver
      July – kernel-mode driver
      Aug – kernel-mode driver
      Sep – MS Graphics component

      Note that each of those updates patched “win32k.sys”.

      In a comment to another posting here — https://www.askwoody.com/2016/slow-windows-7-scan-for-updates-this-months-magic-patch-is-kb-3185911/comment-page-1/#comment-98774 — Bill C. provided some key information about what’s going with WU. He offered a link to a thread on the SuperUser forum which explained:

      “Windows 7 uses Component-Based Servicing, which means Windows Update has to work ridiculously hard to determine file and component dependencies/inter-dependencies, maintain side-by-side versions of older files/components, while still making it possible to uninstall individual updates/components but without breaking any other updates/components, all the while taking into account supercedence and god knows what else. The code that does all this must be hellishly complex.”

      Furthermore, and of particular interest:

      “When you use ETW/WPR/WPA to check for the CPU usage during the scan you see that the CPU usage comes from wuaueng.dll!CUpdatesToPruneList::AddSupersedenceInfoIfNeeded which is called from wuaueng.dll!CAgentUpdateManager::FindUpdates.

      “The AddSupersedenceInfoIfNeeded method is the slowest thing. This does what the name indicates and looks if the offered/installed Windows 7 updates are still needed or superseded (outdated/replaced by newer ones). This is very slow.”

      Given all the above, it seems quite likely there is a problem with the supersedence chain when a new crop of updates has one which patches “win32k.sys.” And that results in WU taking hours and hours to make its supersedence checks. At least, that’s what it’s looking like to me.

      Of course, one way MS could easily fix this is to issue a Win7 Service Pack 2. And then they could establish a new baseline for determining update supersedence. Alas…

    • @ Bill C. Thanks a bunch for the link to thread on SuperUser. It explains in detail what the bottlenecks are in the Windows Update mechanism.

    • System Restore?

      I turned that as soon as a I got a good system imaging program: Disk Snapshot

    • in reply to: Patch Tuesday not dire – quick recap #34909

      After manually installing KB 3185911, it only took 4 mins for my Win7 machine to check for updates! JOY

    • in reply to: Patch Tuesday not dire – quick recap #34907

      Once again…. very long wait…. until today, only took 5 min to “Check for updates”

      Checked at Dalia’s site (http://wu.krelay.de/en/2016-09.htm) and he’s updated his list with KB3185911 (MS Graphic Components) replacing last month’s KB3177725 at the top of his list

    Viewing 15 replies - 46 through 60 (of 72 total)