Chrome with Dokany-mirrored data directory crashes with 0xc0000006 when navigating pages

[mcpower]

Check List

• [x] I checked my issue doesn't exist yet
• [x] My issue is valid with mirror default sample and not specific to my user-mode driver implementation
• [x] I can always reproduce the issue with the provided description below.
• [x] I have updated Dokany to the latest version and have reboot my computer after.
• [ ] I tested one of the last snapshot from appveyor CI

Describe the bug Chrome, when user-data-dir points to a Dokany mirror FS, crashes with 0xc0000006 when navigating pages sometimes.

This is an annoyingly flaky bug - it is easy to reproduce without Dokany logs, but very difficult to reproduce when recording logs.

To Reproduce Steps to reproduce the behavior:

1. Run "C:\Program Files\Dokan\Dokan Library-2.3.0\sample\mirror\mirror.exe" /r C:\Temp\chrome /l g in cmd.exe, replacing C:\Temp\chrome and g with your desired folder and mount point
2. Run "C:\Program Files\Google\Chrome\Application\chrome.exe" --user-data-dir=G:\ in cmd.exe, replacing G:\ with your mount point. You may want to additionally add --enable-page-content-annotations-logging --enable-logging=stderr for additional logging about the thing causing the crashes.
3. Navigate to pages repeatedly until Chrome crashes.

For step 3, I like to navigate to https://about.google and click on the "Google" logo in the top left corner repeatedly, which will induce a crash within 20 navigations most of the time.

Expected behavior Chrome does not crash.

Logs Chrome crash dump, analysed by minidump-stackwalk:

Operating system: Windows NT
                  10.0.19045 6093
CPU: amd64
     family 25 model 33 stepping 0
     12 CPUs

Crash reason:  EXCEPTION_IN_PAGE_ERROR_READ / STATUS_INVALID_HANDLE
Crash address: 0x00000219ade40004
Crashing instruction: `movzx eax, byte [rcx]`
Memory accessed by instruction:
  0. Address: 0x00000219ade40004
     Size: 1
No instruction pointer update by instruction
Process uptime: 13 seconds

Thread 10 ThreadPoolBackgroundWorker (crashed) - tid: 9452
 0  chrome.dll + 0x4c72c30
     rax = 0x00000219ade40000    rdx = 0x00007ddfe9c366eb
     rcx = 0x00000219ade40004    rbx = 0x0000000000129ab0
     rsi = 0x00000052d3bfed30    rdi = 0x0000000000000000
     rbp = 0x0000000000000000    rsp = 0x00000052d3bfecb8
      r8 = 0x0000000000000004     r9 = 0x00007c2c024bf400
     r10 = 0x00000fff318ae820    r11 = 0x0000000111111111
     r12 = 0x00007c2c048d7770    r13 = 0x0000000000000000
     r14 = 0x00007c2c024bfd90    r15 = 0x0000000000129ab0
     rip = 0x00007ff98e4c2c30
    Found by: given as instruction pointer in context
 1  chrome.dll + 0x1eef9d1
     rsp = 0x00000052d3bfecc0    rip = 0x00007ff98b73f9d2
    Found by: stack scanning
...

EXCEPTION_IN_PAGE_ERROR_READ is actually 0xc0000006, also known as STATUS_IN_PAGE_ERROR.

It is exceptionally difficult to reproduce this issue with Dokany logs - for some reason, enabling logs makes the issue rarer - but I have managed to get some logs a single time it crashed: mirror-1.zip

Notably, Chrome crashes around here:

###Read file handle = 0x0000026078BB2AE0, eventID = 10242, event Info = 0x0000026076BDB9A0
ReadFile : C:\Temp\chrome\optimization_guide_model_store\13\E6DC4029A1E4B4C1\7CF2E5DF4D78B826\model.tflite
	read error = 6, buffer length = 32768, read length = 0

Dokan Information: SendAndPullEventInformation() with NTSTATUS 0x0, context 0x78bb2ae0, and result object 0x0000026078BD89C0 with size 48
Dokan Information: SendAndPullEventInformation() with NTSTATUS 0xc0000008, context 0x78bb2ae0, and result object 0x0000026078B8BDA0 with size 48

Every time I have attempted to reproduce the issue without it crashing, 0xc0000008 or read error = 6 do not appear in the logs. It is always reading from a file in optimization_guide_model_store, which led me to the "page annotation service" in Chromium. Disabling the two flags relating to "page content annotations" in chrome://flags seems to completely mitigate the problem.

This is reproducible across multiple root directories across multiple drives.

This is also reproducible on a completely different machine, running a clean install of Windows 11 (except for Chrome and Dokany).

Environment:

• Windows version: 10.0.19045 6093
• Processor architecture: amd64
• Dokany version: 2.3.0.1000
• Library type (Dokany/FUSE): Dokany

[mcpower]

I can't reproduce this issue at HEAD. Can you make a new release to close this issue?

[Liryna]

Hey @mcpower

I just made a new one https://github.com/dokan-dev/dokany/releases/tag/v2.3.1.1000 . Let me know how it goes!

[mcpower]

Hm, that didn't seem to fix the issue. Will investigate why a local compile of Dokany fixes it - perhaps I'm using a more up to date version of the WDK?

[Liryna]

Sorry to hear that. WDK version shouldn't affect the driver behavior as far as I know but let me know!

[LTRData]

Like @Liryna says, WDK versions very rarely change driver behavior in this way. I have sometimes seen cases where different WDK versions headers redirect to different sets of APIs for the same code and similar things though that theoretically could produce result like this. But again, extremely rare. This needs more investigation.

I could run some tests too and see what I can find.

[LTRData]

After a few attempts on different machines now, I have not been able to reproduce this issue.

[Liryna]

Closing for inactivity