[10ProV1709b16299 x64] Random system restarts - only when gaming, no minidump created

Can you clarify what you mean by "Restarted and within 10 minutes..." ? Did you restart the game after a TDR generated a live kernel dump without restarting the computer or did you restart the computer and then restart the game?

It looks like both network adapter drivers were updated so I think we're good as far as drivers. According to the dump files it looks like the game crashed about 5 minutes before the latest live kernel dump. Were there other live kernel dumps generated in that 4+ hour time period prior to the game crashing?

Game crash: Sun Apr 15 14:25:23.000 2018 (UTC - 7:00)
Live dump: Sun Apr 15 14:30:56.530 2018 (UTC - 7:00)

Do you recall if you've Alt+Tab'd in and out of the games before having a problem?
​
 
cwsink said:
Can you clarify what you mean by "Restarted and within 10 minutes..." ? Did you restart the game after a TDR generated a live kernel dump without restarting the computer or did you restart the computer and then restart the game?

It looks like both network adapter drivers were updated so I think we're good as far as drivers. According to the dump files it looks like the game crashed about 5 minutes before the latest live kernel dump. Were there other live kernel dumps generated in that 4+ hour time period prior to the game crashing?

Game crash: Sun Apr 15 14:25:23.000 2018 (UTC - 7:00)
Live dump: Sun Apr 15 14:30:56.530 2018 (UTC - 7:00)

Do you recall if you've Alt+Tab'd in and out of the games before having a problem?
​
Click to expand...

Sorry. I meant I restarted the game after the game had crashed and within 10 minutes the entire system froze as usual. The dump files are correct about that crash happening about 5 minutes before the system locked up, I wasn't timing it but knew it was less than 10 minutes.

In the 4+ hour time period the game played as it should and without any issues until it crashed. I can't say for certain I Alt+Tabbed in that time because I have an older laptop that I've been using to look up information. I might have but there's no certainty. I do know that in the past I've done it but not since the laptop was returned to me last week and I began trying to to troubleshoot it again. I've also run in both fullscreen and windowed modes for the game with the system freeze issue occurring.

I almost forgot. I've been using a piece of software that monitors temps in case it was heat related (it isn't) and noticed that the reported voltage was 12.96V but yesterday it was reporting 13.06V. It could be a case of inaccurate reporting but felt it worth mentioning.
 
Do you still have Driver Verifier enabled? I can't tell in the minidumps and live dumps; there doesn't appear to be any information about it in those for some reason but the Automatic and Kernel dump show that is it is enabled with Special Pool selected. If you do have it enabled, I'd recommend running it again, deleting the existing settings, and then rebooting. Special Pool will cause the computer to run out of memory eventually and the error I'm seeing in the game crash dump file could suggest memory availability problems.
 
I made the changes you said and to my surprise and dismay neither the game or system have crashed. I would love to believe it's fixed but I've fallen for that before. For now though I can't add anything new beyond this although the retailer is supposedly contacting the manufacturer to see if there's an updated graphics card VBIOS. I'll post more when / if something happens but for now I will just say, again, thank you for spending so much time trying to help me find a cause for this issue.
 
I'm happy to help when I can and hopefully the driver updates fixed the original issue. Driver Verifier is often a great help but shouldn't be run all the time. At best it will slow the system down unnecessarily and can even have bug inducing side-effects for an otherwise properly working computer.

Please do let us know whether or not the problems continue after you've had time to test it out thoroughly.
 
cwsink said:
I'm happy to help when I can and hopefully the driver updates fixed the original issue. Driver Verifier is often a great help but shouldn't be run all the time. At best it will slow the system down unnecessarily and can even have bug inducing side-effects for an otherwise properly working computer.

Please do let us know whether or not the problems continue after you've had time to test it out thoroughly.
Click to expand...

It performed fine for almost a day. I switched in my SSD and installed my m.2 drive and still it went about a day without issue but the system has finally crashed again. It still mentions the nVidia driver, no word from them yet, and no word from the retailer on that VBIOS. I'm saddened that it has crashed again even if I knew it would eventually but this is what makes it so hard to troubleshoot. Some days it would happen so often I'd barely get to a title screen before it restarted and others it is fine. As this is an old install I had prior to sending the laptop off for repairs I just slotted the drive in again. If you require a new msinfo32 or other information please let me know but I think my safest bet is doing everything I can to get them to take this back and replace it.
 

Attachments

It might be wiser to add things one at a time to the system with the Seagate driver as the boot drive. The dump from the new configuration has introduced some new drivers and also seems to have some older or different versions of drivers compared to last dump from the Seagate. It makes it more difficult to keep track of variables, otherwise.

