WWSmith

Strange that it only happened to you after the last update. MT hasn't worked for me since either the initial release or the very first update, I can't remember now. This morning I thought that underclocking might have fixed it, but then I had another DX Device Removed crash this afternoon. Unless I just need to underclock more, I'm all out of ideas.

No joy. I just had 2 CTDs in the past hour. I'll try reducing clock speed more, but I'm not hopeful. Edit: the last CTD was not the DX Device Removed error. The log file from the one before that appears corrupt, because I can't open it, but the most recent was caused by a problem with an Apache texture, unless I'm reading this wrong. I've attached the log. I'll continue testing with a different module. dcs.log-20230701-140147.zip

Somewhat confusingly, MSI Afterburner only shows the boosted speed, whereas GPU-Z gives both the base and boosted speeds. In any case, both were above the manufacturer standard, so I used Afterburner to set it just below the recommended boost speed. I played about an hour last night and two hours this morning without a CTD yet.

TonnyArno, I tried your suggestion and found that my GPU was actually overclocked from the factory. I'd never considered this possibility before, having never tinkered around with hardware tuning, and just assumed that so long as I didn't overclock anything, then it wasn't overclocked. Anyway, I turned down the clock speed using MSI Afterburner. I've only just done this, and flew for about half an hour without a CTD, but I'll report back after more thorough testing.

It looks like you're using an AMD GPU. Which one exactly? Me and lots of other people on here with 5700XTs can't play DCS MT, and we've heard nothing about a fix since April. While the issue isn't unique to this 5700XT, there seems to be something about this GPU in particular which makes it especially incompatible with DCS MT. Like you, I have no problem running DCS ST.

Is any progress being made on this front? It seems like anyone with a 5700 XT can't run MT, myself included. I've attached a crash log from the most recent OB, which still has this bug. There's also another recent thread about this issue: dcs.log-20230604-211539.zip

I had the same issues with Mission 2. The Mig-29s turned tail when I was 100 NM away, but Jester acted like they were engaging us. He then couldn't lock any of the 21s, but I was still able to lock and splash one on my own. Then I never got cleared to depart my CAP station, probably because the Fulcrums were still out there, at which point I concluded that something was broken and quit before trying to find the tanker.

No idea if it's driver or hardware related, and neither I nor anyone else posting on here has found a solution, but it's an acknowledged bug, so hopefully someone at ED is investigating.

It's a known issue, which seems to be associated with the 5700XT.

I agree that ST is stable in the current OB. Syria is a very GPU-intensive map, probably the worst in that regard, while Caucasus is probably the least so. On the other hand, for me anyway, the CTDs haven't been related to GPU workload. As part of my troubleshooting efforts, I was checking the resource monitor during flight, and the GPU might only be running at ~75% and 50 C when DCS crashes.

Unfortunately I eventually had another crash, even with the registry edit. It seems to have helped, because before the CTDs were constant when playing with multithreading, but it hasn't eliminated the problem.

I learned about it from this thread: https://forum.dcs.world/topic/252769-crash-switching-from-f1-view-to-f10-and-back/ There's a good tutorial here: https://substance3d.adobe.com/documentation/spdoc/gpu-drivers-crash-with-long-computations-128745489.html I played a couple more hours this morning with no crash. I'm keeping my fingers crossed.

I always used to have VSYNC on, and turned if off as part of my troubleshooting efforts, which actually reduced my GPU load a little. It didn't stop the crashes, but it still seems like a step in the right direction.

