win10自帶殺毒軟件 Windows Defender

Windows Defender微軟自帶的一款系統(tǒng)防護軟件，在幾乎所有領(lǐng)域的安全性測試中，都已經(jīng)超越了第三方軟件，還有高級威脅防護(ATP)，再結(jié)合Windows 10系統(tǒng)自身的安全保護，它近乎可以100%抵御來自惡意軟件的攻擊，安全性能高，并且體積小巧，沒有任何捆綁。結(jié)果證明Windows Defender已經(jīng)很優(yōu)秀了。

缺點

Windows Defender殺毒軟件很耗系統(tǒng)資源。從Windows啟動一直到關(guān)機，始終占領(lǐng)系統(tǒng)內(nèi)存，讀寫硬盤、U盤、移動硬盤時，會造成突發(fā)性卡頓。

Windows Defender殺毒軟件功能單一。Windows defender主要是殺毒防御，沒有系統(tǒng)維護方面的功能，比如清理垃圾、系統(tǒng)優(yōu)化、優(yōu)化加速、電腦體驗等，功能單一。

火絨安全

火絨是一款殺防一體的安全軟件。自主研發(fā)高性能病毒通殺引擎，采用“內(nèi)核純凈化”技術(shù)處理內(nèi)核級Rootkit；單步加多步的主動防御技術(shù)；具有過濾網(wǎng)頁廣告和軟件廣告的功能；軟件小巧，占用資源小。

實時監(jiān)控

可以監(jiān)控系統(tǒng)中所有進程的文件、注冊表、進程以及網(wǎng)絡(luò)動作；

進程管理

啟動項管理

掃描系統(tǒng)中的啟動項，并對掃描到的啟動項進行禁用、啟動和永久刪除；

病毒查殺

防護中心

訪問控制

安全工具

彈窗攔截

總結(jié)：

Windows Defender軟件的功能只能局限在殺毒，對于國內(nèi)的Windows軟件系統(tǒng)環(huán)境的支持還是欠佳。但相對一些對電腦操作意識較好的朋友，那么我就認為不需要再安裝殺毒軟件了，因為win10自帶的Windows Defender，也就是win10自帶殺毒軟件，可以算是比較完備的殺毒軟件了，所以不必去下載其他的殺毒了！

對于電腦不太熟悉的小伙伴，電腦防護意識較差，需要一個強大的電腦保護軟件，火絨安全，一個免費的國產(chǎn)殺毒軟件能做到0彈窗0捆綁，真是國產(chǎn)殺軟的一股清流。它可以算是國內(nèi)領(lǐng)先的殺毒軟件，如果想用，是可以的，畢竟方便用戶更好的操作電腦。

即使現(xiàn)在的系統(tǒng)相比 20 年前已經(jīng)穩(wěn)定了很多了，使用電腦時也難免會遇到藍屏、意外重啟、甚至是意外關(guān)機的情況。盡管這種問題可能只是偶然發(fā)生，可以說是不太走運；但更多的時候放著不管，反而會讓電腦的問題出現(xiàn)得越來越頻繁。

所以，這篇文章就旨在幫助大家快速找到讓電腦不能正常工作的罪魁禍首，雖然不一定能「藥到病除」，但也能讓你離正確答案更近一步。

macOS

盡管 macOS 是Apple為Mac產(chǎn)品線定制的操作系統(tǒng)，但實際上出現(xiàn)問題的機會還是很多的。雖然在macOS中我們可以通過控制臺獲取日志信息，但從macOS Sierra及更高版本開始，考慮到安全和隱私問題，控制臺只允許訪問最近的日志條目，而不是整個日志文件。

所以想要分析日志中所有和關(guān)機有關(guān)的事件，就需要通過「終端」和相應(yīng)的指令進行分析。如果你的 Mac 近期出現(xiàn)了意外重啟等問題，不妨跟著下面的步驟試一試，打開「終端」，并輸入如下指令：

log show --predicate 'eventMessage contains "Previous shutdown cause"' --last 24h

上面這一串指令會使用 log show 檢索系統(tǒng)日志，predicate 可以進一步篩選日志，在本文中我們篩選的日志類型是 eventMessage中包含Previous shutdown cause（此前關(guān)機的原因）的信息，而篩選的時間范圍--last 24h則是過去 24 小時，如果有必要的話可以擴展到 36 小時甚至更長。

