Julian@ could you please look into this issue.

The BSOD documentation mentions that this is happening when the physical memory is depleted. Are the machines that exhibit this behavior particularly low on RAM? I think the error is happening when this policy is on only because Chrome then would write often to the network share but is caused in general by the system running out of memory not because of this feature in particular.

Hardly, the machines where this problem happened had even just Chrome started up. The computers all have between 8GB and 64GB of RAM and have as their operating system Windows 10 build 1703 64bit ent.

Julian, assigning for triaging this bug. Thanks.

Hi. With the memory dump from the crash, we might be able to learn more about the cause. I think Windows drops a dump in C:\Windows\memory.dmp. Could you search for that and share it directly with one of us? Thanks.

Hi, is the minidump sufficient? (C:\Windows\Minidump)
The memory.dmp is really huge

Thx

+ some folks who probably know a ton more about digging into BSOD dumps than I. pennymac, forshaw: could you please advise? Thanks.

I'm a bit confused about this ticket...

First, let me just say that Chrome doesn't have code that runs in kernel, so we shouldn't be able to cause a BSOD.  Unless it's a knock-on effect from e.g. a GPU driver, or a failed exploit attempt.  And this report indicates a physical memory bsod in rdbss.sys (Redirected Drive Buffering Subsystem).  Regardless of any form of memory usage in Chrome (user-mode processes), a BSOD should not result.  There's some bad code here external to Chrome.

Also, Julian or Will can confirm, but I don't think roaming profiles are supported in Chrome at this time - where profiles are off machine.  Something in what we allow in paths for file I/O, and off the top of my head I can say that all child processes (not browser) are blocked from mapping remote images (run exes, load DLLs) via MITIGATION_IMAGE_LOAD_NO_REMOTE.  On the latter though, you'd get an obvious failure in loading a remote file.

Any historical details on supporting roaming profiles Will?  Or what we expect the visible failure would look like if one tried to enable it?

hard to diagnose this more without a memory dump. it can be large but you should be able to upload to a cloud storage product (e.g. google drive, dropbox) and share the link here. Since this bug is public, make sure you lock down the access on the dump file so only people CCed on this bug can access it.

Re: roaming profiles. We do not support this for Chrome binaries running off a roaming profile (e.g. chrome canary, user level install, roaming binaries). Redirecting just documents should be fine, as this is not app data. Can you confirm the exact policy you are using here? (use gpresult to export the policy).

I understand the difficulty of making a diagnosis without or with few details

The documents folder is redirected to a file server \\server\share$\%username%\Documents.

Policy settings are:
1.Set the roaming profile directory --> enabled --> "${documents}\Google_Profilo\"
2.Enable the creation of roaming copies for Google Chrome profile data --> enabled
3.Disable synchronization of data with Google --> Disabled

The folder "Google_Profilo" is hidden via a powershell script

For privacy reasons I can not disclose the entire gpresult, even for the dump there are security problems in disclosing detailed information.

at the moment, in order to make our users work without problems, policy number 3. has been enabled.

thank you very much for your cooperation.