It is hard to create a definitive troubleshooting guide when the code is in flux IMO

 

Regards

bs

So far we have built 17 systems specifically for this sim. Pretty equally split between Steam and MS accounts. They range from 9th Gen i5 to 10th Gen i9. Video from 1660Ti to 2080ti. All with quality hardware. All downloaded and installed flawlessly, all setup the visuals based on their ability, all have been working great according to feedback from customers. 

5 minutes ago, bean_sprout said:

It is hard to create a definitive troubleshooting guide when the code is in flux IMO

That is very true. Frequent releases will always expose new issues with drivers, OS frameworks, Bios shortcomings, and other software incompatabilies. 

Edited October 2, 20205 yr by OneOfMany

Outcome: Working
OS: Windows 10 Home (64 bit)
CPU: Intel I9 10900k
Motherboard: MSI Z-490 Carbone
GPU: RTX 2080Ti  (latest driver 456.55)
RAM: 32 GB
Drive: M2-SSD 1TB
Resolution: 3440x1440
Internet: 250-100 Mbps
Joystick: Thrustmaster Hotas Warthog, VKB-SIM T-Rudder Pedals MK.IV. 
MSFS Version: Steam
Install Location: Drive C
Antivirus: MS Defender
Overclocking: CPU/GPU (No)

Comments: Zero issues installing MSFS. Zero issues with MSFS patchs/updates.

Edited October 2, 20205 yr by Ixoye

IMO, AVSIM is not the place for this type of trouble shooting, who is going to look at this data and make the decisions on what the issues are. Microsoft/Asobo should have an online data base where this info can be entered. This should include computer specs, addons, error codes, MSFS version and if running without or with issues. It should also be required to be able to attach config files. For example, if add-on XYZ  is common with users having issues then MS/Asobo should work with them and solve the issue. If people are tweaking their settings and causing issues, this would show up in the data as well.

59 minutes ago, OneOfMany said:

As owner of a pc business for twenty five years, I have seen instances of every piece of software failing on every OS, from DOS to Mac to Linux and every flavor of Windows on thousands of pieces of diverse hardware. 

Unless it is a bug that is known to exist in the software, buggy drivers, or previous tweaking by customer based on something they read to gain better performance, installation of rogue software, or ways to shield themselves from the prying eyes of their OS (a big one with Win 10), it is hardware. 99%

Hardware 99% of the time?

No, that's irrelevant when there is no change in the user's hardware and OS, and a new patch arrives that causes problems. Like the last one is doing with LOD and a crash when opening the VFR map.

I understand that some user configs are rife with issues. I've seen some very squirrely setups when trying to help others. But when a user's hardware is stable, and works fine not just with this sim but with every other flight sim and AAA PC games, and it crashes and shows major bugs with this one, it's not the hardware at fault.

3 hours ago, RobJC said:

Motherboard: ASUS Z97 Pro

Was a killer board when released. Can't say we had problems with any we built with.

 

Conreast the myriads of word not allowed boards used in so called gaming rigs sold to those who don't know better.

Or even worse, the standard word not allowed in the average big box brand name PC that customers put an actual gaming card in after the fact and wonder why performance is dismal. 

Chipsets overheat, voltage regulation is barely working, the 500w power supply can't output enough amps to spool up a couple of mechanical drives. RAM is the cheapest they can source, with timings so loose the CPU forgets what it is fetching.

This is why although I applaud your desire to help, I don't think it is viable in the Grand scheme of things, as there are way too many variables. 

When guys put the 426 Hemi into a Dodge Colt it crashed often too

 

 

 

Hello all, 

Below is a quote from Johncott,

"IMO, AVSIM is not the place for this type of trouble shooting, who is going to look at this data and make the decisions on what the issues are. Microsoft/Asobo should have an online data base where this info can be entered. This should include computer specs, addons, error codes, MSFS version and if running without or with issues. It should also be required to be able to attach config files. For example, if add-on XYZ  is common with users having issues then MS/Asobo should work with them and solve the issue. If people are tweaking their settings and causing issues, this would show up in the data as well."

