That error number is common enough to recognize on sight. It's an "access violation" error, but it doesn't mean you lack admin access to something. It means something in LabVIEW is trying to access a location in RAM that it's not allowed to access. Sometimes this is a null pointer, other times it's a reference that points to memory that was allocated but later freed and is now outside of the application's memory space.
For the most part LabVIEW's core code, such as file writing, has been tested and debugged extensively so it is very rare for LabVIEW all on its own to generate this error, which is why if you look at other posts with the same error code they often direct you to look at 3rd party code using DLLs or ActiveX as the most likely cause.
Since you're convinced that writing to the file causes it, here's a few important checks to do that could help with troubleshooting:
First, in your current code, have you checked to see which exact subVI or node causes the crash? You could do this in many ways, but since you seem pretty sure writing files is causing the problem I'd suggest adding delays and some code to put status updates on a visible front panel somewhere so that it slows down the operation and really lets you be sure of the exact node that crashes everything.
Second, can you create a very small EXE that runs by itself that replicates the problem but doesn't do anything else? Meaning something that just runs the file saving routine with a set of dummy data, or an even smaller example. If you can do that and post the VIs that make up that EXE here, other people can attempt to build it and see if it works for them or not.
Third, have you tried this on any other PC or OS? If you could see if another W11 PC, or a W10 PC, could run it with no crash, that could help check to see if it's a problem specific to your W11 PC or to W11 in general.
