ags

The answer is: 64GB, given how popular „set a large pagefile” recommendation is.

It's not about the swap file per se - if DCS runs stable with X of RAM and Y of swap, it should run fine with (X + Y) of RAM, and swap disabled. DCS, especially with Syria, actually requires a system with 64GB of RAM.

Well, added a task to clean old temp files. Let's see if that helps.

I did afterwards. There was plenty of free space on the drive - does DCS have problems with temp directories that contain anything?

DCS dedicated server, crashed with same error as reported previously. Help would be appreciated. 2021-02-09 20:20:48.331 INFO EDCORE: E:\DCS World OpenBeta Server\bin\DCS.exe 2021-02-09 20:20:48.332 INFO EDCORE: # C0000005 ACCESS_VIOLATION at F407C80D 00:00000000 2021-02-09 20:20:48.334 INFO EDCORE: SymInit: Symbol-SearchPath: '.;E:\DCS World OpenBeta Server;E:\DCS World OpenBeta Server\bin;C:\Windows;C:\Windows\system32;SRV*C:\websymbols*http://msdl.microsoft.com/download/symbols;', symOptions: 530, UserName: 'Gildias1s2' 2021-02-09 20:20:48.335 INFO EDCORE: OS-Version: 10.0.19042 () 0x100-0x1 2021-02-09 20:20:48.952 INFO EDCORE: 0x000000000046C80D (DCS): CoreUtils::TempFilesManager::operator= + 0x7EC5D 2021-02-09 20:20:48.952 INFO EDCORE: 0x0000000000487EE3 (DCS): CoreUtils::TempFilesManager::operator= + 0x9A333 2021-02-09 20:20:48.952 INFO EDCORE: 0x0000000000496CC1 (DCS): CoreUtils::TempFilesManager::operator= + 0xA9111 2021-02-09 20:20:48.952 INFO EDCORE: 0x00000000000FF683 (edCore): Mail::Reader::stream + 0x1473 2021-02-09 20:20:48.952 INFO EDCORE: 0x000000000093470F (DCS): CoreUtils::TempFilesManager::operator= + 0x546B5F 2021-02-09 20:20:48.953 INFO EDCORE: 0x0000000000934C91 (DCS): CoreUtils::TempFilesManager::operator= + 0x5470E1 2021-02-09 20:20:48.953 INFO EDCORE: 0x000000000094868B (DCS): CoreUtils::TempFilesManager::operator= + 0x55AADB 2021-02-09 20:20:48.953 INFO EDCORE: 0x00000000009248AE (DCS): CoreUtils::TempFilesManager::operator= + 0x536CFE 2021-02-09 20:20:48.953 INFO EDCORE: 0x00000000009139F2 (DCS): CoreUtils::TempFilesManager::operator= + 0x525E42 2021-02-09 20:20:48.953 INFO EDCORE: 0x00000000007BFBD4 (DCS): CoreUtils::TempFilesManager::operator= + 0x3D2024 2021-02-09 20:20:48.954 INFO EDCORE: 0x0000000000790A04 (DCS): CoreUtils::TempFilesManager::operator= + 0x3A2E54 2021-02-09 20:20:48.954 INFO EDCORE: 0x0000000000790DC9 (DCS): CoreUtils::TempFilesManager::operator= + 0x3A3219 2021-02-09 20:20:48.954 INFO EDCORE: 0x0000000001904FF3 (DCS): AmdPowerXpressRequestHighPerformance + 0xC96FEF 2021-02-09 20:20:48.954 INFO EDCORE: 0x000000000098580E (DCS): CoreUtils::TempFilesManager::operator= + 0x597C5E 2021-02-09 20:20:48.954 INFO EDCORE: 0x0000000000017034 (KERNEL32): BaseThreadInitThunk + 0x14 2021-02-09 20:20:48.954 INFO EDCORE: 0x000000000004CEC1 (ntdll): RtlUserThreadStart + 0x21 2021-02-09 20:20:51.882 INFO EDCORE: Minidump created. dcs.20210209-202047.crash dcs.20210209-202047.dmp dcs.20210209-202047.log dcs.20210209-202047.miz dxdiag.txt hash

I just got into here by googling a DCS crash of mine. What does your Event Log say for around the time this error occurred?

Dedicated server crashed during mission, generated zip attached. dcs.log-20210204-205656.zip

Funny enough, now that you have requested a message from Error Log, my DCS started being more stable.

0. First dcs.log correctly picks up an 8GB pagefile, this has been increased to 32GB. 1. Running long-lasting tests for CPU, memory, and ovearall stress is something I have already done, no faults. I’ve increased amount of pagefile since the original post, it is now set at 32GB permanenty - what would you expect to change if dynamic sizing would be allowed? I’ll start logging these values from other software then. To my eye, which lacks insight into DCS under the hood, scenario to trigger an overflow is rather simple - fly in a vanilla (as in, no mods) multiplayer server, keep shooting at things, die multiple times. DCS crash ensues. I so far hold my opinion DCS is too aggressive in how VRAM is being used, and releasing this resource is not happening as expected. As a sidenote, log sometimes mentions polygon gc cycles going into 10s of ms. I’d say this is „long”, and should be faster, or ceased after a smaller threshold value.

I am running Defender only, and these folders are already defined as exceptions.

C:\Users\ags>wmic pagefile list /format:list AllocatedBaseSize=32768 CurrentUsage=227 Description=C:\pagefile.sys InstallDate=20210108133840.734843+000 Name=C:\pagefile.sys PeakUsage=1476 Status= TempPageFile=FALSE And dxdiag is attached. VRAM usage still keeps climbing. DxDiag.7z

Cleaned mods, played online, VRAM kept growing, crashed around <21GB occupied. Track, dcs.log, and gpu-z log https://www.dropbox.com/sh/7yh244grqsbel1e/AAC2t023eaOoZXgPP0SgCxhLa?dl=0