靜靜等待一段，你就能看到如上圖一樣的、將日志篩選后到結(jié)果，我們需要注意的信息就是Previous shutdown cause后續(xù)跟隨的數(shù)字，這個數(shù)字代表著 Mac 電腦上次是因為什么原因而關(guān)閉的。總的來說，負數(shù)的代碼通常是因硬件而關(guān)機的，該信息由系統(tǒng)管理控制器 (SMC)2或處理器本身3報告；而正數(shù)因軟件而關(guān)機的。以下是每個代碼所包含的含義：

如果你的 Mac 出現(xiàn)大量因為 0（斷電）導(dǎo)致的意外關(guān)閉，那么就需要進行一定的排查。對于沒有電池的臺式 Mac 而言，主要檢查的就是電源線有沒有牢牢插入到電源接口中；如果依然出現(xiàn)這樣的問題則很有可能是計算機內(nèi)的電源出現(xiàn)了問題，需要進行維修。對于有電池的筆記本型 Mac 而言，需要同時檢查電源線和電池；筆記本型 Mac 通常會在電池耗盡之前進入休眠狀態(tài)；出現(xiàn)斷電而導(dǎo)致的關(guān)機很有可能是電池或讀取電量的電池控制器有硬件問題，對于 Intel 款 Mac 而言需要根據(jù)官方文檔重置 smc，而 M 系列 Mac 需要手動重啟一次。如果上述步驟依然不起作用的話，也需要進行維修。

長時間未響應(yīng)可能會讓整個系統(tǒng)崩潰，嚴重時還會導(dǎo)致相關(guān)數(shù)據(jù)丟失。定時器超時作為 macOS 中一項功能，它可以有效防止未響應(yīng)的程序?qū)е碌膬?nèi)核崩潰。偶然發(fā)生的 -61/-62 錯誤可能沒什么問題，但短時間內(nèi)出現(xiàn)大量的類似錯誤就要對電腦進行排查了；-61 表示系統(tǒng)認為不能自動恢復(fù)的情況只能進行關(guān)機，而 -62 用于系統(tǒng)確定重啟后可能解決的情況并進行重啟。排查的辦法很簡單，在 macOS 啟動時進入安全模式，在安全模式下啟動項目和守護程序都被禁用；如果沒有再次意外關(guān)機則是最近安裝或更新的程序出現(xiàn)了問題，如果再次意外關(guān)機則和系統(tǒng)本身有關(guān)。

以上就是 macOS 的部分了，相信這個指令可以簡單幫你定位問題，并為你后續(xù)的問題解決打下一個不錯的基礎(chǔ)。

Windows

除了 macOS，Windows 系統(tǒng)日志同樣可以在時間查看器中查看并進行篩選，但考慮界面相對「復(fù)古」且用于篩選的 UI 選項更為復(fù)雜，因此我也更推薦大家使用命令行工具獲取和篩選日志。

如果你的 PC 電腦近期出現(xiàn)了意外重啟等問題，不妨跟著下面的步驟試一試：

# 命令 1
Get-Eventlog -LogName System -Source "User32" | group EventID

# 命令 2
Get-EventLog -LogName System -Source "Microsoft-Windows-Kernel-Power" | Where-Object { $_.EventID -eq 41 }

Get-EventLog 是 Windows 中獲取日志的命令，-LogName System 則限定了查找由系統(tǒng)生成的命令。-Source 則是來源，User32 和 Microsoft-Windows-Kernel-Power 則是兩個不同的來源。

從用戶或程序?qū)用孢M行分析

User32 是一個 Windows 系統(tǒng)應(yīng)用程序源，它包含了許多與用戶界面相關(guān)的函數(shù)，如窗口創(chuàng)建、消息處理、控件操作等等；它還會負責(zé)處理用戶交互方面的任務(wù)，例如鼠標、鍵盤輸入和窗口管理等。因此由用戶或是程序發(fā)起的事件，如登錄、注銷、鎖定或解鎖計算機等，都可以通過 User32 來源來定位。而后 | 用于進一步處理 Get-EventLog 得到的數(shù)據(jù)，這里按照 EventID事件 ID 來group 成組。