My opinion is that the community have already solved a lot of issues, which have been adopted (to my knowledge) by Asobo. The community may not be best placed to evaluate this data, but one never know when a "bright spark" may pick up on a commonality.

It is important, however, that the problem children (expression only...not a comment) put their systems etc up here as well and for them to be as exuberant doing so as they are putting their complaints or hassles into the forum.  If only the people who are problem free are doing this, we cannot really expect any sort of comparisons with which to work.

As far as the configs are concerned, those with config issue expertise should probably ask for the configs from individual users if they think they may have a lead to work with. 

It may well be very interesting to see if we can get an outcome.

One thing we should definitely not underestimate is the communitys' ability to troubleshoot.

Tony

 

The troubleshooting process should always begin with the Windows logs.  It is simply a matter of teaching someone how to read them and what to look for.

Cheers

bs

We need more data. Working is just as valuable as Not Working. 

1 minute ago, Paraffin said:

No, that's irrelevant when there is no change in the user's hardware and OS, and a new patch arrives that causes problems. Like the last one is doing with LOD and a crash when opening the VFR map.

LOD is a known issue, and another user has found a change in a config file that probably caused it. That is a software bug. 

And I agree that the vfr map issue is more than likely a bug, as it was introduced only since this patch. 

I certainly am not saying that this software is bug free, none are. 

What I am referring to is people encountering ctds all the time, stuttering on graphic cards that others are using successfully. This is usually caused by software conflicts. Bios level, driver level or service level. If you can't resolve these on a particular system with fully updating firmware and drivers on fresh installed clean OS, properly timed and benchmarked, it's hardware. In this particular software, a lot more demand is placed on the NIC, and I ain't gonna lie, the average on board one sucks both on a hardware and more importantly, on a driver level. 

1 minute ago, OneOfMany said:

LOD is a known issue, and another user has found a change in a config file that probably caused it. That is a software bug. 

And I agree that the vfr map issue is more than likely a bug, as it was introduced only since this patch. 

I certainly am not saying that this software is bug free, none are. 

What I am referring to is people encountering ctds all the time, stuttering on graphic cards that others are using successfully. This is usually caused by software conflicts. Bios level, driver level or service level. If you can't resolve these on a particular system with fully updating firmware and drivers on fresh installed clean OS, properly timed and benchmarked, it's hardware. In this particular software, a lot more demand is placed on the NIC, and I ain't gonna lie, the average on board one sucks both on a hardware and more importantly, on a driver level. 

Right. Take RAM. Just because you think you had a stable system before MSFS, you could have faulty RAM that just never gets pushed hard enough to expose the issue. This sim exposes flaws. 

Also your Windows Build version can be important.  Should add that to the list.

1 minute ago, OneOfMany said:

What I am referring to is people encountering ctds all the time, stuttering on graphic cards that others are using successfully. This is usually caused by software conflicts. Bios level, driver level or service level. If you can't resolve these on a particular system with fully updating firmware and drivers on fresh installed clean OS, properly timed and benchmarked, it's hardware. In this particular software, a lot more demand is placed on the NIC, and I ain't gonna lie, the average on board one sucks both on a hardware and more importantly, on a driver level. 

Beansprout has said that the windows logs ie start, event viewer, windows logs and open will reveal the problem. If the log cannot be worked out or interpreted by the computer owner, maybe they could elaborate by enclosing the log/s along with the original problem.  This is of course, information that Asobo is probably not privy to, and that just compounds the problem, or at least does not help.  The community could be a huge help in this respect.

It may well be an even better idea if combined with computer specs if known.

Tony

1 hour ago, OneOfMany said:

So far we have built 17 systems specifically for this sim. Pretty equally split between Steam and MS accounts. They range from 9th Gen i5 to 10th Gen i9. Video from 1660Ti to 2080ti. All with quality hardware. All downloaded and installed flawlessly, all setup the visuals based on their ability, all have been working great according to feedback from customers. 

I reinstalled Windows (formatted the drive to start) coincidentally just before this sim launched. So my install was clean to begin with.