But if you want to try with the new configuration:
Code: 
4: kd> lmDvmTeeDriverW8x64
Code: 
[COLOR=#222222][FONT=Verdana]Browse full module list[/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]start             end                 module name[/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]fffff809`73620000 fffff809`73653000   TeeDriverW8x64   (deferred)             [/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]    Image path: TeeDriverW8x64.sys[/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]    Image name: [URL="http://www.carrona.org/drivers/driver.php?id=TeeDriverW8x64.sys"]TeeDriverW8x64.sys[/URL][/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]    Browse all global symbols  functions  data[/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]    Timestamp:        Thu Sep 15 10:08:03 2016 (57DAD573)[/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]    CheckSum:         00033253[/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]    ImageSize:        00033000[/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4[/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]4: kd> lmDvmRtsPer[/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]Browse full module list[/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]start             end                 module name[/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]fffff809`73660000 fffff809`73724000   RtsPer     (deferred)             [/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]    Image path: RtsPer.sys[/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]    Image name: [URL="http://www.carrona.org/drivers/driver.php?id=RtsPer.sys"]RtsPer.sys[/URL][/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]    Browse all global symbols  functions  data[/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]    Timestamp:        Thu Aug  4 02:11:14 2016 (57A306B2)[/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]    CheckSum:         000BFE1A[/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]    ImageSize:        000C4000[/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4[/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]4: kd> lmDvmXtuAcpiDriver[/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]Browse full module list[/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]start             end                 module name[/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]fffff809`753d0000 fffff809`753e0000   XtuAcpiDriver   (deferred)             [/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]    Image path: XtuAcpiDriver.sys[/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]    Image name: [/FONT][/COLOR]
Code: 
[COLOR=#ff0000][LEFT][FONT=Verdana]XtuAcpiDriver.sys[/FONT][/LEFT]
[/COLOR][LEFT]
[COLOR=#222222][FONT=Verdana]    Browse all global symbols  functions  data[/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]    Timestamp:        Thu Feb 26 04:51:57 2015 (54EF16ED)[/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]    CheckSum:         00018DFC[/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]    ImageSize:        00010000[/FONT][/COLOR]
[COLOR=#222222][FONT=Verdana]    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4[/FONT][/COLOR]
[/LEFT]


The page for the driver names with links should allow you to find the updated versions of those driver. The red driver is for a utility that can be used for overclocking if this page is correct. I'd recommend uninstalling it and not installing any such utility; at least while troubleshooting the system. There is also this driver:
Code: 
4: kd> lmDvmScpVBus
Browse full module list
start             end                 module name
fffff809`75470000 fffff809`7547e000   ScpVBus    (deferred)             
    Image path: ScpVBus.sys
    Image name:[/FONT][/COLOR][FONT=Verdana] [COLOR=#008000]ScpVBus.sys[/COLOR][/FONT]
[/LEFT]
[COLOR=#008000][/COLOR][LEFT][COLOR=#222222][FONT=Verdana]
    Browse all global symbols  functions  data
    Timestamp:        Sun May  5 14:31:26 2013 (5186CFAE)
    CheckSum:         00010BD7
    ImageSize:        0000E000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
[/FONT][/COLOR][/LEFT]

Which might be perfectly harmless but I see it show up in a lot of Windows 10 dump files for people who are having hard to debug crashes. It's a driver used to allow the use of a Sony game controller and the timestamp for it always makes me nervous. It's no longer being supported, either. I'd leave it for now but please be mindful of whether or not the problem appears only after doing anything with the controller (using, connecting/disconnecting, etc.)

It also looks like you're using a different version of the Nvidia driver.
​
​
 
I forgot to switch this install to the older driver but I will get on that. I've updated the ones you mentioned and deleted the strange ones. I don't know where that Intel Xtreme tuning file came from as I've never installed the program!

Further to this I somehow missed that a win32kbase dump had been created a few days ago. It's 256MB zipped, 1GB unzipped so I'll link that. Prior to switching drives back I was very careful not to use the PS4 controller or anything external to avoid conflicts and while the system hadn't crashed until I switched back (a day of full use with no issue) it also went a full day with no issue with mouse, headset and both drives installed.

Two further Watchdog files attached

win32kbase
 

Attachments

When you wrote that you tested each DIMM individually was that using the system as you normally would but with only 1 DIMM installed at a time? I've participated in and read many posts involving DDR4 memory where memtest86 and Windows Memory Diagnostic passed with zero errors only to find out later a DIMM was actually bad. I've not actually found any diagnostic software to be reliable at detecting faulty DDR4 memory. The most reliable method seems to be using the system as you normally would but with only 1 DIMM installed at a time to see if it is stable with one or the other DIMM. Has that already been tried?

I ask because the dumps that are actual crash dumps seem to involve memory problems of one sort or another.
 
I tried DIMM 1 in slot 1, booted and tested until I got a crash while gaming. Switched DIMM 1 to slot 2, booted to Windows and went again until I got a crash while gaming. I then did the same with the second DIMM on its own. Sometimes it took a little longer but the result was always the same.
 
Very little documentation seems to exist about debugging 0x141 live kernel dumps. Timeout Detect and Recovery (TDR) can have many different possible causes and the fact that your GPU seems to be able to recover could suggest it's something other than the GPU. That FurMark doesn't trigger a problem also suggests to me it's not a GPU issue. Honestly, I'm not sure the 0x141 error is even related to the more severe problem of the system restarting without generating a dump file. I have a single instance of the 0x141 live kernel dump in my event log from 11 days ago and I never have system crashes.

Perhaps we should try to get a full process dump when the games crash. To do so I'd recommend setting up procdump:
  1. Create a folder called dumps on a drive with plenty of space for a full crash dump.
  2. Download and unzip the procdump contents to the dumps folder you created in step 1.
  3. Launch a cmd prompt with Administrator privileges and navigate to the dumps folder.
  4. From the cmd prompt run the command: procdump -ma -i

That should set procdump as the default debugger and generate a dump file in the dumps folder whenever a process crashes. Please try running a game and see if you can capture any dump files. When we're finished with procdump you can set the debugger back to default values by running the following command from an elevated command prompt in the dumps: procdump -u
 
No luck I'm afraid. As with the normal debugger it fails to capture anything when the system locks up. So far all it's caught is my bad coding in Python with infinite loops. I gave the retailer a week after they mentioned the VBIOS but I fail to see how it takes more than a day to get a reply from someone you do business with. They did mention that the manufacturer is in the US (retailer and myself are UK) as if that somehow makes a difference to me. The only reason to mention this is that I am hoping they will stop stonewalling me and just replace the laptop. It feels more likely than getting a solid answer here due to the lack of dumps I'm getting despite all your efforts to help me.

I will update if anything of note happens.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top