Welcome Back AskPerf!

Published 03-25-2019 10:22 AM 4,339 Views

Hello Everyone! Welcome to the new home of the AskPerf blog. We have recently moved, and many things have changed in the years since the last post here. The owners of the blog have moved on to bigger and better things, so I have decided to bring it back to life, and bring some new fresh content to help the community. The Performance team has actually been split to two teams internally at Microsoft, one is still called "Performance" and the other is called "User Experience", or UEX. Between the two teams, we will still provide information on all of the topics that we cover, here under one roof. So welcome back, and we will be providing some information here soon.

-Craig Marcho

Occasional Visitor

What up @CraigMarcho !! Let's post some content! :)

Senior Member

Waiting eagerly!

Occasional Visitor

Yay!! Lets get it rolling.....

Occasional Visitor

First time posting on this and not sure how it works.  But I see that there have not been to many posts here.  How does this work?

Senior Member

OK here is a "starter for 10": How about an article on the performance issues causing some users grief, after having Feature Update 2004 installed.

There are many reports of this in the MS Answers forum, and Feedback contains 50+ items about FU2004,many with no comments.


The impression I am getting, is that those with older devices with HDD see the performance issues (slow restart/reboot, slower internet, search indexer and sysmain/prefretch hogging/slowing the machines) much more noticeably than those with SSD, so it is just possible that the insider groups, and the main testing groups were not measuring performance, and not noticing it either, as they would most likely have later, well configured systems with SSD, to help with faster testing and deployment and validation for product readiness.


So, as this appears to be the "external" public facing side of the "Performance Team", rather than highlighting items that started life in 2015, how about getting more "proactive" stuff on here, where (hopefully), your group can get feedback from the "coal face" internal teams, that are working on fixing Feature Update 2004, AND any other known issues with ANY of the Windows internal functional areas that are currently known to cause performance hits (especially post-2004 update), and what Microsoft is doing to help users get back to the performance and productivity they had before it got installed.


Please be aware that performance issues can be very frustrating for most normal users, who lack any diagnostic knowledge and tools, to find the real issues. It should be Microsoft teams like yours, who have access to the debug tools that the public does NOT have, to detect and iron out these things BEFORE big changes get into mainstream use, and this blog COULD be a good vehicle to convey Microsoft's current activities and action plans to reassure users, and help them move forward to the experience they are expecting from Windows 10.

Senior Member

OK, so finally, some feedback from Microsoft. The current "culprit" MIGHT be related to a non-removable update (KB4559309) that installs the new Chrome based Edge browser. However, I have my doubts that it is the ONLY cause. My desktop HAS the 2004 updates, but does NOT have this update, and does NOT have the new Edge, but STILL has horrible performance issues.


I DID mitigate them for normal running mostly, by stopping and disabling the SYSMAIN and Windows Search services. However, I still have long reboot/restart times, much longer then before 2004 update.  I AM a user with MalwareBytes premium AV, that was supposed to be a factor in normal work going slow, but I have the later updates to it that stop that issue.

Senior Member

FYI: I just found the original URL link for the very interesting (and long) article on the MS Answers forum, that was referenced in the PCGAMERS site where I got the info for my post above, regarding the very suspect update for deploying the new EDGE browser (KB4559309).


Some users are even saying that the update interfered with their manufacturers Motherboard Chipset drivers, and that they had to reinstall them to get back the previous performance. Others have NOT seen that, but are still stuck with bad performance. However, there are 22 PAGES of complaints on this post alone. The fact the the errant update is NOT uninstallable makes the issue MUCH worse than it should otherwise be:


Hopefully now THIS above is seen on THIS Tech Community, maybe it will give more traction and viewings/posting on BOTH. Users and tech folks need to speak up on this, and get it sorted out, as there are a LOT of fed up and angry users out there.

Senior Member

