Wondering if anyone has seen this general error from Windows while running a jME-based application (or any other really).
Been doing a lot of work with a project the last few days that involves alt+tabbing between the fullscreen jME “game” and Microsoft Excel. About two times or so I noticed that when I was doing this, if I alt+tabbed back and forth very quickly/repeatedly, the jME screen would go black and I’d have to close the game. However today was the first time I got an error from Windows when this happened. In the system tray, a notification popped up that said: “Display driver stopped responding and has recovered”. This happened immediately after alt-tabbing back into the jME game after ~20 minutes of back and forth alt-tabbing without closing the game.
I’m inclined to say this is not a jME-caused issue for a variety of reasons that I won’t detail here; just wanted to see if anyone else has any input.
I don’t have the time to write anything useful but:
a) What Windows Version/Drivers updated?
b) Yes, I had this multiple times
I don’t remember what fixed it but I had it regularly (years before I used jme!).
Could it be that your hardware starts dying? Overheating?
I remember this happening whilst the Windows-Style turns to Aero again and a short complete blackscreen and such
Could be the hardware dying of course.
Haven’t noticed any other symptoms but obviously this could be a “canary in the coalmine” situation.
The OS is 8.1 and graphics are Intel HD integrated. No other problems in general; no overheating, parts failures, etc.
One important detail: I can always alt-tab back out of the black screen. Only the fullscreen game is affected. After I got the notification, I tabbed back into the game and it was still black until I restarted it.
If you’re asking if the drivers are updated, by coincidence, the display driver is up to date – however updates are disabled on this computer and it is disconnected from the internet to prevent software updating without permission. However, I am letting Windows update check for updates now to see if there is anything relevant to this issue, just in case.
I thought better about it and decided to check my temperatures after that last post. CPU overall was 19% utilized but the temp was not detecting with the program I used. Memory was 2/8GB. Basically nothing but background processes running.
Then I saw the temp was, and had been for over 5 minutes, about 89 Celsius (192 Fahrenheit). Even though the max for this processor is 105 C, that seemed ludicrously high for not having anything running.
Opened task manager and saw a random svchost.exe process that was at 11% CPU; forced it to terminate out of curiosity and wallah. As shown in the image below, that was causing a huge temp increase.
So I’m pretty sure if I add the stress of the jMU game plus the other applications I had going (e.g., MATLAB, Eclipse, Excel, etc), that’d be enough to cause a problem. So I was wrong, overheating appears to be the issue, and the cause was that svchost, though I don’t know root culprit. I’ll keep an eye out in case I’m not shutting down something gracefully.
Still kinda high at 54C if that’s idle… I’m at 30C-33C now. I guess it’s the integrated graphics producing the extra heat?
Besides looking into that svchost issue, if you’re not on a craptop (and I’m guessing you are…), get a better cooler? (Or a GPU)
(Make sure if fits, it’s about the size of a small car. )
Am on a laptop, correct. For reference the processor (and thus graphics since they are integrated) is an i7-3632QM. Tested it again with the project open, and it hangs out around 73 C. Idle was near 54 C afterwards. Maybe I’ll put a fan next to it. I’ve opened it up recently (no external access to disk); no obstructions near the fan were obvious.
Was going to see what Core Temp said since I’d used that before but it seems it now comes prepackaged with software to “help me build my kingdom and conquer”, so, think I’ll pass on that.
Update: The high temperatures were likely a symptom of a bigger problem. I checked the minidump generated by the crash and found it was related to TDR. Googling the issue revealed that alt+tab & TDR issues are not uncommon in gaming in general, and from what I saw, when they did get resolved over time a driver issue was the culprit. That led me to check my Windows event logs, where I found that apparently the driver has been crashing regularly without me knowing it, since just after I set up the OS on this SSD. So when the driver reported it was up to date, that was irrelevant. I remembered then why I got that driver; it was a generic because the manufacturer of the computer had inexplicably removed their proprietary version of the display driver from their support site by the time I set up this drive. I had little choice back then but to get something rather than nothing. Anyway, I never realized there was anything wrong because the crashes were occurring during overnight system-scheduled tasks, thus I was never there to witness it.
I went through some backchannels and got what I believe is the correct driver. No overnight crash last night, so, so far so good (we will see over time). Either way, I switched my project to windowed mode for the time being. That has alleviated the alt+tab TDR crashes.
Just wanted to post that here in case someone came looking for a solution someday.
It wasn’t completely clear from the post before:
Did you check the core temperature or the gpu temperature or the cpu proximity?
It’s usual that even with a low cpu load your i7 heats up when jme is running. Without a limited framerate it pushes your GPU to 100% (assuming your CPU has enough power for the game logic). So you might experience a hotter cpu temperature than without using the internal gpu.
svchost is Windows’ Host for Daemon Processes (or rather Services). Next time before kiling right click and use “show assigned services” and then you might see where that load comes from (maybe search indexing?) because if you kill it it might simply get restarted.
Good to hear that it’s only a driver issue, though.
oh and btw: my i7 in my macbook pro can get down to like 35°C CPU Proxmity (which would be like 45°C core), but only running firefox is like 40-45°C, watching youtube is 60°C (70°C Core) and compiling maxes it out to 120°C.
That doesn’t feel good but well, it’s a laptop after all
As you already figured out:
If the system/driver crashes in any way, it is always driver or hardwarefault.
No matter what the applications where doing, it is the job of the os&the drivers, to keep within safe value, or else terminate the offending application. At least for OpenGL there should in theory be no way to crash the driver/os in any way, no matter what kind of illegal calls you make.
In reality both often kinda suck at this (tho it did improve a lot since the win95 times, where a game crash more often then not left hardware in undefined states, leading to a full system crash shortly after)
In my post before, I checked the GPU temperature as reported by Intel XTU. After restarting the computer, it was able to access the other temps that weren’t registering previously, including the 4 separate CPU core temps and package temp (which I assume = “cpu proximity” as you put it, but not sure). Since then I have been watching all 6 values and have not seen any point where there is a drastic difference between the values (though they always vary from one any other just slightly). I do use 60 hz vertical sync; not sure if that limits framerate in the same way you are talking but there’s that.
The svchost thing – yeah, as soon as I realized it was a culprit I realized my mistake. I wasn’t even thinking at the time; although the event viewer showed errors for “host process for X terminated unexpectedly” or something like that, for about half a dozen processes. I’m not sure how any were related to the temps I was seeing when I closed the svchost however; I’d have to research it.
In any case I still have not had any driver crashes since updating the driver. Hopefully that continues. Thanks for all the info.