Elsewhere in the forums, it has been mentioned that this error is related to how Scrivener accesses video drivers.
For me, this error is directly related to the monitors being powered off.
I often remotely access my main computer from within my house, and without… Mostly the monitors are off.
When attempting to start Scrivener with the monitors off, the error 87 is displayed… And since I am sometimes very far away from my house, the monitors cannot be powered on. Hence, Scrivener is not usable.
No other program exhibits such behavior… I use WP, Word, XL, Firefox, Outlook, Cakewalk, VoiceMeter, Video editors, and file conversion utilities, and so on…
I think Scrivener’s relationship with video-drivers needs to be changed.
I’ve had Windows itself mess up when a monitor was turned off, including pop-up windows (part of Windows… not a third party) that were blank until the monitor was turned on again.
From what I’ve seen online, you should consider updating your video drivers. Some have what seems to be a related issue with AMD video cards. In one case, a person had what seems to be a related issue with AutoCAD and AMD Radeon graphics drivers and application software.
Scrivener doesn’t have a direct relationship with the video drivers, as far as I know – it’s simply using Qt libraries (which in turn are using system-provided API calls) to interface with the display system.
Whenever having video issues, the first step is to ensure you have all your driver updates (and all your Windows updates, because driver internals often change in response to specific Windows updates.)
One of the curses of Windows. With so many potential hardware combinations and so many development platforms, a missed update or install glitch in any area can have consequences of this nature.
I’d say get a Mac, but even I run both platforms (and regularly curse Windows).
As others have said, check all updates are applied.
That said, even on Mac on very rare occasions, I have had issues where I’ve had an app open in the background and disconnected from my external monitor then brought the app to the foreground. No message like this, but a window that opened on the monitor doesn’t want to display on the laptop. Even rarer, sometimes it just won’t clear the issue even with an app restart, and a complete system restart is needed.
It COULD be a clue, but knowing that others have this issue with other apps and even other platforms without the added factor of remote access suggests it might also not be a clue.
I gather you are only having this issue when remote? That might suggest there is nothing wrong with Scrivener’s interaction with the OS/hardware itself. The issue is introduced by the remote access software? Perhaps there is an issue with QT’s support for whatever is involved with your remote access software.
I’ve had a Very similar issue on TWO Windows machines. One failed to render a Windows 10 Settings window (maybe power settings). Also, a laptop of mine was set to stay awake even with the screen closed because I knew that my friend was going to remote in and use TurboTax 2020. It refused to render one pop-up (EVEN THOUGH the laptop remained awake) until I opened the laptop (restoring actual power to the screen).
I’m sure that this is NOT a Scrivener issue. It seems fairly clear to be a driver issue (or remote software issue). Have you tried updating the video card drivers? I’d like to hear back.
SIDENOTE RE REMOTE SOFTWARE:
I’m a tech guy (doing a lot of tech support) though am not a pro at virtual terminals. So I doubt all this is precise, but may help understand the space we’re talking about. Remote software uses virtual terminals to render the images handed to you and works tightly with video card drivers. The issues those developers deal with are complex. Multiple physical monitors with the capability to mirror those renderings within your virtual screen(s), knowing the reported orientation and spatial relationship of physical monitors, generating virtual screen(s) if there is no monitor, and much more. When the physical monitor is turned off, the driver AND the remote software must be smart enough to realize (for each window and pop-up) that, even though the rendering on the physical screen is no longer needed, it IS needed on the virtual terminal (and usually must mimic the physical screen, which could be turned on at any point). Maybe that kind of logic is what’s failing in your case. I suspect so.