目前我電腦中只有 1074 這個事件，這個 1074 事件是計算機的正常關(guān)機的主要表現(xiàn)形式。如果 User32 有其他的 EventID 那么用下面的命令進一步分析：

# 本例中依然用 1074 做分析 
Get-Eventlog -LogName System -Source "User32"  -Newest 1 | Where-Object { $_.EventID -eq 1074} | fl *

前面的命令就不再贅述了，-Newest 1 表示選取最近的一個日志， | 用于進一步篩選 Get-EventLog 得到的數(shù)據(jù)。Where-Object 表示篩選一個對象數(shù)組，$_ 表示當前處理的對象（也就是 | 傳遞過來的數(shù)據(jù) ），.EventID 表示對象的 EventID 屬性，-eq 是一個比較運算符，表示等于，這里等于的 1074 這個事件。| 依然是用于進一步處理 Where-Object 得到的數(shù)據(jù)，由 fl（也可以用完整寫法 Format-List 替代）格式化輸出對象的*所有屬性。

找到其中的 Reason Code: 0x80020010 可以得知這是一個計劃內(nèi)的關(guān)機請求，如果不是服務(wù)器的話，這一般由 Windows Update 自動更新發(fā)起；而由用戶發(fā)起的關(guān)機則會被標識為 0x0。以下是常見的 Reason Code 所表示的含義，完整列表可以參見這里：

藍屏問題導(dǎo)致關(guān)機或重啟，還可以進一步下方的命令進行分析。

從電源管理相關(guān)的事件入手進行分析

不過很多意外關(guān)機的事件，比如藍屏導(dǎo)致的，無法被 User32 捕獲，因此從Microsoft-Windows-Kernel-Power 獲取電源狀態(tài)、電源事件以及與電源管理相關(guān)的錯誤和警告信息得到更多的信息。

Get-EventLog -LogName System -Source "Microsoft-Windows-Kernel-Power" | Where-Object { $_.EventID -eq 41 }

代碼中相似的內(nèi)容不再贅述，在Microsoft-Windows-Kernel-Power和意外關(guān)機有關(guān)的 EventID 是 41，這個事件通常是在意外關(guān)機后重啟的階段中生成的。輸入上面的命令以后，Powershell 會輸出一段包含十進制 BugcheckCode 的內(nèi)容，首先需要將它轉(zhuǎn)換為十六進制，以做進一步分析。

如 159 等同于 0x0000009f，209 等同于 0x000000d1 等等，轉(zhuǎn)換后的十六進制就可以得到最終的含義了。BugcheckCode 內(nèi)容也和藍屏?xí)r輸出的錯誤碼是相同的內(nèi)容，有的時候藍屏代碼一跳而過，所以這也是找到問題的好辦法。以下是常見的錯誤的代碼以及含義，完整列表請看這里：

由于錯誤碼的種類繁多，因此這里不太可能一一列舉。另外還需要注意的是，同一個錯誤可能會有不同的原因而導(dǎo)致，排查時可以從近期的軟件改動入手去尋找電腦意外關(guān)機的原因，排查完軟件以后才是排查硬件的真正時機。

關(guān)于 Powershell 7 使用中的一些細節(jié)

值得注意的是，Get-EventLog只能使用 Windows 內(nèi)的 Powershell 運行；Powershell 7 中因為相關(guān) API 已被棄用，會提示無效指令，因此需要換用Get-WinEvent命令：

# 命令 1
Get-WinEvent -ProviderName 'User32' | group EventID

# 命令 2
Get-WinEvent -ProviderName "Microsoft-Windows-Kernel-Power" | Where-Object { $_.EventID -eq 41}

# 命令 2 改進版
Get-WinEvent -FilterHashtable @{ProviderName = "Microsoft-Windows-Kernel-Power"; Id = 41}

Get-WinEvent 是 Powershell 7 中獲取 Windows 日志的新命令，不同于此前的Get-EventLog能同時篩選具體的事件日志-LogName和事件源-Source；Get-WinEvent在使用時只能在篩選事件日志-Logname和事件源-ProviderName中二選一。Get-WinEvent 還可以使用一個新的寫法 -FilterHashtable，降低命令長度的同時提高索引效率。

以上就是本文的全部內(nèi)容了，希望可以在未來幫助到你。