Problem CPU reboot at Load screen Orbiter16

[creature]

Hello Orbiter People

Been away from OSFS for a while. I recently got a new machine, installed the zip version of Orbiter2016. Starts up great from Orbiter.exe but when I launch a scenario it sends my computer into a reboot.

Been searching for a few hours for a solution but haven't been able to find a solution.

I don't even get a log from the Orbiter log

Windows 10 64bit
Nvidia 1070ti
Powerspec g223

 

[dbeachy1]

Can you run some system stress tests for a few hours, like Prime95 to stress the CPU and, after that, Heaven Benchmark to stress the video card? In my experience, a hard reboot under load is often caused by a hardware problem. Are you overclocking your CPU, video card, or RAM? If so, I recommend resetting all speeds to stock and retesting. Beyond that, I would double-check that your video driver is up-to-date.

 

[Marijn]

Maybe the default DX7 is causing this? Vanilla Orbiter 2016 with DX7 doesn't work on any of my Win10 machines. Perhaps it's worth trying installing the DX9 client.

 

[Trekkie]

Maybe the default DX7 is causing this? Vanilla Orbiter 2016 with DX7 doesn't work on any of my Win10 machines. Perhaps it's worth trying installing the DX9 client.

this shouldnt be the issue DX7 works on Win10 for me

 

[GLS]

Maybe the default DX7 is causing this? Vanilla Orbiter 2016 with DX7 doesn't work on any of my Win10 machines. Perhaps it's worth trying installing the DX9 client.

I don't think it would reboot the pc... :shrug:

 

[DaveS]

this shouldnt be the issue DX7 works on Win10 for me

The problem is the resolution. DX7 supports a maximum resolution of 2048x1536. Anything above that will cause crashes. It's just that DX7 doesn't support the native resolutions of modern monitors (which is normally above the 2048x1536 maximum resolution of DX7). Full HD is defined 1920x1080 which is below the DX7 maximum resolution, but most modern monitors exceed that by going to at least Quad HD(QHD) which has a resolution of 2560x1440 which is above the maximum DX7 resolution.

DX7 is simply just not made to run at the native resolutions of modern monitors and this is hard limit, no way to get around it besides playing at a lower support resolution.

 

[kuddel]

As the others already mentioned:
A CTD (crash to desktop) can be done "easy" by addons / GraphicClients, but a reboot is much harder nowadays
Drivers / Hardware would therefore be my guess as well.

 

[Marijn]

Installing the DX9 client only takes seconds and I assume @creature will want to use the DX9 client anyways. So I think it's the logical next step.

 

[creature]

Thanks everyone for the response.

Did the stress test and graphics test. all good

installed the DX9 client and ran the orbiter_ng.exe and with great happiness it loaded in "full screen" only. when I try windowed CPU reboots.

I'm a big fan of Project Apollo and I'm not sure if that is compatible with Orbiter2016

 

[jangofett287]

Lets be clear here, there should be no way for userland code in Win10 to cause a system reset. This is almost certainly hardware related.

 

[creature]

Love that KISS reference!!

Moved the vanilla Orbiter to different HD and still get a system reset in windowed mode. So for now I'm just using full screen using the _NG.exe. Unfortunately NASSP doesn't seem to play nice with Orbiter 2016. I'll do a search for that one as not to split this thread.

Creature

---------- Post added at 08:35 AM ---------- Previous post was at 02:44 AM ----------

Well I found NASSP V8 and all is right in the world again!!!

So glad this sim is still running strong.

 

[Marijn]

What happens if you launch the orbiter.exe and select full screen mode as well instead of windowed mode? Does your system reboot? Care to try?

---------- Post added at 08:15 PM ---------- Previous post was at 07:38 PM ----------

On my laptop, the default 'auto-select' setting in the Nvidea config screen (right mouse click on desktop), is actually setting the onboard Intel HD 4600 graphics while not running games. Using this default setting, Orbiter won't list the GTX in the 3d-devices on the video tab. It only lists the 4600.

So I have to run the GTX at all times by explicitly setting this in the Nvidea config. Then I can select the GTX properly in Orbiter. Nvidea's mechanism to wake up the GTX when orbiter_ng.exe is launched is not working for me.

Perhaps there is a problem with waking up your GTX. Maybe a sudden power drain is causing your system to reboot. If only hardware can cause a system reboot, then wat possible options remain? Go see if your GTX is awake at all times. If not, set it so and test again.

 

[DaveS]

What happens if you launch the orbiter.exe and select full screen mode as well instead of windowed mode? Does your system reboot? Care to try?

---------- Post added at 08:15 PM ---------- Previous post was at 07:38 PM ----------

On my laptop, the default 'auto-select' setting in the Nvidea config screen (right mouse click on desktop), is actually setting the onboard Intel HD 4600 graphics while not running games. Using this default setting, Orbiter won't list the GTX in the 3d-devices on the video tab. It only lists the 4600.

