先說(shuō)配置和系統(tǒng)信息

版本：Windows 10 家庭中文版

版本號(hào)：22H2

操作系統(tǒng)內(nèi)部版本：19045.2546體驗(yàn)

AMD 4800U 16G內(nèi)存 無(wú)獨(dú)立顯卡 也就是聯(lián)想小新pro13 2020款

前提：電腦關(guān)閉了休眠功能，并且開(kāi)機(jī)時(shí)間比較長(zhǎng)，比如15天以上

任務(wù)管理器內(nèi)可看系統(tǒng)開(kāi)機(jī)運(yùn)行時(shí)間，處于睡眠狀態(tài)的時(shí)間也會(huì)被計(jì)入進(jìn)去

15天是一個(gè)大概估算的值，有時(shí)候12、13天就開(kāi)始出現(xiàn)這個(gè)問(wèn)題了

系統(tǒng)剛啟動(dòng)不久的時(shí)候，基本上睡眠多久喚醒都不會(huì)超過(guò)10秒

啟動(dòng)久了之后系統(tǒng)就開(kāi)始抽風(fēng)了

比如電腦進(jìn)入睡眠狀態(tài)后8個(gè)小時(shí)再喚醒，喚醒得50、60秒

但是如果進(jìn)入睡眠時(shí)間比較短的話(huà)，喚醒還是能保持一個(gè)比較迅速的速度

下面是一些從事件查看器里power-trobleshooter記錄的一些睡眠喚醒用時(shí)

查看方法：

????事件查看器 -> windows日志 -> 系統(tǒng) -> 查找名為power-trobleshooter的事件

用 WakeTime - SleepTime 就能得到進(jìn)入睡眠狀態(tài)的時(shí)長(zhǎng)

SleepDuration 是指電腦進(jìn)入睡眠狀態(tài)花了多少時(shí)間 單位是毫秒

WakeDuration 則是電腦喚醒花了多少時(shí)間，單位也是毫秒

下圖是電腦進(jìn)入睡眠時(shí)間很短的時(shí)候被喚醒，用了1.5秒時(shí)間

下面這圖則是系統(tǒng)進(jìn)入睡眠狀態(tài)大概11個(gè)小時(shí)，喚醒花了70多秒

還有這種情況

進(jìn)入睡眠狀態(tài)大約8小時(shí)，但是 DriverInitDuration 這個(gè)喚醒耗時(shí)非常多，花了50秒

喚醒總耗時(shí)則是花了51.9秒

這些圖還有很多，就不一一放出了

也陸陸續(xù)續(xù)在網(wǎng)上找了很多教程和解決方案，但是都沒(méi)有太大的效果

下面列出來(lái)，也許對(duì)進(jìn)入睡眠狀態(tài)無(wú)法喚醒有幫助

• 設(shè)備管理器的一些設(shè)置（無(wú)效）

• AMD GPIO Controller設(shè)置為允許計(jì)算機(jī)關(guān)閉此設(shè)備以節(jié)約電源，挺多教程里面說(shuō)這個(gè)驅(qū)動(dòng)就是導(dǎo)致睡眠無(wú)法喚醒的罪魁禍?zhǔn)?/p>

• AMD Link Controller Emulation禁用

• AMD High Definition Audio Device禁用

• AMD Streaming Audio Device禁用 ，這個(gè)驅(qū)動(dòng)是用來(lái)抑制麥克風(fēng)的背景噪音的，但是小新好像用不了，我就干脆禁用了

• AMD Audio CoProcessor禁用，這個(gè)驅(qū)動(dòng)被我禁用是因?yàn)榭吹揭郧坝行╇娔X因?yàn)檫@驅(qū)動(dòng)導(dǎo)致關(guān)機(jī)特別慢，所以我就試了下，但是沒(méi)效果

• 聯(lián)想的睡眠修復(fù)工具，無(wú)效，但是這好像是用來(lái)修復(fù)進(jìn)入睡眠狀態(tài)無(wú)法喚醒的（真是急病亂投醫(yī)）

• 電源計(jì)劃設(shè)置里面設(shè)置了在此時(shí)間后關(guān)閉硬盤(pán)為 “從不”，也無(wú)效

• 升級(jí)BIOS，無(wú)效，目前是最新版本F0CN39WW，在這個(gè)版本前面的三個(gè)版本都試過(guò)，也無(wú)效

然后就沒(méi)有嘗試更多了

除了上面說(shuō)的進(jìn)入睡眠時(shí)間長(zhǎng)之后喚醒很慢的問(wèn)題外，還有一個(gè)偶爾出現(xiàn)的睡眠無(wú)法喚醒的問(wèn)題

比如今天又經(jīng)歷了一次睡眠后無(wú)法喚醒

鍵盤(pán)燈亮，風(fēng)扇有在轉(zhuǎn)，就是屏幕一直黑的，按一下電源鍵直接秒關(guān)機(jī)

這種情況以前是10多天一次

后面隨著我的瞎折騰，變成了20多天一次

這此距離上次系統(tǒng)重啟大概是30天左右

觀(guān)察了下日志發(fā)現(xiàn)每次睡眠后無(wú)法喚醒都會(huì)有兩個(gè)個(gè)事件

一個(gè)是閏秒配置已更新

另一個(gè)事件是

這倆事件重啟也有，不過(guò)沒(méi)找到什么解決方案

網(wǎng)上說(shuō)關(guān)閉時(shí)間自動(dòng)同步能緩解，但我沒(méi)嘗試

不過(guò)仔細(xì)觀(guān)察了下啟動(dòng)的事件呢

倒也發(fā)現(xiàn)了區(qū)別

就是喚醒之后的第一個(gè)事件?Kernel-General，這個(gè)事件似乎是用來(lái)修正電腦時(shí)間的

如果能喚醒，正常進(jìn)入系統(tǒng)的話(huà)（哪怕花了非常多的時(shí)間來(lái)喚醒）

這個(gè)事件的 EVENT_ID 是 1

內(nèi)容里會(huì)列出一個(gè)更改原因：System time synchronized with the hardware clock

然后系統(tǒng)會(huì)被修正為當(dāng)前時(shí)間

但是如果進(jìn)入不了系統(tǒng)了，也就是前面提到的一直黑屏狀態(tài)

這個(gè)事件的?EVENT_ID?就變成了12

事件內(nèi)容也變成了操作系統(tǒng)在某個(gè)時(shí)間點(diǎn)啟動(dòng)，而且也沒(méi)有說(shuō)修改系統(tǒng)時(shí)間了

注：

上圖中的一些錯(cuò)誤是因?yàn)槲医昧薟IN10更新導(dǎo)致的，一直都有，跟喚醒應(yīng)該是沒(méi)關(guān)系的

原因1：沒(méi)禁用的時(shí)候也有這個(gè)問(wèn)題

原因2：正常喚醒的時(shí)候也會(huì)有這個(gè)報(bào)錯(cuò)

如下面是一個(gè)正常喚醒的記錄

暫時(shí)就先到這，后面有嘗試了新的解決方案再更新