Well Irv, my ignorance shows through again...I suppose I'm not as bad off as I thought...
And it seems like Bitdefender takes a long time to get going.
From my cheapie laptop I spoke of earlier:
Not as much difference as I thought. But I think I know why. I am running Bitlocker on both of these machines with just a straight password. From dead cold, when you push the power button on the laptop, the Bitlocker password screen comes up immediately...really quick. Push the button on the 8700 desktop and it sounds like it cycles (for the lack of a better term) everything before the password screen pops up. It sounds like it pings the optical drive, and the HDD takes a spin as well. The laptop doesn't have a HDD or an optical drive, so maybe that's why it's quicker upfront.
Anyway, thanks for sharing and thanks for your help.
Well, there is more to that as well.
Looking only at your 8700 vs. mine for differences.
You've got listed above 32GB's, I've got 8GB's. My CPU is 8% slower. My random drive speed is 15% slower too.
I'm also starting up 20 more apps on boot... Note that what it considers 'Windows boot' is basically the same though.
You also have to take into account Windows Fast Boot if you have NOT disabled it (it is on by default). It only effects a cold boot, not a restart, so the times would be different depending which you use. Fast Boot will use the HIBERFIL.SYS on a cold boot to get the system up faster. No so on a reboot though.
So basically (I have left Fast Boot enabled) and the extra auto-start programs make up the extra time. Don't forget, I can use the PC well before all my programs auto-start as well.
Oh, the password time is NOT in the calculations, see the line through it?
Hi, were you able to solve it?
I had same error which is finally resolved now, the steps I followed are :
1. Uninstall Broadcomm Wireless drivers and Bluetooth drivers
2. Disable Internal WLAN and Internal Bluetooth from BIOS Settings
3. Remove if you have added extra RAM (which didn't come with your PC)
Once done, now try to run the Setup file again and see if this resolves the error.
Source >> Fix We Couldn’t Install Windows 10 Error (0XC1900101 – 0x20017)
I upgraded from Windows 7 and Windows 10 just too good for my old PC (Dell Inspiron N5010) 😄 hopefully this helps someone.
So, I decided to take IrvSp advice and go through the "Image, reinstall, restore" process, so I downloaded the Macrium Reflect, and created the restore disk. At the verification stage, when I ensured that the recovery USB actually booted right, I decided to inspect the drives as Macrium saw them right out of the BIOS. Here is where I got a kick out of what I saw.
Preface, I too cloned the HDD with Paragon to my Samsung SSD, and I also tried to disconnect the HDD, plugging the SSD to the SATA port 0 and the HDD to port 1. I would have imagined this would have set the disk order to SSD disk 0 and the HDD to disk 1, but that is not what happens.
Also, in windows, the SSD is Drive C, whereas the HDD is Drive E. This is what I would have expected to see in Macrium. To my surprise, and aha moment... this is what I see from Macrium.
As you can tell from the image below, out of the BIOS, the old HDD is still being recognized as the C drive. Here in lies what I think is the issue with the upgrade is.
With respect to your pictures, what you are seeing is:
C: is the FIRST PARTITION on the hard drive on SATA port 1 (probably read from the BOOT MANAGER, not the BIOS)
E: is the FIRST PARTITION on the SSD on SATA port 3 (DVD should be on port 1)
M: is the USB drive most likely
X: is the Macrium Reflect of Windows Boot/recovery disk.
A better thing to look at would be either using DISKPART or DISK MANAGER to see what is what.
DISKPART> list disk
Disk ### Status Size Free Dyn Gpt
-------- ------------- ------- ------- --- ---
Disk 0 Online 931 GB 2048 KB *
Disk 1 Online 111 GB 0 B *
Disk 2 Online 931 GB 0 B
Disk 3 No Media 0 B 0 B
Disk 4 No Media 0 B 0 B
Disk 5 No Media 0 B 0 B
Disk 6 No Media 0 B 0 B
DISKPART> list volume
Volume ### Ltr Label Fs Type Size Status Info
---------- --- ----------- ----- ---------- ------- --------- --------
Volume 0 D DVD-ROM 0 B No Media
Volume 1 DIAGS FAT32 Partition 40 MB Healthy
Volume 2 WINRETOOLS NTFS Partition 490 MB Healthy
Volume 3 OS NTFS Partition 109 GB Healthy
Volume 4 K Disk_K NTFS Partition 811 GB Healthy
Volume 5 PBR Image NTFS Partition 8 GB Healthy
Volume 6 ESP FAT32 Partition 500 MB Healthy System
Volume 7 NTFS Partition 449 MB Healthy Hidden
Volume 8 C OS NTFS Partition 111 GB Healthy Boot
Volume 9 NTFS Partition 450 MB Healthy Hidden
Volume 10 L Disk_L NTFS Partition 931 GB Healthy Pagefile
Volume 11 F Removable 0 B No Media
Volume 12 G Removable 0 B No Media
Volume 13 H Removable 0 B No Media
Volume 14 I Removable 0 B No Media
I found a solution that worked for me and (I think) hasn't been discussed here.
Similarly to other people in this thread, I have a Dell PC (8300 in my case, not 8700) and my attempt to upgrade to W10 yielded the "0xC1900101 - 0x20017" error. Drive 0 is a rotating disk, Drive 1 is a (Samsung) SSD that I initialized using some (Samsung-supplied) cloning software at the time I bought the SSD (some time back). The BIOS is (was) configured to boot from Drive 1 (the SSD).
I was at a loss (and I wanted to find a solution other than IrvSp's since that one involves making and restoring image copies and wiping out partitions--a bit scary), so I figured I'd see if I could boot from Drive 0 (which still had the W8.1 installation that I'd left behind after getting my SSD) and install W10 there. So I changed the BIOS config to boot from Drive 0, ran the "Windows Media Creation" tool, and was able to successfully install W10 on Drive 0. (It took a while--I'd forgotten how much faster my system had gotten when I'd switched from the rotating disk to the SDD! 🙂
At that point I was going to reconfig the BIOS to boot off of Drive 1 and try the W10 upgrade there again, hoping that somehow having done the upgrade to Drive 0 would have jiggled things into a working state. ("Jiggled" is a technical term 🙂 But before trying that I decided to see if I could figure out this BCD stuff and the bcdedit tool (the last time I did this level of stuff it involved editing boot.ini files) to make it so I could keep the BIOS set to boot from Drive 0 but configure things so that the Windows boot process would offer me the choice of booting from the (now W10) Windows on Drive 0 or the (still W8.1) on Drive 1. I did this sort of just for yucks and sort of to avoid having to switch BIOS settings back and forth as part of these experiments and it also occurred to me that this would be another possibly interesting configuration to try upgrading the SSD's W8.1 installation from.
Anyway, I succeeded on the BCD changes and was indeed presented with the choice of the two Windows installations to boot from. I booted from the SSD and was then able to do the W10 upgrade. It's possible that just making the BCD changes--and not bothering with upgrading Drive 0 to W10--would have been enough to make the upgrade of Drive 1 to W10 work, but I guess I'll never know. Or care 🙂
If I feel motivated, I might try reconfig'ing the BIOS to boot from Drive 1 again to see if that works--i.e,. I'm able to boot from the Drive 1 W10. (That'd be a preferable state since then my ability to boot would depend on only one disk, not two, being in a functioning state.)
I Finally got an answer from Paragon:
Thank you for contacting us!
Sorry for the delayed response. It is because of my vacation. We now in process of huge test of this problem but all seems like the problem is in Windows 10. I’ll replay as I have any updated solution.
Technical Support Team
Paragon Software Group
I guess they were on vacation for 3 weeks. W10 problem? I doubt it, but...
my Dell XPS8500 is now smoothly running with Windows 10 and all my applications!
After receiving the new Dell recovery media on DVD (Windows 8.0) I made an image of the running 8.1 OS, cleared the SSD, removed all other drives, installed the 8.0 OS via the recovery media and upadated to a full working 8.1 system. Then I recovered the formerly saved image of the C: partiton back to the SSD and finally started the Win10 update process... and it worked!
In one try I made the mistake to recover all the partitions of the saved SSD back (C: with the Windows OS, the OEM sevice partition and the UEFI partition). With this configuration the update process failed again.
Based on my experience and my Dell system the following factors had no influence on the update process:
- to remove all drives
- to remove the onboard 30GB msata drive
- to remove the wireless device and their drivers
- to remove or deactivate the antivirus (Norton 360 IS)
The failure number never changed during my failed update attempts (C1900101-20017). For all image saving and recovering processes I used the paragon hard drive manager (I had nothing else and was quite familliar with it ;-).
Thank you very much for your help! I found no where else an other work-arround for this problem and at the end it was quite easy to execute... except the first step of killing the running System. Paragon also did not answer yet.