After long testing, what it seems to work is to install 'EVGA Precision' and raise the fan speed to 50%. No more issues. This is absolutely strange, because my rig is new, I checked and no dust that could suppose overheat is present. By default, the fan speed is around 22%.
And, of course, this only happens while playing STO. I have no problem with Skyrim and other demanding games, that I usually play with ultra high quality graphics on.
Thank god I found this thread..cause I have been going crazy for the past 3-4 weeks.
Since then is when my issues with STO began.
Say out of the 10 times I try to start the game 8 times it will lock up with in 60 secs of booting up the game.
Sometimes it completely freezes the PC when it forces me to to a hard shut down but sometimes I can manage to alt+Tab back to the desktop (laggy as hell though) and ill get a error msg pop up which says:
Fatal Error: Direct3D driver returned error code
(DXGI_ERROR_DEVICE_Removed) while checking sync query.
Technical Details: Sync query 5 0x13eb0cc0 GetData == 0x887a0005 0 NF
D3D11 Device removed due to DXGI_ERROR_DEVICE_HUNG 0x887a0006
any updates on what has been happening to others receiveing this same msg?
Unexpected, non-recoverable D3D errors can (rarely) occur for several reasons:
The GPU hardware could hang due to a driver bug, hardware fault, overheating, etc. It must then be reset (basically rebooting the GPU) before rendering can continue. This is referred to as a TDR, which stands for Timeout Detection and Recovery.
The GPU could have been physically removed from the computer (which happens when undocking certain laptop models) or its driver could have been updated on the fly.
The driver could have a bug that got it into a messed up state.
The driver or D3D runtime could run out of memory in a place that isn't recoverable. Some allocation failures (for instance not having enough room to create a new texture) are easy to report back to the caller, but others (for instance failing to allocate an internal renamed resource while flushing a command buffer) could leave things in an ambiguous partial state where some amount of rendering might already have taken place yet other work cannot be completed. There is no good way to describe such a situation to the caller, and not really anything they could do to continue past the problem.
A boneheaded error could have gone unnoticed (especially if the debug D3D layer was not in use) so the D3D runtime passed invalid parameters through to the driver. What happens next is entirely up to the driver (this is undefined behavior!) but one likely outcome is for the driver to become horribly confused, fling its hands in the air, and shout huh? you want me to do whaaaat???
In all these cases things have gone badly wrong, and not in a clean way where D3D could report back that any single method call was rejected. We know the D3D device has ended up in a different state to what the program intended, but cannot describe exactly how things are different or what needs to happen to get everything back in sync. At this point D3D switches into a special "device removed" state. You can still call D3D methods, but they will be ignored and nothing will actually be rendered. When you eventually come to call Present, it will return one of the error codes:
The only way to recover from device removed state is to destroy the broken D3D device, destroy all its associated resources, create a new device, and reload a whole new set of fresh resources. Some apps go to great pains to robustly handle this situation, but many (most?) games don't bother, and will just crash in response, or stop rendering and need to be killed by the user.
Note that D3D11 device removed state is different from the old D3D9 device lost behavior, which occurred any time the monitor switched between windowed and fullscreen mode (e.g. when pressing alt+tab). This was a common occurrence, so all D3D9 apps had to handle device lost. In D3D11, display mode switches are handled by the runtime without any special effort from the app. Device removed is reserved for situations where the state of the device is not well defined and thus no automatic recovery is possible, which is much rarer.
If you frequently run into device removed errors, the first step is to check the debug D3D layer to make sure these are not just knock-on consequences of an earlier boneheaded error.
The other thing I noticed while doing research was that two years ago Champions had this exact same problem using "underwater" aliasing. If I'm not mistaken, that exactly the fix they applied to the feature episode in order to make it work correctly. That would explain why my crashing started when the FE came out.
I'm getting the same error. It's pretty frustrating. This first happened to me the first time I entered the Dyson sphere while I was flying around trying to complete the story objectives. Then I entered the battleground and things got worse from there.
Was running around the city with a buddy last night and my game crashed at least 5 times. I decided to make a new Romulan toon, game crashed in character creation twice. I finally finished creating my toon and crashed in the city trying to get to the weapons locker; the very first mission.
I have no idea what to do. I've been playing for about 3-4 weeks, it was fine until 2 or 3 days ago.
Hey guys, just an update for those still experiencing crashes. Dunno if this will work for you but it did for me, at least for now.
I decided to uninstall and re-install the game in an entirely different directory and partition of my HDD. I haven't had any crashing issues so far since. I also decided not to change of the graphics settings. It's not the prettiest sight since I know my card could handle much more but I'd rather avoid the crashes.
Hope this helps. Lemme know how it goes for you guys.