Intermittent freezes ("ANTIFREEZE ENABLED")

[RJLee]

Hi all--

Lately I've been getting the same intermittent freezes that others have reported -- i.e., not stuttering or micropauses, but a complete image freeze that continues for anywhere from 5 to 30 seconds.  During these freezes, audio continues to play but other world activity seems to stop, and at the end the simulation continues (interestingly, I have not had DCS crash).  These are reliably associated with the usual pair of opaque entries in dcs.log that everyone reports ("ModelTimeQuantizer: ANTIFREEZE ENABLED", followed within ~0.2ms by "ModelTimeQuantizer: SAME MODEL TIME").  It doesn't happen every session, it doesn't seem to matter whether I restart DCS (or my computer) between sessions, and it doesn't seem to follow any particular pattern that I can see (happens across multiple aircraft in scenarios of varying sizes, though I'm mostly flying very simple sorties with few objects).  I've tried different suggestions that people have made (here, on reddit threads, etc.), but so far no luck.

I did want to share a data point that might be helpful to those of you who are smarter than I am on this stuff.  Today I was getting freezes while in one of the AH-64 basic tutorial missions, so I alt-tabbed out to desktop, opened the Task Manager, and just watched.  At this time the simulation was in active pause waiting for me to hit the spacebar to advance the tutorial; I was in VR watching the Task Manager.  At this time Task Manager showed CPU utilization at ~30%, RAM at ~52%, and GPU at ~60%; VRAM utilization looked to be about 66%; nothing special showed up in the process list.

Every few minutes the simulation would freeze.  While frozen, GPU utilization spiked to 98%.  CPU did not increase (it actually fell to 20%, presumably waiting on the GPU), VRAM did not change, Task Manager process list did not change.  Of the GPU tasks, it was the "3D" task that accounted for all of the increase (I'm on a Quest 3 using Virtual Desktop and the video encode/decode tasks remained the same).

What's interesting to me is that I was not interacting with the sim (though it continued to track my head position).  Indeed, DCS did not appear to be doing very much at all -- it was waiting in active pause during a gunnery training mission (a few infantry units are waiting on an airfield to be shot with 30mm).  But despite all this, obviously DCS was doing something in the background that overloaded the GPU's "3D" thread and brought everything to a stop.  

Then, like magic, it would all come back (sometimes the VR view would spin and shudder for a few seconds before it recaged), and the numbers would return to a steady state.  This went on repeatedly, until I thought I had seen enough and ended the mission.

I don't know if Task Manager's reporting is reliable, or what any of this means.  But I thought it might be useful to those of you who are better informed.  I've also attached my dcs.log in case there are more clues there, though I don't need any individualized analysis at this point (so don't feel obligated).  Hopefully someone can get to the bottom of this soon!

Intel i7-13700KF, 32GB DDR5, WD Black SN770 NVMe, RTX 4090/latest drivers, Quest 3/Virtual Desktop, assorted Winwing gadgetry.  Win 11/23H2 (power plan set to "ultimate performance")

 

dcs 20251109.log

Edited Sunday at 10:09 PM by RJLee
formatting fix

[The_Nephilim]

Well 2 things stand out:

 

2025-11-09 19:38:34.280 WARNING EDCORE (Main): CPU HAS PARKED LOGICAL CORES (this can be source of stuttering and reduced performance especially on hybrid CPUs with P/E-cores)

 

and you are running Tacview, this could also cause stutters ingame.. also do you use any mods? It did not look like you did but I just did a quick through.. when you installed the nvidia drivers did you use DDU to uninstall the new ones and did you debloat the nvidia drivers before installing them?

[sleighzy]

As The_Nephilim said, turn off core parking. You can use software like ParkControl to disable it for all your power management profiles.

In addition to this temporarily remove the Scripts\Hooks\bhHook.lua file as well. It's the export hook for the UH-60L AI gunners. Potential to be perf problem. You can add it back afterwards.

You're also running WinWing MFDs, I'm fairly sure you're not running DCS as administrator as you may have noticed issues in the ingame menu screen as well. However, just double-check you aren't (your username in the log file was redacted so can't tell from that) but check the properties for your DCS shortcut and exe file (both in bin and bin-mt) to make sure "Run as administrator" isn't ticked under the Compatibility tab from the properties menu.

[ARM505]

I have the same. I do not run tacview and I have ensured all cores are unparked.

It has defeated me, I have tried everything I can find here, but it still occasionally happens exactly as described above (including the dcs.log showing the 'ANTIFREEZE' message). The worst is when it happens on spawn in (although this may be a slightly different problem) - after platform selection, the sim can 'hang' with one CPU core sitting at 100%, the rest (everything, including RAM, drive activity, GPU) just absolutely chilling out and having a wonderful day. Then, when I do actually spawn in, somebody else has already taken the parking spot, and the natural result of two objects occupying the same space happens (explosion).

[RJLee]

First, thanks for sharing your expertise and experience so quickly.  This stuff is messy and every little bit of insight helps.

It's too early to declare victory, but I made the suggested changes and experienced no freezes during testing tonight.  I examined the dcs.log and did see two instances of the ANTIFREEZE ENABLED warning, but they appeared to be during initial mission entry (maybe during the loading screen, maybe when the cockpit textures are loading) and I did not notice them.  This might be what ARM505 is describing (I agree that this seems like a different problem than the mid-mission freezing).

For the record, here's what I did so far:

1.  Generated a debloated version of the latest NVIDIA driver using NVCleaninstall (https://www.techpowerup.com/download/techpowerup-nvcleanstall/).  Did a clean uninstall using DDU (https://www.guru3d.com/download/display-driver-uninstaller-download/).  Reinstalled the debloated driver.  (Note:  this requires a safe mode reboot, and there is a recent Windows security bug that locks all USB mice/keyboards out of safe mode.  Microsoft just patched this last week so if you try this now you may have to do a Windows Update.)

2.  Forced core parking off using ParkControl.  (I thought that merely selecting Windows' own "ultra performance" power plan does this, but it does not.)

3.  Renamed the bhHook.lua script.

Other things:  TacView was already disabled in the special options, so I didn't do anything to it.  I do have Winwing MFDs but they are disconnected in the Windows display settings (I don't use them with DCS).  I don't run DCS as administrator.  I don't have any mods other than the community A-4E and the UH-60L.

I'll continue to test over the next few days and will report back.  Thank you again -- you guys are great.

[The_Nephilim]

13 hours ago, ARM505 said:

I have the same. I do not run tacview and I have ensured all cores are unparked.

It has defeated me, I have tried everything I can find here, but it still occasionally happens exactly as described above (including the dcs.log showing the 'ANTIFREEZE' message). The worst is when it happens on spawn in (although this may be a slightly different problem) - after platform selection, the sim can 'hang' with one CPU core sitting at 100%, the rest (everything, including RAM, drive activity, GPU) just absolutely chilling out and having a wonderful day. Then, when I do actually spawn in, somebody else has already taken the parking spot, and the natural result of two objects occupying the same space happens (explosion).

I would suggest starting your own thread and add a DCS Log file so others can have a look. system specs would help as well.. that spawning in issue should not happen and is a seperate issue..

12 hours ago, RJLee said:

First, thanks for sharing your expertise and experience so quickly.  This stuff is messy and every little bit of insight helps.

It's too early to declare victory, but I made the suggested changes and experienced no freezes during testing tonight.  I examined the dcs.log and did see two instances of the ANTIFREEZE ENABLED warning, but they appeared to be during initial mission entry (maybe during the loading screen, maybe when the cockpit textures are loading) and I did not notice them.  This might be what ARM505 is describing (I agree that this seems like a different problem than the mid-mission freezing).

For the record, here's what I did so far:

1.  Generated a debloated version of the latest NVIDIA driver using NVCleaninstall (https://www.techpowerup.com/download/techpowerup-nvcleanstall/).  Did a clean uninstall using DDU (https://www.guru3d.com/download/display-driver-uninstaller-download/).  Reinstalled the debloated driver.  (Note:  this requires a safe mode reboot, and there is a recent Windows security bug that locks all USB mice/keyboards out of safe mode.  Microsoft just patched this last week so if you try this now you may have to do a Windows Update.)

2.  Forced core parking off using ParkControl.  (I thought that merely selecting Windows' own "ultra performance" power plan does this, but it does not.)

3.  Renamed the bhHook.lua script.

Other things:  TacView was already disabled in the special options, so I didn't do anything to it.  I do have Winwing MFDs but they are disconnected in the Windows display settings (I don't use them with DCS).  I don't run DCS as administrator.  I don't have any mods other than the community A-4E and the UH-60L.

I'll continue to test over the next few days and will report back.  Thank you again -- you guys are great.

hopefully that  cures it.. maybe it was a corrupted nvidia driver install..