So I have to run the GTX at all times by explicitly setting this in the Nvidea config. Then I can select the GTX properly in Orbiter. Nvidea's mechanism to wake up the GTX when orbiter_ng.exe is launched is not working for me.

Perhaps there is a problem with waking up your GTX. Maybe a sudden power drain is causing your system to reboot. If only hardware can cause a system reboot, then wat possible options remain? Go see if your GTX is awake at all times. If not, set it so and test again.

I think we can rule out this as the source of his issues. Based on the first post, he using a pre-built desktop system, namely this one: https://www.microcenter.com/product/507160/powerspec-g223-gaming-desktop-pc

 

[Marijn]

I think we can rule out this as the source of his issues. Based on the first post, he using a pre-built desktop system, namely this one...

According to the link you posted, it's an B360-A Pro system board and therefore has Intel HD Graphics support.

I think @creature should look carefully on Orbiters video tab and make sure the 3d-device selected there is not the Intel chip. It should be the Nvidia GTX.

Can you confirm @creature?

 

[creature]

I appreciate this!! Full screen mode is a bit of a bother when I need to look up checklists or procedures

My option under the video tab from the Orbiter.exe with windows reboot are:

RGB Emuluation
Direct3d HAL
Direct3d T&L HAL
Direct3d HAL NVIDIA GeForce GTX 1070ti
Direct3d T&L HAS NVIDIA GeForce GTX 1070ti <--current option selected

With The Orbiter_NG.exe and no crash I only have one selection

NVIDIA GeForce GTX 1070ti

---------- Post added at 10:55 PM ---------- Previous post was at 10:51 PM ----------

and just so you know I do have NASSP 8.0 running on another installation of Orbiter using full screen and the NG.exe file. I'm not gonna mess with that one until I can figure this out on the vanilla installation of Orbiter

---------- Post added at 10:56 PM ---------- Previous post was at 10:55 PM ----------

I forgot how much I liked this program!!!!

 

[Linguofreak]

Lets be clear here, there should be no way for userland code in Win10 to cause a system reset. This is almost certainly hardware related.

Well, either hardware or kernel-mode code (OS, drivers). Given that the last DOS-kernel version of Windows was released almost 20 years ago now, the OS itself should be solid, so either hardware or drivers. I suppose you could say that buggy drivers are hardware related, but most driver related crashes have to do with the driver scribbling over critical kernel data rather than causing the hardware it drives to do nasty things to the system electrically, so I tend to classify them as software bugs.

In any case, any time you get bluescreens or reboots in a 3D application, your GPU drivers are almost always the culprit. After that, it's either some other 3rd party driver, Windows, or a physical problem with the hardware (bad RAM, bad motherboard, etc).

 

[creature]

Tried "windowed" mode today

RGB option it loaded but FPS were very low

all other options=reset

I ve had no other issues with this PC or video card on other graphic intensive sims.

Obviously I don't like to keep crashing my computer so I may give it a rest for a while and just continue to use the Full Screen option. If I come up with anything or a solid log file I will post it. In my opinion, I think it may be the Nvidia driver. My current version is 430.86. There is a new one out but from past experience with Nvidia, "don't fix what ain't broken". My only issue is Orbiter windowed mode. All other sims I use run great.

Thanks for your help
c

 

[Marijn]

In my opinion, I think it may be the Nvidia driver.

Recently, I did a few fresh Win10 installations. After it finishes, Orbiter runs fine. When I installed the latest Nvidia drivers, I got trouble with the 3d device. So it's most likely a driver issue. Associating Orbiter_ng.exe to any Nvidia functionality seems to fail for me.

 

[creature]

Recently, I did a few fresh Win10 installations. After it finishes, Orbiter runs fine.

Just curious if you now the Nvidia driver version that Orbiter worked with before the update and were you able to run in windowed mode.

thx
c

 

[Linguofreak]

Tried "windowed" mode today

RGB option it loaded but FPS were very low

all other options=reset

I ve had no other issues with this PC or video card on other graphic intensive sims.

Obviously I don't like to keep crashing my computer so I may give it a rest for a while and just continue to use the Full Screen option. If I come up with anything or a solid log file I will post it. In my opinion, I think it may be the Nvidia driver. My current version is 430.86. There is a new one out but from past experience with Nvidia, "don't fix what ain't broken". My only issue is Orbiter windowed mode. All other sims I use run great.

Thanks for your help
c

Well, really, "don't fix what ain't broken" is a fairly universal rule when dealing with graphics drivers: they are complex systems and thus bound to be full of bugs (especially given that most GPU manufacturers keep their drivers proprietary), so if you don't have any current issues, it's best not to change anything. But for the same reason, if you are getting bluescreens or reboots when running 3D programs, the very first thing to do is update your drivers. Or, if you're running OpenGL software on ATI hardware (including pretty much anything that's available for any system other than Windows), just buy an NVidia card. ATI's great with DirectX, glitchy/underperformant with OpenGL on Windows, and useless (at least with the manufacturer's drivers) when you aren't running Windows.