I figured I should just post this in case others encounter this, because it seems like something that may be quite complicated to actually pin down.
I have a Windows on ARM system (Surface Pro 11), and so need to run Julia in WSL to use the version compiled for ARM. So I have VSCode set up to run connected to WSL, and to use Julia inside WSL.
When I tried to precompile a package, which includes dependencies on Enzyme and Flux among others, from scratch inside VSCode’s REPL, the entire system hangs (display and all) somewhere variable while Enzyme is being precompiled. Eventually the system throws up a DPC_WATCHDOG_VIOLATION blue screen.
However, if I repeatedly precompile, it eventually gets through everything.
I also don’t seem to see the issue if I precompile from scratch just within a WSL Terminal window. CORRECTION: Not true
I’ve now seen a whole family of BSODs. It’s very reliable.
IPI_WATCHDOG_TIMEOUT
CLOCK_WATCHDOG_TIMEOUT
DPC_WATCHDOG_VIOLATION
Turns out that the WSL team wants BSODs to be reported to Microsoft’s Security team, so I’ve sent them four minidumps from the crashes.
And this is what I sent them as a reproducer:
# 1. install Julia
curl -fsSL https://install.julialang.org | sh
# 2. Execute a long-running process in Julia
julia -e "import Pkg; Pkg.add([\"Flux\", \"Enzyme\", \"Symbolics\", \"Plots\"])"
Microsoft determined that the problem is resource exhaustion. They recommended that .wslconfig (Advanced settings configuration in WSL | Microsoft Learn) be used to set the number of processors available to the VM (default is all), and to reserve 1 or 2 for Windows. On my 12-core machine, I set it to 10 cores and Julia worked perfectly. (Didn’t try 11.)
# Settings apply across all Linux distros running on WSL 2
[wsl2]
# Sets the VM to use ten virtual processors
processors=10
1 Like
I take that back, it suddenly started happening again. I even reduced CPUs to 6.
Next attempt: setting autoMemoryReclaim to dropcache