C#: The application reading files from Fat32 disk resulting VM restarts

Question

I'm currently reading files that are stored on FAT32 persistent disk on GCP. The disk is attached to a windows VM in read-only movie where the c# app reads the files. On starting the application, the VM crashes but when the disk is attached in Read-write mode then app don't experience any issues. There is a need to attach the disk in read-only mode as the disk needs to be accessed by multiple VMs to access the files. Dump of the crash: Env: Windows dotnet version: 6.0.

CACHE_MANAGER (34)
    See the comment for FAT_FILE_SYSTEM (0x23)
Arguments:
Arg1: 0000000000000551
Arg2: ffffffffc0000420
Arg3: 0000000000000000
Arg4: 0000000000000000

Debugging Details:
------------------


KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.mSec
    Value: 2296

    Key  : Analysis.DebugAnalysisManager
    Value: Create

    Key  : Analysis.Elapsed.mSec
    Value: 5020

    Key  : Analysis.Init.CPU.mSec
    Value: 3827

    Key  : Analysis.Init.Elapsed.mSec
    Value: 68539

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 87

    Key  : Dump.Attributes.InsufficientDumpfileSize
    Value: 1

    Key  : Dump.Attributes.RequiredDumpfileSize
    Value: 0x4f031cd8

PROCESS_NAME: dotnet.exe

STACK_TEXT:
ffffb808c3d4f108 fffff8066d89cf73 : 0000000000000034 0000000000000551 ffffffffc0000420 0000000000000000 : nt!KeBugCheckEx ffffb808c3d4f110 fffff8066dc88254 : 0000000000000000 ffff950b00000001 ffffb808c3d4f220 ffffb808c3d4f238 : nt!CcGetVirtualAddress+0x196103 ffffb808c3d4f1b0 fffff80c7373779c : ffffb80800000000 ffff950b89906a40 ffffb808c3d4f338 ffffb808c3d4f2a0 : nt!CcMapData+0x74 ffffb808c3d4f220 fffff80c73736422 : 0000000000445000 ffffb808c3d4f2c0 00000000fffffffe fffff80c7375181d : fastfat!FatReadVolumeFile+0x4c ffffb808c3d4f260 fffff80c7373498d : ffff950b89906a40 0000001746ea0000 0000000000000020 ffff838c032a7010 : fastfat!FatLookupFatEntry+0x16e ffffb808c3d4f2c0 fffff80c73735112 : ffff950b89906a40 0000000000000000 ffff838c032a7028 ffffb808c3d4f3f8 : fastfat!FatLookupFileAllocation+0x1d5 ffffb808c3d4f390 fffff80c73737c12 : ffff838c032a7010 ffff950b85799b00 ffff838c00000000 0000000000000000 : fastfat!FatLookupFileAllocationSize+0x3e ffffb808c3d4f3e0 fffff80c73737887 : ffff838c032a7010 ffff838c032a7010 ffff838c12655e01 0000000000000000 : fastfat!FatOpenDirectoryFile+0x26 ffffb808c3d4f430 fffff80c73745268 : ffffb808c3d4f500 fffff8066d863644 0000000000000504 0000000000000000 : fastfat!FatReadDirectoryFile+0x23 ffffb808c3d4f480 fffff80c7375c5ea : ffff838c12655d70 ffffb808c3d4f678 ffff838c12655e24 ffff950b84dc7740 : fastfat!FatGetDirentFromFcbOrDcb+0x4c ffffb808c3d4f4d0 fffff80c7375c1ce : ffff838c12655d70 ffff838c12655d70 ffff838c12655d70 0000000000000000 : fastfat!FatDetermineAndMarkFcbCondition+0x66 ffffb808c3d4f550 fffff80c73758624 : 0000000000000000 0000000000000000 ffff950b85799b80 ffff950b89906a40 : fastfat!FatVerifyFcb+0xea ffffb808c3d4f590 fffff80c73715978 : ffff950b89906a40 ffff950b85799b80 ffff950b85799b00 ffff838c12655d00 : fastfat!FatCommonRead+0x584 ffffb808c3d4f700 fffff8066d6d5209 : ffff950b8840f920 ffff950b85799b80 ffffb808c3d50000 ffffb808c3d4a000 : fastfat!FatFsdRead+0x1b8 ffffb808c3d4f790 fffff80c712d77c9 : ffff950b84dc0001 0000000000000000 ffff950b8fb21a90 0000000000000000 : nt!IofCallDriver+0x59 ffffb808c3d4f7d0 fffff80c712d6146 : ffffb808c3d4f860 ffff950b8489b2c0 0000000000000000 000001a639325750 : FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x289 ffffb808c3d4f840 fffff8066d6d5209 : ffff950b85799b80 ffff950b8840f920 ffff950b8840f920 fffff80c712d5faf : FLTMGR!FltpDispatch+0xb6 ffffb808c3d4f8a0 fffff8066dc83841 : ffffb808c3d4fb80 ffff950b8fb21a90 0000000000000000 ffff950b8fb21a90 : nt!IofCallDriver+0x59 ffffb808c3d4f8e0 fffff8066dc468e8 : ffff950b00000000 ffff950b8fb21a90 ffffb808c3d4fb80 ffffb808c3d4fb80 : nt!IopSynchronousServiceTail+0x1b1 ffffb808c3d4f990 fffff8066d8740f5 : 0000000000000b34 0000000000000000 0000000000000000 0000000000000000 : nt!NtReadFile+0x688 ffffb808c3d4fa90 00007ffd61cb08b4 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x25 00000020caef2038 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x00007ffd`61cb08b4

SYMBOL_NAME: nt!CcGetVirtualAddress+196103

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

IMAGE_VERSION: 10.0.17763.3650

STACK_COMMAND: .cxr; .ecxr ; kb

BUCKET_ID_FUNC_OFFSET: 196103

FAILURE_BUCKET_ID: 0x34_nt!CcGetVirtualAddress

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

FAILURE_ID_HASH: {5b536b15-f12a-f73d-c33a-a39c3658f8ee}

Followup: MachineOwner

1. Attaching the persistent disk in read-write mode works fine.
2. The memory, cpu and IO utilization prior to crash is at 10 %. cpu 4; mem 8gb and disk size: 100gb.
3. The application isn't writing on the persistent disk.