New
#21
If checked, they are loaded.
Re-enabling secure boot after trying out non-WHQL USB 3.1 drivers
-
-
New #22
Unfortunately, I already tried removing the AutoRunsDisabled entry for those three registry keys and made sure that the Start entry is set to 3 (because Autoruns sets it to 4) but I'm still not able to boot.
I've encountered this same BSOD loop a few hours ago when I tried deleting those three files but pasting them back to c:\windows\system32\drivers fixed the issue which is why I had high hopes that reverting what Autoruns did will also allow me to boot back. But I'm not sure what's going on.
EDIT: I forgot that I enabled System Restore before disabling the drivers with Autoruns
So I simply restored and I'm back to booting to my system although I'm back to square one.
-
New #23
Sorry for the delay. Personally I would call it quits at this point, you can have a non booting system, or a system that boots but not if you enable secure boot....and doing anything to remedy the situation results in those two outcomes. I have a feeling if you try anything else you may end up with a permanently broken system.
Re install Windows from scratch. An upgrade or repair install may just compound the issue.
Continue asking for Winraid's assessment in the mean time in the hope someone there can shed light on it.
What you want now I imagine is just a working system the way you want it.
-
-
New #25
An upgrade or repair may not remove the offending items, they may have been written to persist over upgrades, after all if you have custom drivers you wouldn't want an upgrade to remove them. A clean install would wipe the slate clean.
-
New #26
I'm still not at the point of reinstalling. I still don't consider any OS damage to my system except for those drivers. Just an update, I was able to remove one of those three pesky drivers by uninstalling the WHQL driver for the xhci controller, rebooting, and then uninstalling the winraid drivers with the checkbox checked, and doing a final reboot. That removed it totally from autoruns as well. So I have 2 if those pesky drivers left in Autoruns now but I can't remove them the same way (using device manager) because I can't see any device that used them before (I confirmed that by choosing the "let me choose driver..." option). Disabling/deleting them using Autoruns just results to the same BSOD loop which I can easily revert from using system restore.
So before I call it quits, I need to be able to get rid of those two drivers first. What does device manager do in the background when you uninstall a driver software by uninstalling the driver with that checkbox checked? Doesn't it simply remove the registry entry and delete the sys files? There's got to be something else it does that I'm missing here.
- - - Updated - - -
Oh and btw, in case you guys interested with the conversation I'm having with the winraid site owner, here you go:
Forum - RE: USB 3.0/3.1 Drivers (original and modded) - 148
Not to disrespect him or something, but I don't think I'm going anywhere with him. I feel that you guys are way helpful than he is, or maybe it's just the language barrier, I'm not sure.
-
New #27
I applaud your persistence!! Honestly I do like to tinker and don't like being beaten by things I should be able to solve. But also I am of an age now where if I want it to work and I hit a brick wall I will scrub and restart...lifes too short some times.
In theory when you install drivers (say for the first time) Windows will keep a copy in a backup location, think it is the driver store file repository in system32, but I have also found that Package Cache folders can appear in Program Files under the manufacturers name and there are a couple more places you can find Package Cache folders. Using Treesize run as admin is an eye opener. Windows can re install drivers from any of these locations and to be honest I'm not a 100% sure why they aren't all in the Driver Store File Repository folder which Is where I imagine MS wants them.
So even though you uninstalled the drivers, even using device manager with the remove software option, we know from Autoruns that some of the drivers files where still on the system and in use. this could simply be down to permissions set on the files themselves and in the registry making them persistent.
That is my take on it, I would welcome any one else jumping in here if they know more than me.
So maybe you will need to hunt those files down across your whole system and in the registry and nuke them that way....but you would need to find out why/ how they make a system unbootable if not being used, there is something very odd there.
I know with the Intel RST drivers there was one service being loaded after uninstall that resulted in a Stopcode if not disabled, it was actually in the Startup items, simply starting Taskmanager, Startup tab and disabling it allowed be to boot past the Stopcode and then remove the pesky service.
- - - Updated - - -
Random thought, you mention in your previous post you removed an XHCI device, I'm just wondering if the writer of those USB drivers was using Windows AHCI controller function to speed up USB access times, this could make USB drives appear as SATA drives to the system, maybe this is what is causing the non bootable situation. Don't even know if that is possible and seems like a Frankenstein method of dealing with USB devices.
Last edited by Pejole2165; 01 Oct 2019 at 17:46.
-
New #28
A repair install will certainly replace any damaged files including the boot files.
Yes, a clean install would probably be better, but instead of going through the hassle of reinstalling all your programs, app, and settings, I'd try a repair install first. If it solves the problem it saves the time of reinstalling everything. If not you didn't loose much time trying it. Anyway you could read Brink's tutorial on the repair install process which I linked to earlier.
BTW, if wouldn't surprise me if either a clean or repair install didn't solve the Secure Boot problem. All that said, I don't disagree with the clean install, it's just I'd give the repair install a try first.
My two cents
-
-
New #29
You are right of course Sygnus, I was just approaching it the way I would. When your install doesn't work the way it should, or the way you want it can actually be a blessing to clean install, it gives you an option to re look at the way you set your system up, re assess your disk layout structure, your backup approach etc. I know the thought of starting from scratch seems like an effort at times but it does have some up sides.
Only my opinion based on what I would be thinking at this point if it was happening to me.
I think the OP really wants to figure out the "why" of the issue before moving on with any other options. as long as he/she wants to try, I will try to help with my thoughts.
As I said he/she is a persistent bugger, I admire that.
-
New #30
You wouldn't believe how persistent I can be :) Told you I'm not a home user, lol. It's just that reformatting/reinstalling is so time-consuming for me because I have a lot of optimization steps to do when installing a new OS. It's really my last resort unless the system is really crappy or full of bloatware (which my system is nowhere near).I applaud your persistence!! Honestly I do like to tinker and don't like being beaten by things I should be able to solve. But also I am of an age now where if I want it to work and I hit a brick wall I will scrub and restart...lifes too short some times.
In theory when you install drivers (say for the first time) Windows will keep a copy in a backup location, think it is the driver store file repository in system32, but I have also found that Package Cache folders can appear in Program Files under the manufacturers name and there are a couple more places you can find Package Cache folders. Using Treesize run as admin is an eye opener. Windows can re install drivers from any of these locations and to be honest I'm not a 100% sure why they aren't all in the Driver Store File Repository folder which Is where I imagine MS wants them.
So even though you uninstalled the drivers, even using device manager with the remove software option, we know from Autoruns that some of the drivers files where still on the system and in use. this could simply be down to permissions set on the files themselves and in the registry making them persistent.
That is my take on it, I would welcome any one else jumping in here if they know more than me.
So maybe you will need to hunt those files down across your whole system and in the registry and nuke them that way....but you would need to find out why/ how they make a system unbootable if not being used, there is something very odd there.
I know with the Intel RST drivers there was one service being loaded after uninstall that resulted in a Stopcode if not disabled, it was actually in the Startup items, simply starting Taskmanager, Startup tab and disabling it allowed be to boot past the Stopcode and then remove the pesky service.
- - - Updated - - -
Random thought, you mention in your previous post you removed an XHCI device, I'm just wondering if the writer of those USB drivers was using Windows AHCI controller function to speed up USB access times, this could make USB drives appear as SATA drives to the system, maybe this is what is causing the non bootable situation. Don't even know if that is possible and seems like a Frankenstein method of dealing with USB devices.
The thing is that these drivers were installed using DPInst.exe, so no software involved. It's just weird that I already tried removing the whole registry key for the remaining two drivers and that still resulted into the stop code. So there's something in the system "depending" on these drivers. I used TreeSize before but how would it be an eye opener in this case?
I don't know either but I do know that my system is running in RAID mode, not AHCI.
I never do a repair install on my own system as I never trust Windows doing things to itself without my consent. If I would need to do any installation to fix this, I would be reinstalling it. But like I said, it would be my last resort.
Oh and btw, I would be a 100% sure that a clean install will fix my Secure Boot problem. I've installed Win 10 on this machine a couple of times with Secure Boot enabled. Nothing's wrong except for the fact that I tried installing modded drivers.
Quote
Related Discussions
