Why isn't \System32\DriverStore\FileRepository allowed for Update -> SCAN?


Why isn't \System32\DriverStore\FileRepository allowed for Update ->...
Author
Message
DSperber
DSperber
Junior Member
Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)
Group: Forum Members
Posts: 38, Visits: 196
\FileRepository is where Windows keeps a "library copy" of all currently installed drivers for possible future re-use (even though the drivers are actually installed and "registered" somewhere else).  Therefore this is the location most easily pointed to when doing an advanced build of WinPE/WinRE WIM, adding actually running user-provided drivers rather than using "compaible drivers already present" in WinPE/WinRE.

So you should be allowed to navigate to \FileRepository when doing Advanced -> Devices & Drivers -> Update -> SCAN (iwith sub-folders checked) when custom building the drivers in the WIM.  And yet, this is rejected, I know not why. Not allowed to SCAN, perhaps maybe because of an "authority" issue accessing C:\Windwos\System32... even just for READ?  Is it the "check sub-folders" here that's the problem?

Don't know. But it's not allowed. And so you must manually make a copy of the drivers from \FileRepositoy to ANYWHERE ELSE (like your own local private location for keeping drivers, program installers, etc.).  And from this ANYWHERE ELSE location you CAN then do the Update -> SCAN, to custom build your WIM.

Why can't we just point to the correct \FileRepository sub-folder and use it, including "check sub-folders"?  I know, there are many hundreds or thousands of driver folders in the parent \FileRepository, so use of the "check sub-folders" would probably be inappropriate if you were pointing at the parent \FileRepository itself.  But If I pointed to just ONE of these individual driver sub-folders (e.g. the \SECNVME* sub-folder that holds the Samsung NVMe driver) why can't that be allowed? There may actually be further sub-folders within each of these driver sub-folders inside of \FileRepository so I want to be able to "check sub-folders".  But there's no performance issue doing a "check sub-folders" at this individual driver folder level underneath \FileRepository, compared to scanning down from the overall parent level \FileRepository where I could understand why you might possibly legitimately not want to allow starting at that ultmate high-level for "check sub-folders" through thousands of folders.

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)
Group: Forum Members
Posts: 6K, Visits: 45K
A while ago I suggested that Rescue Media Builder add a "Force copy host driver" function that would cause it to pull the driver from the host OS into a Rescue Media build even if it determined that compatible support was already present in WinPE/RE.  I suggested it after having helped two users troubleshoot an issue where the "compatible driver" did in fact load in WinPE/RE, leaving no devices showing as unsupported, but that driver lacked certain capabilities that were necessary for the proper operation of the device in question, in one case a NIC and in another case an eSATA controller.  In both cases, manually copying the "real" driver into the Drivers folder used for Rescue Media builds resolved the issue.  Anyway, a Macrium developer even sent me a test build of Rescue Media Builder that included that function I suggested.  Last I heard it was still waiting on peer review before the code could be merged into a release branch.  But that capability would seem to accomplish what you're trying to do with significantly less effort.

But just out of curiosity in your particular case, does the native Microsoft NVMe driver not work?  If it does, why are you trying to add the Samsung NVMe driver?  I realize that the Samsung NVMe driver can improve performance in some systems, but presumably you won't be using Rescue Media all that often, and given that compatibility/reliability would seem to be a priority over absolute performance in a Rescue Media context even if you WERE using it often, I personally would think it safer to stick with the native NVMe support.  I remember a while ago the Samsung NVMe driver caused BSoDs when the user simply created a VHDX file on a partition hosted by a Samsung SSD.  I don't know about you, but if I'd seen that behavior, especially if I didn't actually try to do that until a while after I'd installed all of my drivers, I would have spent a lot of time and removed a lot of hair before I thought that my third-party NVMe driver might be responsible for such behavior.

Edited 12 February 2020 7:32 PM by jphughan
DSperber
DSperber
Junior Member
Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)
Group: Forum Members
Posts: 38, Visits: 196
jphughan - 12 February 2020 7:20 PM


I wasn't using the Samsung NVMe driver as an example of one that needed to be use instead of the MS one, in order to resolve an "unsupported/missing" device problem.  I was simply on a path to use ALL of my currently installed host drivers instead of the ones present in WinPE/WinRE, because I did have problems of hardware not being visible unless I used host drivers.