Very interesting. I also have a 5700 XT, and have been getting an insane number of "DX device removed. Reason: 0x887A0006" CTDs with multithreading. This was never a problem for me before MT. To troubleshoot, I have thus far: -removed all mods -updated graphics driver -uninstalled and reinstalled graphics driver -run a full (slow) repair of DCS -rolled back to the original MT OB version -rolling back didn't help so updated to latest version -disabled all automatic features of AMD's Adrenalin Software -not overclocking -set Windows power plan to "performance" -turned up GPU fan speeds (it wasn't overheating to begin with, but better safe than sorry) -played with just about every graphics setting in DCS -added TdrDelay and TdrDdiDelay registry keys This last one seems to have fixed the problem...maybe. I just tried that yesterday, so I can't say whether it's really fixed the problem or merely reduced the frequency of crashes to a somewhat-acceptable level. I've uploaded a heap of crash logs, but can post some here, too, if anyone wants.

I seemingly fixed the Viggen by removing the A-4 mod, successfully flying 2 sorties which had previously ended in CTDs, and then decided to try the Hornet, since I hadn't flown it in quite a while and wanted to see if it had any issues. The result was constant CTDs, all with logs showing DXGI_ERROR_DEVICE_REMOVED. A few hours later, I had seemingly fixed this, which I think I inadvertently caused by reinstalling my graphics driver while troubleshooting the Viggen issue. AMD's software likes to be meddlesome, and some settings which I'd probably turned off ages ago were re-enabled. The Hornet worked for a little while, then CTD'd again. After more digging on the forum, I found a thread about this exact issue: So, long story short, it's not any specific module, and supposedly it's being fixed in the next update. In any case, DCS currently seems a lot more stable in single-thread, so that's what I'm sticking with for now.

I seem to have fixed the Viggen CTDs by removing all mods (I hadn't installed anything new recently, but maybe something old doesn't play nice with MT--I'll have to try to narrow that down), and running a full repair. The Apache CTD I mentioned earlier is connected to a specific instant action mission.

Thanks for replying. It sure would be nice if AMD notified users when there's an update, but I've now updated my drivers, and I'm not using Steam. I switched to MSAA, having found the notice in the MT bugs section about turning off SSAA. I also ran DCS repair. Anyway, long story short, it's not Viggen-induced, after all, because I just had 3 CTDs with the Apache this morning.

Well, it looks like my problem is not exclusive to multithreading, after all, because I've also had a couple CTDs with the Viggen without multithreading. I've been flying the Mi-8 and Mirage 2000 a lot with no trouble, so it seems to be something Viggen-related. Anybody else having issues lately? dcs.log-20230329-111659.zip dcs.log-20230409-000027.zip

I've tried playing the Mjolnir Response campaign recently, and have had CTDs on each of the first three missions, but only when using multithreading. I've attached the logs. dcs.log-20230322-140626.zip dcs.log-20230324-113944.zip dcs.log-20230325-115047.zip

Since this doesn't seem to be getting much attention, I'll confirm that this is a problem for me, too. Try any of the road base instant action missions, and you'll find AI Viggens sitting with their afterburners going.

I guess I should have been more specific when I said that it's fixed for me, although I described my issue earlier in this thread. Anyway, my problem was that, with a force feedback stick, attitude hold was not holding attitude whatsoever at any speed. It did originally, then a couple of patches ago it was changed so that its control authority was extremely weak and couldn't compensate for any mechanical play in the stick, and now it works again. If you don't have force feedback, or maybe a spring-centered stick with a weak spring, then you probably never experienced this problem at all.

Today's Open Beta update fixed attitude hold for me.

Ok, so I just read up on the controls indicator, since I never normally use it. I see what you mean about the white diamond drifting slightly when I let go, which is a consequence of my FFB stick's small mechanical deadzone. (Not sure of the proper term, but basically the magnets aren't applying force within a very small range of center, so the stick can move slightly when I release it.) However, this shouldn't be enough to override the SCAS, as explained here: I just flew again with the controls indicator on-screen this time, and the white diamond never comes near the edge of the rectangle, so unless I'm misreading this, the SCAS should have no trouble holding a hover. Instead, it seems that the tiniest input is enough to override it.

Just for the sake of it, I tried your exact settings, and they made the Apache borderline unflyable for me. Adding any deadzone causes the stick to jump every time I press the trim button, making trimming incredibly difficult, and any but the mildest curves have the same result. I already wasted 3-4 hours experimenting with curves and deadzones, as I mentioned in the thread below, and the lesson I learned was that these don't react well with FFB and a helicopter's force trim system. In any case, the Apache's attitude hold used to work perfectly for me, while the Mi-24 and Ka-50 still work perfectly for me, so something must have changed with the Apache.

Nuts. I was hoping that force feedback was the common thread here. Otherwise, I can't figure out why some of us have this issue and most apparently don't. I'm not using any curves or deadzones, and saturation is at 100%.