Not to get a dick measuring contest, but yes, i have written interrupt handlers. I have written them in several OSes going back to the late 80s even. I did not mention Ryzen because 6700k was written clearly in the first post.

I always manually change the config file for each installation, because i am too lazy to setup a shared one.

The short answer is that either Windows itself, or more likely one of the drivers you have installed (most likely culprit is the video driver) has bugs in it that permit userland applications to do things they shouldn't be able to do which ultimately leads to the OS crashing as a result. The solution would be to make sure the OS is fully up to date, and make sure all of the drivers are fully up to date. If both are already true, then switching to an older video driver release might work around the issue as the video driver is always the #1 culprit when it comes to such instabilities. Another possibility could be bad RAM (testable with memtest86+ for 24-48 hours), a bad PSU or other bad hardware.

But, it is not a bug or problem in DOSbox, nor in GOGs games. This is non-intuitive, but let me say it again... All problems of this nature are NOT problems in the games or other software that trigger the problem to happen. Why is that?

That requires a bit of a longer explanation so I wanted to start with the nice short detail-less one above first. :)

In short, it is the job of the operating system to take complete control over all of the hardware in the computer and to arbitrate access to that hardware through standard operating system interfaces. Video games and other software generally have zero access permissions to talk directly to the hardware without going through the operating system. As such, video games and other software have zero ability to tell the hardware to do something wrong, nor to do things such as blindly reboot the computer either on purpose or due to a bug in the video game. They do not have this access because the operating system runs in protected mode ensuring that it is in full control of the hardware and the software running under it does not have hardware level permission to do those things.

Video games talk to the hardware through operating system level APIs or APIs built on top of that such as DirectX, etc. As such, games and other software can only do to the computer what those APIs allow them to do. These APIs do not have any intentional functionality such as "reboot the computer on purpose" exposed to the programmer to call on purpose or by mistake, so it is simply not possible for a game to do this on a properly working system.

The only way it is possible for a game or other piece of software to reboot the computer or crash the operating system in protected mode, is if the game issues commands through one of the OS APIs that either accidentally or purposefully triggers a bug in the OS or a driver that does have low level access to the hardware, and that hardware is capable of locking up or rebooting the computer. Of course no game or software developer would purposefully put code in their game to intentionally try to trigger a bug in a driver or OS to reboot or crash the computer, so any behaviour like this that one experiences is almost certainly a bug in the operating system or video driver or some other component of the system which is running at elevated privileges in protected mode ring 0.

The video driver on a computer is one of the most complex pieces of software running on the system. Not only is it complex but it is rather large overall with todays drivers, and due to this complexity it is also the most likely to contain bugs. Bugs in video drivers can easily cause bad DMA operations to corrupt kernel memory or cause other problems leading to a triple-fault reboot or similar. It is so common that when people experience this sort of problem on their system, it is the best place to start looking for the cause. Having said that, the same problem could happen in any driver such as an audio driver, network driver, or any other driver or part of the operating system that runs in protected mode ring 0.

Video games, DOSbox, Microsoft Office and other programs run in protected mode ring 3 - unprivileged code that has no ability to reboot the computer or crash the system, so when one runs those kind of programs and experiences a system-wide crash or reboot, it is time to start looking for driver updates and OS updates, testing the memory of the system and the power supply and other hardware to ensure it is all working correctly. The symptoms may appear that "game or program XYZ just rebooted my computer" but in reality it is "game or program XYZ just inadvertently triggered a bug in the video driver or underlying operating system that caused the computer to reboot" or "my system has corrupted RAM or other hardware problems causing memory to be unreliable which ultimately leads to things like reboots".

Back in the days of MSDOS game bugs could directly crash or reboot the computer because MSDOS was not a protected mode operating system, however those days are long gone. Nowadays, such problems are 100% hardware problems or operating system/driver problems.

Hope this helps shed some light on these kind of issues.

Good writeup. I wish more people would read this (and actually take the time to read up on some of these terms, like protected mode).

Reminds me of an episode not too long ago, on GOG's twitch channel, where Riddick would randomly reboot kilg0re's computer. People blamed the game; I told them it can't be the game, it's either the hardware or an OS/driver bug. People kept insisting, because "it's an old game and runs in quirks mode" or other bs like that. Even self-proclaimed software developers would tell me that no, it really might be the game, because games are complicated, and they know... *sigh* I have a hunch these devs were web developers who never touched a kernel. Or maybe they haven't touched PCs since DOS.

In the end. Mr. Trout replaced some hardware and the problem vanished.

In fairness to the average gamer/person out there, this kind of thing is rather complicated and difficult to understand without a more extensive background in computer systems engineering and software development. What the user sees from their perspective is "When I run X, Y happens, therefore X causes Y to happen and X is at fault." rather than the actual much more complex reality which is "When you run X, Y happens, which is caused by a bug in Z being triggered by X, however you don't see Z so it isn't apparent." :)

Sure. That is why I hope people read your post, because it's a well written summary :)

But yeah, I don't expect most people -- including gamers -- to know much about it. Which is fine. I guess I just get frustrated when people won't listen at all, and then gang up & go into credentialism ("look I'm a software developer!") instead of, maybe, looking up some of the terms I hand out. In the end they too should want to know what's the most likely cause of their problem, so that they can fix or work around it.

I'm probably very bad at expressing myself though, and that doesn't help.

Thanks for an excellent explanation!

I used to maintain video drivers in Linux as well as the screensavers and other stuff. I'd often get bug reports that the screensavers rebooted the computer or crashed it. I'd ask them to attach the relevant system logs where video driver information/errors showed up and ask them about their video hardware, so the bug could get reassigned to the video driver or kernel where it belonged. Sometimes people would go apeshit over it, demanding the screensavers just be fixed to not crash the system. Very frustrating to deal with that sort of thing, especially when the person just made demands and would not use troubleshooting suggestions and attach information that could actually be used to track down the actual problem in the video driver or kernel. :) For all I know they still get those crashes hehe.


No prob! :)

Today I got a bit wiser :-)

Does the cutting to black happen in windowed mode or just fullscreen?

It happens on both. I recently tested with M&M 4-5 with fullscreen ticked on and off. The monitor readjusting thing still happens before the game starts. The good news is that disabling DSR seems to have rectified the problem of the reboot and I haven't had any issues since.

tomb raider 1 (dosbox) damages the windows 7 taskbar until you restart. no other game does this regardless of dosbox. maybe dosbox gog version, is faulty

Just as an advisory: although DOSBox hasn't seen a new release in five years, there is a newish SVN build called "ECE" that does feed in the latest changes to the source code as well as the OpenGL high-level Glide implementation and a "surfacepp" pixel-perfect mode.

http://www.emucr.com/search/label/DOSBox

That's possible. The GOG version of Tomb Raider uses a special version of DOSBox that enables Glide emulation but can cause problems with switching between fullscreen and windowed mode as a result.