Windows 10: Tablet has bluescreens during night/standby

After 3 times boot failure you should get the troubleshooting options, go into the advanced troubleshooting options and in there choose command prompt, then enter the command
Code: verifier /reset[/quote]

 

Ok Im back in Windows, repair took a bit longer than expected, working again, seems it used the last repair point. Now what? And no, the automatic repair didn't give me any advanced options, just reboot and "repair last".

 

Please run the DM Log Collector again, with the BSODs dumps should have been created which we need to analyze to find out what driver caused it.

 

No problem, I'm just glad you're back in Windows already *Smile

 

Please update/reinstall Unified Remote 3.
Code: 1: kd> lmvm uvhid Browse full module list start end module name 8e2b0000 8e2b9000 uvhid T (no symbols) Loaded symbol image file: uvhid.sys Image path: \SystemRoot\System32\drivers\uvhid.sys Image name: uvhid.sys Browse all global symbols functions data Timestamp: Tue Mar 22 10:42:48 2016 (56F11398) CheckSum: 0001557A ImageSize: 00009000 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4[/quote]

 

Should I do another system repair point after that and re-run the tool again? I don't think that the standby bluescreens are related to that. Also, how to make sure the driver is removed too?

 

Also why Tue Mar 22 10:42:48 2016? When I do a Windbg from the last dmp file it says: Probably caused by : Wdf01000.sys.

 

First see if you can update/reinstall the software and after that try to get another BSOD.
If you get another BSOD then run the tool again.

Removing the driver causes the related software/devices to function improper and thus causing more problems, that isn't what we want.


Wdf01000.sys is a Windows driver, Windows drivers are pretty much never the root cause.

The Unified Remote HID Mini Driver for Unified Virtual HID is the one that is flagged here, running the lmvm command we see the timestamp of the driver (and some other stuff)
Code: ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck C9, {22e, 85c024b0, 8d79b828, 0} *** WARNING: Unable to verify timestamp for uvhid.sys *** ERROR: Module load completed but symbols could not be loaded for uvhid.sys Probably caused by : Wdf01000.sys ( Wdf01000!FxDevice:ispatchWithLock+0 ) Followup: MachineOwner 1: kd> lmvm uvhid Browse full module list start end module name 8e2b0000 8e2b9000 uvhid T (no symbols) Loaded symbol image file: uvhid.sys Image path: \SystemRoot\System32\drivers\uvhid.sys Image name: uvhid.sys Browse all global symbols functions data Timestamp: Tue Mar 22 10:42:48 2016 (56F11398) CheckSum: 0001557A ImageSize: 00009000 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4[/quote]

 

But Tue Mar 22 10:42:48 wasn't the 3rd BSOD (the 3rd file)... The 3rd file is from 16:26 from today... when I ran the tool from an hour ago, now it's 17:24 here.

Attachment 81242

No you got me wrong... installing software sometimes don't remove drivers coming with it. My question was, if I remove the software, how do I know the driver is removed too properly / unloaded.

Also what do you mean with when I get another BSOD, then the tool wouldn't be running and I got it for no debug reasons, or am I mistaken?

I ran the tool again and no bsod this time, shouldnt I let it run for 48h now?

 

Tue Mar 22 10:42:48 is the time of the driver, not the time of the dump.

It isn't that because a driver is causing a crash that you need to remove it, in 99% of the time you need to update it or reinstall the related stuff.
When you remove the software you need to go in Windows Explorer and enter this in the address balk
Code: %systemroot%\System32\drivers\[/quote] That leads you to the right folder, search for the file uvhid.sys which caused the crash and then you can safely delete it.

After a suggestion is tried we need to know if it worked, you need to try to get another BSOD through the way you usually get a BSOD.
If you get another BSOD then run the DM Log Collector again.

Please try to read my posts properly, to me it looks like you interpret some parts improper and confuse it with something else unfortunately leading to something I don't mean/say.

 

No, believe me, I read your posts properly, you didn't get what I mean. Also in 99% of the time, there is no update for drivers. Anyway... updating Unified is no option, because it is already the newest version, so uninstalling was the only option, and nothing what I say is without a reason. And like I said several times, there is no way to trigger this bsod, it happens randomly during connected standby, and I doubt that this was the cause of the connected standby issues. My question was, if I should let the verifier run again, this time for 48h... not the log collection.

 

Most drivers causing crashes are outdated *Wink
In your situation it isn't the case, but that is why I suggested to update or reinstall

I'm not asking to trigger it, I'm actually asking you to just wait and see if another one occurs. I didn't write it proper, but as you cannot force one it is just waiting for another one. That is what I meant with 'try to get another BSOD' *Smile

I would suggest to wait and see if another one occurs, if you want to run driver verifier per the instructions be my guest though I would recommend to NOT enable driver verifier again until another BSOD has occured where the generated dump does not flag a driver.

 

Of course they are outdated... the problem is with tablets they are manufactured once and afterwards there are no driver updates anymore for things like the camera, the touch device, wifi card, and so on. Chipset is mostly by Intel, problem is Intel doesn't care much about the BayTrail drivers, last updated drivers are from 2013/2014, same goes for the Intel HD drivers for BayTrail. Wifi card the same, Qualcomm drivers are from 2014, no updates anymore since then, and so on and so on...

Why then not let the verifier run for another 48h? I thought it would force/trigger all drivers to get a bsod, or higher the chances to triggr one, no? So why not use it again? I don't get it. Why should I wait for a normal BSOD to happen AND THEn use it to try to trigegr it again? That doesn't make any sense to me.

I will come back to this thread if I get another BSOD in the next days. Thank you very much for your help. I have to say, you are the first person who surprised me with knowledge in this forum. 90% of the people in this forum have no clue what they are talking about and get sissy/report you if you tell them about it.

 

That was more general spoken, with tablets that is indeed a big problem.

Yes it does, though it depends on the settings for the result that you want where the wanted result is dependent on the type of crashes or other problems, like for example with memory leakage you need to enable other settings then the tutorial describes.
It is normal that when a driver has been flagged by driver verifier the user needs to test the system to see if the problem is resolved under normal circumstances.
Then there is also the lagging problem that can occur what stresses a user and so they take steps that they later regret, but they don't learn from what they've done and take reckless steps again under similar circumstances. I want to prevent that with everyone I help *Smile I have no idea how technical you are so I'm just extra cautious trying to prevent as much problems as possible with suggestions that may turn out the wrong way.

You're welcome *Smile
There are many users on this forum that are specialists/experts in quite some things, it can be a bit difficult to find them though with all the activity going on every second.