In particular, the Asmedia USB 3.1 controller and Asmedia 106x SATA controllers on my ASUS Z170-Deluxe board were NOT properly supported by the drivers in WinPE/WinRE that got assumed by Macrium Reflect. It was only after manually building a WinPE 10 rescue media (using the method I'd described previously) such that all host drivers were used, did all my drives and external USB 3.0 backup devices now become fully visible and usable.

I only suggest being able to point to those drivers in their \FileRepository location, since they are ALL located there (for possible future reference, once they get installed wherever they actually get installed).  So it is the perfect "library" to point to (at least the specific folder for each individual driver you want to use, rather than the high-level parent folder  \FileRepository which would require scanning thousands of sub-folders just to pick up one driver. I could live with not allowing the parent folder, if only I could use an individual folder and also "check sub-folders" for it.

Or, as you've already presented as a perfectly equivalent and simple alternative: just allow forcing this to automatically happen for all drivers to be picked (i.e. forcing currently installed host drivers to be used for USB, SATA/AHCI/RAID, and NETWORK), not relying on any which might be in WinPE/WinRE compatible or otherwise.

MPSAN
MPSAN
Junior Member
Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)
Group: Forum Members
Posts: 72, Visits: 204
I need help as I believe I need to add some driver that Windows10 Pro 1909 used. I have v7.2.4711. However when I build a pe or re rescue media, it now loads to a blue screen. There must be a driver that 1909 uses but I have no idea how to add it. I am asking for help here as it seems that this is what you all are talking about. How can I add this when I build my rescue DVD?
MPSAN
MPSAN
Junior Member
Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)
Group: Forum Members
Posts: 72, Visits: 204
I can TRY the custom scan trick to see what happens as I see 3 folders that were created yesterday!
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)
Group: Forum Members
Posts: 6K, Visits: 45K
@MPSAN if you know the actual driver you need to add, you can manually copy the folder containing the driver into the correct subfolder of C:\Boot\Macrium, based on the WinPE/RE version you want to add it to, the architecture, and the device category.  So for example you might go to C:\boot\macrium\WinREDrivers\64Bit\Disk.  Copy your driver folder into there so that you have a new subfolder for that driver underneath the Disk folder.  You can name the driver folder anything you want.

If you're not sure what driver you need, then if you're using a flash drive for Rescue Media, see if the log file on the root of the flash drive contains any useful information after trying to boot from it.  Or does the blue screen error itself contain any useful information?

Also, you say you're having trouble with both WinRE and WinPE-based Rescue Media?  WinPE Rescue Media should still be using WinPE 10 1709, regardless of the Windows 10 version you're running.  There have been reports of boot errors when using the recovery boot menu option, but this is the first I've seen of problems with flash drive-based Rescue Media.

Another thing you could try is just blowing away your entire Rescue Media file set cache and having Reflect rebuild it from scratch.  To do that, just delete the C:\boot\macrium folder.

MPSAN
MPSAN
Junior Member
Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)
Group: Forum Members
Posts: 72, Visits: 204
Well, this is being built on a dvd. Anyway, I seem to think that it could be a display driver. I do NOT have the recovery option selected. If I just delete the boot\macrium folder won't it just rebuild it wrong again or will it go to the current filerepositry?
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)
Group: Forum Members
Posts: 6K, Visits: 45K
I just suggested deleting the folder because it's easy to rebuild.  It might end up reintroducing the same problem, but since it's not clear what the problem is right now or why it's just now started occurring, "resetting" the build might resolve the issue.  But Reflect doesn't include display drivers in its Rescue Media builds.  It just relies on the basic display driver support built into WinPE/RE unless you manually drop display drivers somewhere underneath its Drivers folder.  I know somebody did that because they wanted their 2560x1440 display to run at 2560x1440 in Rescue rather than 1920x1080 (even though that's plenty of resolution for Rescue purposes, but that's neither here nor there.)  But anyway, scanning a folder for drivers would be relevant for devices that Reflect actually checks driver support for in the first place.  Stated differently, if you don't see the device of interest under Rescue Media Builder > Advanced > Devices & Drivers, then scanning a folder for drivers won't cause Reflect to add drivers for that device.

I'm also not sure why this would have just started after updating to 1909 and/or updating Reflect.  Can you go to Rescue Media Builder and confirm that when you choose WinPE 10, it is in fact using WinPE 10 1709?  The reason I ask is that 7.2.4711 includes a note that for WinPE 10 builds, Reflect will auto-detect newer WinPE ADK versions if they're installed, so I guess the WinPE 10 version could potentially be using a newer version.  And maybe that changed recently to introduce a problem.  And at least while you're debugging, if you have a flash drive to test with that might be faster since they're much quicker to update and also much quicker to boot from.  I'd even say the convenience makes it worth spending $6 or so to get a flash drive dedicated to Rescue Media.  I have a SanDisk Ultra Flair for this purpose.

MPSAN
MPSAN
Junior Member
Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)
Group: Forum Members
Posts: 72, Visits: 204
Well, I still do not have it working! I see the suggestion to do a scan using the filerepositry and check subfolders. How do I even know which directory to point to? I have no idea what is causing the issue. As far as seeing what is on the screen when I do boot from the rescue media, there is nothing but a light blue screen. Nothing else. How do I know what to select?
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)
Group: Forum Members
Posts: 6K, Visits: 45K
Ok, so it's not a BSOD then, just a blank light blue screen?  That sounds like the default background color of WinPE/RE, so perhaps the Reflect application itself isn't loading when it should be.  I will reiterate my suggestion to blow away your Rescue Media cache and have Reflect rebuild it from scratch.  I'd also suggest trying WinPE 10 since it's more of a known and Macrium-tested quantity for Rescue Media than WinRE, which gets updated whenever Microsoft updates Windows 10 and even gets customized on individual systems.  If your Rescue Media worked before, you shouldn't need to suddenly deal with manually adding drivers to make it work again.

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Login

Explore
Messages
Mentions
Search