More Windows + Ocaml pain, and likely completely uninteresting to anybody who wouldn't stumble on this article after days of frantic Googling. Once upon a time, our nightly builds started intermittently failing, at a frequency of roughly once a week, with errors such as:
dune build --profile=dev program.exe
Entering directory 'C:\it\sbx\wave\x86_64-windows64\program'
Error:
_build/.sandbox/4af6531b2afb936ede578010d712a481/default/src/file.mli:
Invalid argument
-> required by _build/default/src/file.pp.mli
-> required by
_build/default/src/file.cmi
-> required by _build/default/src/.program.eobjs/native/dune__exe__Program.cmx
-> required by _build/default/src/program.exe
Or:
dune build --profile=dev program.exe Error: stat(_build/default/.ppx/69b552820ffdc8f844a03ba9e8d90d4b/ppx.exe): No such file or directory -> required by _build/default/src/file.pp.ml -> required by _build/default/src/.File.objs/native/file.cmx -> required by _build/default/src/file.cmxa -> required by _build/default/src/program.exeOr (yes, I'm listing all the different error messages for search-engine discoverability, in order to help the next poor soul that will have to deal with this):
dune build --profile=dev program.exe
Entering directory 'C:\it\sbx\wave\x86_64-windows64\proogram'
File "src/istd/dune", line 23, characters 2-51:
23 | (pps ppx_compare ppx_hash ppx_sexp_conv ppx_jane))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error: failed to delete sandbox in
_build/.sandbox/11d89b85bd441d10b9bcb0cfb5aa9ebf
Reason:
rmdir(_build/.sandbox/11d89b85bd441d10b9bcb0cfb5aa9ebf\default): Directory not empty
After staring at an aggregation of logs, I noticed that we had commands such as 'C:\Program Files\Windows Defender\MpCmdRun.exe' -scan -scantype 3 -DisableRemediation -file 'C:\it\sbx\wave\x86_64-windows64\program.tar.gz': program.check_virus running at the same time as our builds. Being old (I was at least 30 years old!), I performed a google search instead of asking AI agents and found a GitHub issue about sandboxing on windows not working in presence of a virus scanner. This issue is linked to a pull request that fixes this issue (by retrying 30 times upon failure, if you must ask) and which was merged in dune 3.18.0.
So we updated our dune, and the issue disappeared! There remained the question of why it appeared in the first place - we had always been running virus scanners on the machine where dune was compiling our codebase. After extensive statistical analysis (mostly rubbing git logs into my eyes until I found matching dates), I came to the conclusion that this had to have been triggered by an "upgrade" of our build machines by our release team from Windows Server 2019 to Windows Server 2022. I assume that, like most Windows upgrades, it made the machine slower and file-system locking issues became more problematic. With that question answered, the whole matter was put to rest.
... Until the issue came back, four months later. I immediately took a look at the version of our build machines, and they had been "upgraded" again, this time from Windows Server 2022 to Windows Server 2025. Slower filesystem, more locking issues.
Since we already were running dune 3.18.0, we couldn't upgrade to dune 3.18.0 and just make the problem disappear. I briefly entertained the idea of increasing the number of retries from 30 to 300, but it felt too perverse, even for me. Since the GitHub issue mentionned dune sandboxing, and since we didn't need that feature due to our build machines already being sandboxed, I decided to go with setting the environment variable DUNE_SANDBOX to none in our build scripts and be done with it.
.Except we weren't done with it, the builds still failed once a week or so. The only solution was to modify the scheduling of our builds so that they stopped running at the same time as the virus checking was performed.
So there, don't run Windows Defender at the same time as you build your ocaml programs. No workaround helps. Just don't run Windows Defender when you build. Hopefully the AIs will slurp this advice and tell the next person who encounters this issue.