hardware ID mismatch is easily explained by a bios update.

I'm experiencing repeated crashes with 2021-01-07 21:30:18.619 ERROR DX11BACKEND: failed to create structed buffer. Reason: E_OUTOFMEMORY 2021-01-07 21:30:18.619 ERROR DX11BACKEND: CreateShaderResourceView FAILED. Reason: E_INVALIDARG I'm on a not-overclocked 5950x, using a G1, and a non-overclocked MSI 3090. Current OS, drivers and DCS openbeta. Logs attached, and an gpu-z log as well, that shows memory usage growth. Windows is a fresh install (Sunday, 3rd Jan). Help appreciated. gpuz_log2020g.7z dcs.7z dcs.log.old.7z

Both are free flight, F18, PG, low level one way, reverse, low level the other, but driven by hand.

This looks great, as long as somebody plays low fi models in SP. Throwing in a high fidelity model, and everything goes away. Similar low level passes over Persian Gulf produce:

After speaking to HP, I will need to get a replacement, it's not a fault of DCS - there is miscalibration in the device. For comparison, here is a G1 screenshot:

Hi. After spending time on getting x570 + G2 work together, I stumbled into another problem - image is misaligned, and this effect is magnified when using spot zoom, see picture: (horizontal line and 45 degree lines are for reference) I've tried cross eye tool, but I can't get both normal and zoomed picture work well together. Naturally, G1 had no problems in this domain.

Hi. I am a software engineer by day, and enjoy flight simulators by hobby, and this particular software family since Flanker times. I do admire the effort and workload put into DCS, and what many great things it allows. I know very well software is hard, living with a legacy codebase is harder, and that the domain of high-fidelity simulation is another step in complexity. What doesn’t resonate with my professional point of view, is the reduced frequency and unpredictable cadence of releases, and their detrimental effect to perceived quality. I do not claim to say whether it should be once every week or two weeks, but there is an agreement among software professionals that a regular delivery cycle positively impacts quality. How are "wrong branches" ending up in a release is beyond me. There is only one answer here - have a process, automate it, let people make decisions, let computers do the work. It is also agreed that automated testing is beneficial to the state of software. You do have the “replay track” feature, as well as certain pre-set missions, I would expect it possible to automate a check, for example, if radar, using a certain location (given! known up front!), can see and lock a target. Similarly, if it can get rid of this target using a variety of ways. Let computers do the repeatable work, this is what they are for! Bad releases do happen. But getting fundamental things broken repeatedly leads to questions. Getting them wrong over and might be funny to some. Again, you have said old codebase, netcode etc. I get it. But these are within your control. Software engineering is not something invented 2 years ago. So is testing, continuous delivery, etc etc etc. What I would like to see, as a user, is a continuous, positive trend. I don’t care about a training bomb for the F18. I don’t care about SLAM, as much as I care about being able to first take off and land, and then get rid of some near air threats. I would like radar to work, and I would like basic weapon systems to be available. From managing expectations point of view, this means: pause new features, fix things. Have a look at the release model Java adopted - whatever is ready, as a feature, for cutoff date, gets in, anything missed gets into the next one. What could keep happening is a feature release on a Monday, after tests by whoever does testing in the closed realms. That could lead to an easy go/no go decision, not at the last minute. Next patch, after that? Let’s say in one week, only bug fixes, those not critical. New features in two weeks? Sure. Tell us what your regular cadence is, and stick to it. Do we really need to keep asking “is there round the corner”? Getting quality consistently up is IMHO more important than anything fancy for the Hornet. (and Viper deserves this 65D!). This could lead to an improvement for when a hotfix is required, this can be done before the weekend, especially as many serious gaming organisations do run regular events towards the weekend. Some issues, less core (old example: not being able to change audio in flight) can wait, a bit. I would, of course, like to see them fixed, too. I can appreciate some areas (rendering engine, netcode) will take more time. They are doable, evolving software is hard, take some time. How to make things look better? Keep improving small things. “Small” like maps that match airports, default custom kneeboards per terrain, being able to delete some of existing kneeboard assets without affecting integrity checks, or things coming back. Data cartridges for airplanes? It doesn’t need to be a ground target evaporating feature to be “nice”. Restore lost RWR symbols? I am sure you have a list of things like that. Such everyday activities should be quite simple to implement, but will make regular users feel slightly less annoyed (some way before “better”), and make regular use of the simulator a better experience. The effects of the difficult few weeks are here. People I would usually fly with, fly with less. We have been forced to use airstarts, and land boat-based planes on airfields. With some, we are considering rolling back to 2.5.5 stable. Please fix my sim.

Hi, I'm on a reverb, and sometimes get head limits, sometimes don't. Some people suggested it would be first flight of the day, first multiplayer takeoff, second multiplayer takeoff, etc - but so far it's not a rule, it comes and goes. I've tried to find a pattern, but I can only call it random. I first had it in Spit, recently saw in Hornet. Today, in the hornet? Nothing.

And all the other things will be gradually added to the e-store with Early Access option available.

This could be mentioned in the briefing, maybe even as a kneeboard page, it's too surprising! (just started the campaign, and I thought I'm doing something terribly wrong)

I'm on an HP Reverb, so it's going through Windows MR, and Windows MR Steam… If there is a simpler setup, I would love to know :-)

I would be very curious if more VRAM would make any difference to perceived performance. I'm easily reaching 100% VRAM in VR, and if adding a 2nd gpu to take care of HDMI audio and 2nd screen would improve, that's easy.

Hi, you mention Takeoff and "Combat Ready" panels "coming soon" (https://winwing.cn/en/JOYSTICK). What will these contain? Any early sketches?