BSOD Since Win10 1809 update, 0x133(1) DPC Watchdog Violation

I extracted the ckcl etl from the memory13.dmp you made available earlier and it shows acpi.sys and ntoskrnl.exe creating DPCs but the function names aren't appearing. I'm hoping it's because meta data which would allow symbols to be resolved is getting paged out and that disabling the paging executive will keep it in memory. I haven't been able to get anyone who was having bugcheck 0x133 issues to try, though, so I don't know for sure.

I am referring to this post:
BSOD Since Win10 1809 update, 0x133(1) DPC Watchdog Violation

MrPepka said:

I am referring to this post:
BSOD Since Win10 1809 update, 0x133(1) DPC Watchdog Violation

It looks like the person who tried this acpi driver has reported in the other thread on bleeping computer forums that it has not solved the issue, and in fact may have made it worse?

Given that this person did not post new memory dumps, it is difficult for me to refer to this. You can create a restore point before installing this driver, then install the driver and check

It doesn't look like the data required for symbol resolution is being collected, unfortunately. It's quite obvious the ACPI.SYS DPCs are often taking way too long to process (19 ms) but the amount of time for each does not seem to be exceeding 2 minutes which is the timeout period for the bugchecks. For these bugcheck it's a cumulative timeout so perhaps there are other DPCs waiting for that long because they aren't getting any CPU processing time but if that's the case they are not showing up in the etl data for some reason. The extracted trace in the latest dump is only 11.5 seconds long, though, so the data for earlier DPCs probably wouldn't show up.

It looks like the system can run for quite a bit of time between crashes. Have you noticed if there's a way you can reliably trigger the problem? I'm trying to figure out if there's a way we can setup a Windows Performance Recorder trace to capture the information we'd need.

It's an odd one. Sometimes, like earlier today, it can bugcheck when just sitting idle.

OP at the Bleeping Computer thread is trying to see if preventing the computer from going through a sleep/wake cycle can be a workaround. She is using only drivers and updates from Windows Update - not even those from the Dynabook/Toshiba support page. Have you tried your system in such a configuration and if so, have you noticed if the crashes only occur after having gone through a sleep/wake cycle? The timespan between crashes for her in that configuration has been 12 hours and 16 hours and only after/during a sleep/wake cycle.

Although I tend to prefer sleeping my machine most of the time, for speed of waking it when I need it (I should really shut it down more often, it's not like it's a slow booter as I have an ssd), once or twice it has bugchecked shortly after booting. In fact the other day it booted into windows and the mouse pointer never appeared. Touchscreen wouldn't work either. Had to sleep and wake it, then the functionality returned.

Just to be sure, Windows by default doesn't actually shutdown when told to do so through the menu and physical power button. Unless some settings are changed it goes into a deep sleep akin to Hibernate. You're already aware of that? Regardless, functionality returning after an intentional sleep/wake certainly wouldn't support my thinking.