SOLUTION: bootrec /fixboot Access is Denied

So here’s a new one. Warning: this one’s rough. It’s an advanced one, and there are possibly more causes than simply this… so as always, I take zero responsibility for anyone messing with their own machines without professional help.

This particular story is just that: a case study, basically, referencing the circumstances of the individual machine I was working on. This post is more for my reference than for anyone else’s from that standpoint. 😉

A client’s machine came to me, stuck in a boot loop to WinRE. Nothing corrected it, but the machine seemingly wasn’t even trying to boot to the Windows partition. As is often the case with Windows 10, System Restore was of no help. As always, the first step, then, was to repair the BCD and boot parameters (this was a GPT/UEFI drive), so I went through the usual steps first.

However, once reaching the bootrec /fixboot step, the result was Access is Denied. This is the first time I’ve seen this message to my knowledge, so I did some digging.

What I discovered is that apparently the latest build of WinRE doesn’t properly handle this command in some situations. I booted to an older build of a Windows ERD (based on 1703), ran the same commands, and this time, it worked.

After this (and after disabling automatic restart on system failure), I was finally reaching an intelligible boot error screen, thus confirming that the system was at least attempting a boot from the Windows partition. The error referenced the file WdFilter.sys, which is located at c:\Windows\system32\drivers\wd\WdFilter.sys. It’s the Windows Defender Real-Time scanning filesystem filter driver, specifically.

I navigated to this directory next and noted the file creation/modification dates on the two files, which was 10/23/2018 (in case this is of any use to anyone else with this problem). The same dates were shared by WdNisDrv.sys (the Windows Defender network stack filter driver). WdBoot.sys, meanwhile, was dated sometime in April 2018.

Copies of these files are stored in c:\Windows\system32\drivers. Suspecting that one of the October-dated versions was corrupt, I replaced both WdFilter.sys and WdNisDrv.sys, then booted the system.

This time, the machine finally reached Windows. The work wasn’t finished yet: to bring everything up to consistency, I next performed a Component Store Cleanup and DISM RestoreHealth command followed by a system file check and repair. After all of these steps, the problems were completely resolved, and everything was back to working normally.

Donate to say "Thanks" if this post has helped save you time and money! 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *