軟體主廚的程式料理廚房

自從 Windows Server 2019 有一次莫名地被重新開機之後，每次登入就會出現關機事件追蹤器的視窗，不堪其擾。

做了 Windows Update 還是一樣，原因不明，不過我找到了三個解法，提供給各位參考。

身為一名程式設計師，打開瀏覽器 Google 一些資料，或是開啟 IDE 寫點程式是常有的事，而當事情做到一半必須被打斷時，「睡眠」這個功能就可以讓電腦在下一次開機的時候，快速地回復到前一次的工作狀態，但是 Windows 10 自從更新了 1903 之後，電腦卻經常在清晨被喚醒，等到我發現的時候，早就不知道運轉了多久、浪費了多少電，甚至直到最近我也更新了 1909，問題依舊還在。

自從更新了 Windows 10 1903 之後，事件檢視器就經常爆出 ESENT 事件識別碼 455 的錯誤，是不影響平常的操作，但是這個錯誤實在太多了，多到整個事件檢視器有三分之二的空間都是這個錯誤，影響到查找其他錯誤的效率。

前些日子開了一台新的 SQL Server，最近從監控當中發現凌晨 02:10 ~ 02:30 之間 CPU 被拉高，日復一日都是相同的時間點。

看起來吃了不少 CPU 資源，由於這段時間嚴格來講並不算是服務的離峰時間，還是希望將珍貴的 CPU 資源留給服務，所以必須查出來到底是誰吃掉了 CPU 的資源？

手上或所處的資訊環境如果有一些舊硬碟，在還堪用的情況之下，應該會希望能持續發揮它的價值直到它生命的最終點，微軟從 Windows 7、Windows Server 2012 R2 開始就內建軟體式的 RAID 功能，有 JBOD、RAID-0、RAID-1、RAID-5 可以選擇使用，已經能滿足大部分的需求了。

Topshelf 這個套件在網路上隨便搜尋，不管國內外都有很多文章在介紹它，我是直到最近才開始跟它有更親密的接觸，利用它我們可以很容易地將 Console 程式 Host 成 Windows 服務，變成 Windows 服務之後我們的應用程式就擁有了透明且可控的生命周期。

在 twMVC#34 聽到一位朋友說他遇到 ASP.NET SignalR 有連線數 11 的限制，由於這位朋友沒有現身，不知道更詳細的情況，我就我之前遇到的情況跟各位朋友分享，ASP.NET SignalR 是會有連線數限制的情形，但這不是 ASP.NET SignalR 的問題。

一直以來，都以為 Windows 工作排程器（Task Scheduler）的重複工作間隔時間最小只能設到分鐘，無意中查到這篇文章，原來不是不行，是我不會。

這個雷我踩了不下三次，寫下來記錄一下，C# 程式要取得當前目錄的方法我們下關鍵字搜尋可以搜出一堆解決方案，沒意外的話第一個搜尋結果通常是 Directory.GetCurrentDirectory 方法(System.IO) - MSDN - Microsoft，但是這個方法在程式是由 Windows 工作排程器（Task Scheduler）啟動的狀況下就不 Work 了。

某個週末公司某個裝在 Windows Server 上的 Redis 服務掛點，從 Server Log 看到下面這段錯誤：

# Write error saving DB on disk: Invalid argument
# rdbSave failed in qfork: Invalid argument
# fork operation complete
# Background saving error

是在 Redis 做 Snapshot 的時候沒有成功，進而影響到服務的運作，Snapshot 會失敗大概會有幾個原因：

1. 記憶體不足
2. 磁碟空間不足
3. 權限不足

現在我們就來看看是哪一個原因？