rdr_file_system 0x27 BSOD After Windows 10 2004 update, but only on domain profiles

I too have a similar issue. I did post here an hour ago thinking I had a workaround. This turned out to be a fail in the end.

Below is my post from this topic "BSOD stop code on Windows 10 start (RDR File System - mxrsmb20.sys) after installing Synology 218+" https://answers.microsoft.com/en-us/windows/forum/all/bsod-stop-code-on-windows-10-start-rdr-file-system/6e2bafea-8ad8-4372-9ca1-e84203999405?page=1 which could be of some use.

I too have a Synology (DS916+) which I offload excess data for Domain users which hoard too many files. I thought it was this "rdr_file_system 0x27 BSOD After Windows 10 2004 update, but only on domain profiles" from here https://answers.microsoft.com/en-us/windows/forum/all/rdrfilesystem-0x27-bsod-after-windows-10-2004/c34f5703-1367-4788-a4f3-2d75f7dfaa07?page=1 which sadly it is not.

I offline these files on the Synology for some users who insist having access to everything. I also offline their My Documents which is being redirected to my Server 2016 Domain Controller (and for some to a crusty old SBS2008 that is waiting to be decommissioned).

Formatting the CSC cache to zero the state and only making My Documents offline does not produce the BSOD. Adding the Synology target back as well does make it BSOD. I would guess then there is something broken when trying to spin up Offline Files that come from the Synology. I did initially get a strange error on one machine I configured last week implying a security mismatch of sorts related to the Synology location which I dismissed and failed to take complete note of what it was describing.

The Synology is up-to-date.

The Windows machines that fail are build 2004 and are up to date.

Entering user credentials to start the logon process will create the BSOD once the authentication process starts.

This does not occur if the offending WIN10 machines are connected to the Domain network and the Synology hosted files are deemed Online.

I read that giving the Windows machines ANY network to access will allow successful login; I got only so far with that suggestion but cannot fully say that is a viable workaround as it seems to me the files made offline from the Synology are broken somehow. When I "fix" this issue the BSOD returns. I tried installing the Microsoft Loopback adapter to fake an always connected network but that trick broke once I "fixed" the offline file issue with data made offline from the Synology.

I'm experiencing the same issue, although not as badly as I can log in with BSOD.  My issue occurs when connecting my VPN and then at a random point soon after I get the BSOD.  We use Offline Files for our profiles and therefore can't realistically disable it.

I was able to log a paid support incident for the issue and Microsoft confirmed this is a known issue, although it's not documented anywhere.  The only fixes are to roll back to 1909 or disable Offline Files.  As I'm past my 10 day rollback period this is a real pita 😡

As this has been going on for some time, I find it somewhat rediculous that Microsoft don't have a fix for this or at least have it documented and based on other threads it may only be fixed by going to the next version of Windows...

Nick

we have the same problem in dozens of customer environments. RDR_FILE_SYSTEM when they login outside of office....hopefully Microsoft will fix this in the next update

Same issue here

We've been able to re-enable Offline Files.

We had this problem with 4 of 10 v2004 PCs. With one, the user could log on without BSOD'ing but it would BSOD upon browsing a network drive. The rest BSOD'd during logon until I disabled Offline Files via remote registry edit. The other 6 are getting along just fine so far.

In all 4 cases, we've worked around it by resetting Offline Files (create a FormatDatabase DWORD value set to 1 in HKLM\System\CurrentControlSet\Services\CSC\Parameters, re-enable Offline Files service and reboot the computer). Then the users can log on with Offline Files enabled.

However, the mapped drive (which maps to a DFS share, if that's relevant) is inaccessible after logon. The workaround for that has been to add a logon script that unmaps the drive, then remaps it to the non-DFS share. Initially, only the redirected folder share (also DFS) is browsable. Later, the rest of the DFS shares become browseable, perhaps after they're onlined by Offline Files.

Small sample size. Don't know how universal this workaround is, but hope it helps somebody!

[22 Sep 2020 update] The first computer I tried this workaround on had the same BSOD at logon today. So clearing the cache is not a permanent fix, as others here have since said. I've now disabled Offline Files on desktops.[sigh] On laptops, will have to continue clearing the cache for now. At least it buys a few weeks.