Glad to be of help
Windows Booting very slow after 2004 update ,
Windows for home | Windows 10 | Performance and system failures
Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.
128 answers
Sort by: Oldest
-
Anonymous
2020-11-15T23:33:43+00:00 -
Anonymous
2020-11-17T15:12:33+00:00 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):
HKEY_LOCAL_MACHINE
Software
Microsoft
Windows
CurrentVersion
Policies
Explorer
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.
Note:
I have not tested with Microsoft’s recommendation of using HKEY_CURRENT_USER.
Reference:
https://docs.microsoft.com/en-us/windows/win32/shell/autoplay-reg
Acknowledgement:
Kaspersky’s Total Security ‘Vulnerability Scan’ tool
-
Anonymous
2020-11-20T01:47:22+00:00 @DanDScan - that is interesting that it made such a dramatic change. As the C: disk is the boot disk (and should always be treated as "non-removable"), I am surprised that any "autorun" functionality is used at all! Did you say that Kapersky scan recommended that change? A reference would be useful.
Altering the registry can be dangerous. It is best to use an official utility for "autorun" changes. This official Microsoft tool (autoruns) developed by Mark Russinnovich is very good, and a right click on entries will remove registry entries as required. This is especially useful for those hard to detect items/drivers/bloat apps that start up that you do not need, and also detects stranded items from faulty uninstalls (that can cause added delays as items are searched for during startup).
https://docs.microsoft.com/en-us/sysinternals/downloads/autoruns
-
Anonymous
2020-11-20T16:16:50+00:00 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.
-
Anonymous
2020-11-20T20:43:53+00:00 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):
HKEY_LOCAL_MACHINE
Software
Microsoft
Windows
CurrentVersion
Policies
Explorer
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.
Note:
I have not tested with Microsoft’s recommendation of using HKEY_CURRENT_USER.
Reference:
https://docs.microsoft.com/en-us/windows/win32/shell/autoplay-reg
Acknowledgement:
Kaspersky’s Total Security ‘Vulnerability Scan’ tool
I too have tried all the suggestions here and got the boot time down from several minutes. Tried your suggestion via the Kaspersky app and sure enough it found the autorun and disabled it by adding the entry in the registry. It set it to 3c and I changed it to 7c so all are disabled. Boot time is quicker after password entered. It takes about 10-15 spins of the busy cursor to usable Windows...
Thanks for this info. Strange but works.