@PerseousYou were asking how this works. Well, at this point, I am unsure, as it seems after the initial opening post by  @CraigMarcho there are no actual information posts FROM microsoft, and only my few posts about Performance Issues after users get the Windows 10 2004 update, and further issues after KB4559309. I would urge you and any other technical readers who have had experiences of these problems, to post them here AND on Feedback Hub, and hope that:

1) Craig will read them and pass them along to his colleagues to review and comment

2) The correct teams that (might be) looking at those issues from here or Feedback Hub will comment and provide feedback as to WHAT/WHEN Microsoft will be doing to mitigate the issues raised.

Senior Member

I would like to post a useful comment from DanDScan on a Microsoft Answers forum. He has found that a report from Kaspersky mentioned a specific "autorun" registry item for Hard Disks should be basically disabled, and force them to be set as "non-removable", and therefore not part of an "autorun" scheme (especially the boot disk). Here is his post:


I have tried most of the solutions proposed for the long boot time with version 2004 and none has worked. I have now found a solution that does work on my computer. From login to useable screen was taking about 6 minutes and now takes 75 seconds which is the same as with previous versions of Windows 10.


Machine: Laptop, Intel i5, single HDD, Windows 10 Pro 2004


In the registry I have disabled Autorun for the HDD – see Microsoft’s documentation in the reference at the end of this post. One difference is that I have this key under HKEY_LOCAL_MACHINE rather than Microsoft’s recommendation of HKEY_CURRENT_USER.


Using Regedit create the following key (if it’s not already there):









Then create NoDriveTypeAutoRun as REG_DWORD with value 0x08 (decimal 8)


The possible values are:


Bit Number       Bitmask Constant                     Description

0x04             DRIVE_REMOVEABLE         Disk can be removed (such as a floppy disk).

0x08             DRIVE_FIXED                       Disk cannot be removed from drive (a hard disk).

0x10             DRIVE_REMOTE                  Network drive.

0x20             DRIVE_CDROM                    CD-ROM drive.

0x40             DRIVE_RAMDISK                 RAM disk.

All other solutions proposed under earlier posts have worked for some users but not all and I suspect this solution will be no different. Still, this solution has zero cost, is easy to apply (if you are used to using Regedit) and is reversible. Hopefully, a few more users will find themselves dug out of the slow-boot hole.



I have not tested with Microsoft’s recommendation of using HKEY_CURRENT_USER.




Kaspersky’s Total Security ‘Vulnerability Scan’ tool"



I agree that it is a dramatic and surprising result and not at all what I was expecting. I can’t explain why it works as I have no tools to interrogate the early part of the boot process to see what actually is going on. Within Kaspersky Total Security is an analysis tool called ‘Vulnerability Scan’ which I ran with no thought of the slow boot-time. It came back with ‘Autorun from hard drives is enabled’, ‘Autorun from network drives is enabled’, ‘Autorun from removeable drives is enabled’ with suggestions to correct by disabling these entries.


Kaspersky further says that “If the autorun from hard drives option is disabled, then it will not impact your system boot and your system performance. The fix disables only the autorun of the autorun.inffile, which can contain links to launch malicious programs. By default the autorun from hard drives option is disabled.”


Subsequently, when I saw the boot process had speeded up, I did some digging to determine what had changed and a search of the registry found the NoDriveTypeAutoRun entry with a value of 0x1c (decimal 28) covering the three drive types. A test showed the HDD entry alone was sufficient to speed-up booting, value 0x08 (decimal 8) as in my post.


A common feature of the very slow boot time in v2004 that I and other users have experienced is the continuous, heavy access to the HDD after entering login details (which is why some have suggested switching to an SSD). Pinning down why this happens in v2004 but not in earlier versions has been the challenge. The NoDriveTypeAutoRun fix has worked on my machine but I don’t know why.


Editing the registry can indeed be dangerous which is one reason I included the link to Microsoft’s autoplay-reg documentation, not least to provide some insurance if I made a typo in my post.


And a definite thank you for the link to Mark Russinnovich’s  autoruns tool."

Version history
Last update:
‎Mar 25 2019 10:22 AM
Updated by: