Compiler.exe / GC error - workaround

For months I'd have my server (AZ Casual) "crash" because there would be a "gc" error popup during server restart, with an "OK" button.  If the OK button wasn't pressed, server wouldn't start up properly.  Is also an intermittent issue, and I don't know the source.

So, if anyone else has a similar issue, I'd like to provide the following DOS batch file.  Save as a .bat file, and run it.  It will check for the stuck compiler.exe, and kill it (effectively, clicking OK) so your server can boot normally.  It checks frequently, and provides a count of how many instances it's found: 

30s pause
Runs = 61
Found = 1

I launch it as part of my overall server startup script.  It also logs any time it finds/kills the issue.  I've run it since the summer (2021) with no problem.  Edit the path's as appropriate.  I could've made it a var.  I didn't.  "ping -n 30" is a 30s pause.  Increase/decrease n to modify the pause.

Hope it helps someone :-)

Log output:
LIST says:
Image Name PID Session Name Session# Mem Usage
========================= ======== ================ =========== ============
Compiler.exe 17300 RDP-Tcp#1 2 982,044 K
KILL says:
SUCCESS: The process with PID 17300 has been terminated.
----------------------------------------------------------------------


@echo off

set r=0
set f=0

:MAIN
cls
@echo 30s pause

:: Save Netstat Info
@netstat -aon|find "*.*.*.*:38216" >r:\RustPort.txt

set /a r = %r%+1
@echo Runs = %r%
@echo Found = %f%
@ping -n 30 *.*.*.* >NUL

tasklist /fi "WINDOWTITLE eq Fatal*" >C:\Users\<your path>\Desktop\ChkIssue.txt
::echo compiler.exe >>C:\Users\<your path>\Desktop\ChkIssue.txt
find /i "compiler.exe" C:\Users\<your path>\Desktop\ChkIssue.txt
goto %errorlevel%found
goto :end
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:0found
@echo FOUND
set /a f=%f%+1

@echo :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: >>C:\Users\<your path>\Desktop\GCHangLog.txt
echo %date% %time% >>C:\Users\<your path>\Desktop\GCHangLog.txt

echo LIST says: >>C:\Users\<your path>\Desktop\GCHangLog.txt
tasklist /fi "WINDOWTITLE eq Fatal*" >>C:\Users\<your path>\Desktop\GCHangLog.txt

echo KILL says: >>C:\Users\<your path>\Desktop\GCHangLog.txt
taskkill /f /fi "WINDOWTITLE eq Fatal*" >>C:\Users\<your path>\Desktop\GCHangLog.txt

echo. >found.txt
@echo ---------------------------------------------------------------------- >>C:\Users\<your path>\Desktop\GCHangLog.txt
goto :end
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:1found
@echo Not Found
goto :end
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:end
@echo Go to Main
Goto :Main​

If you are seeing an error with the compiler, it'd be helpful to see that.

It's a popup that says very little, along the lines of "Error in GC", titled "compiler.exe" I believe, with an "OK" button.  (apologize for the minimal info) 

I have a log/timestamp of when it's occurred -- happy to dig into any other logs you specify to try and provide you additional info.

It continues after a clean install on an entirely different server, as well.  It's fairly sporadic.  Here's an idea of frequency.  5:00a is the server reboot time:

2021-11-18 5:08:02.37
2021-11-19 5:11:01.95
2021-11-22 5:09:40.99
2021-11-26 21:50:53.81
2021-11-28 5:06:35.68
2021-11-29 5:06:29.44
2021-12-02 5:11:18.39
2021-12-03 5:10:33.40
2021-12-04 5:09:34.25
2021-12-08 5:07:38.10
2021-12-09 5:04:58.14
2021-12-12 5:09:52.28
2021-12-16 5:07:00.05
2021-12-17 5:10:15.46
2021-12-21 5:07:42.30
2021-12-25 5:04:55.98
2021-12-29 14:13:03.26

Happened again today after an out of cycle reboot around 2p.

Recreated  Looks like it happens every 1-4 reboots reliably.  Rebooted 5 times: here it is:   
Window Title: Fatal error in gc
Windows Test: Too many heap sections

There's an OK button to press.

I am having a similar issue. It happens when I edit and save plugins with many dependencies quickly. 

Yup.  I finally identified the cause as well: I had a script that ran shortly after server startup, downloading/updating all mods.  The delay between each was too short (2m) and increasing the delay between mod updates fixed.  Sounds similar.