2009-11-11 119 views
2

我有一個用C#.NET框架3.5編寫的Windows服務,並想知道檢查服務的先前關閉是否正常的最佳方法。檢查Windows服務是否被強制關閉或崩潰

啓動服務後,應該檢查最後一次關機是否正常(通過服務管理中的停止服務按鈕),或者有人剛剛殺死了進程(或者由於某種原因而不是與服務本身直接關聯而崩潰)。

我想過在啓動的服務的硬盤上寫加密的XML,然後用一些值編輯它被停止服務時。就這樣,在我下次再次啓動服務後,我可以檢查XML並查看在關閉期間是否以正確的方式編輯了值,如果不是,我會知道該進程已被殺死或崩潰。

這種方式看起來太不可靠,不是一個好習慣。你有什麼建議?

澄清: 該服務所做的是它位於服務器上並偵聽來自客戶機的連接。建立連接後,它將通過Web服務與遠程數據庫進行通信,並確定它們是否有權連接(並因此使用作爲調用者的應用程序)。保護的一個方面是併發檢查,如果我將限制設置爲5個工作站,我將TcpClient連接從Windows服務保持爲活動狀態,假設有5個工作站,並且第六個工作站無法連接。

如果我殺了服務流程,並重新啓動它,連接都走了,我對工作站上運行5「行貨」的應用程序,現在也有將要採取的5個5個免費的連接插槽。

+0

你爲什麼不能檢查您的WebService? – Arthur 2009-11-12 13:38:44

回答

2

我最後一起去了這裏: 服務用於檢查連接的工作站,看看它們是否還活着,但現在我已經建立了所有工作站的定期檢查(它們通過一個常見的路由器DLL,我已經在檢查中建立)。每10秒連接被驗證一次,如果沒有連接,客戶端將嘗試在15秒內重新連接,如果只是暫時的網絡問題,這將會成功,但如果服務被強制關閉,則會失敗(因爲所有它的Tcp對象將會丟失)。

0

除非服務正在運行一些你需要有一個「篡改」證明系統我不明白爲什麼使用文件是一個壞的解決方案排序securiy系統。

本人來說,我認爲一個encrpted XML文件是矯枉過正,一個簡單的文本文件應該是足夠的。

+0

對不起,我不清楚爲什麼我不認爲只是使用文件作爲標記是個好主意。服務是更高安全系統的一部分,需要防篡改解決方案。 – 2009-11-12 08:35:20

0

我認爲你是在正確的軌道上,我不知道爲什麼你要編輯的值,只需使用文件(或註冊表項)作爲一個標記,以表明該服務已啓動並正在運行。在正常關機期間,移除標記。然後您只需查找標記的存在即可知道您是正常關機還是崩潰。

如果您發現該文件不能可靠地創建,然後確保你正在關閉和沖洗和處理的文件對象的,而不是依靠垃圾收集器。

---編輯以下澄清---

所以要求是許可制度,而不是簡單地判定該服務是否是安全關機。我猜想,希望在正常關機時清除「許可證」,並在崩潰後恢復,這些情況是可以互換的。

我可能會使用數據庫備份存儲和適當的安全性來將許可證密鑰保存在服務器上。當每個客戶端連接並請求許可證時,它們都會提供一個密鑰,該密鑰必須呈現給客戶端的每個通信。服務器顯然正在驗證提供的密鑰對當前會話有效。如果服務器正常關機,它可以清除密鑰表,如果它崩潰,那麼密鑰仍然存在,並可以兌現。這可能是我認爲最安全的最簡單的方法。

如果有尚未更多的故事,然後讓我們知道。

+0

一個簡單的標記可以在定期關閉後被複制,然後在強制關閉後進行替換,這樣服務器在重新開始時看起來似乎沒有任何問題。 對於我在原始文章中未明確的服務功能,我表示抱歉。 – 2009-11-12 09:16:00

1

我會建議使用EventLog。在服務啓動或停止時添加日誌事件,並通讀事件日誌以檢測異常情況。

下面是從CodeProject一個基本的樣本。 這是一個walkthrough from MSDN如何創建/刪除/讀取事件日誌和條目。

+1

感謝您的提示,但我放棄了這個想法。 – 2009-11-12 09:14:21

2

我也無法看到什麼不好使用的文件。你甚至可以使用這個文件記錄更多的信息。

例如,您可以附加到AppDomains Unhanded Exception事件並嘗試記錄該異常。 或者你可以評估你的服務如何運行/不運行(解析該任務的日誌文件有點困難)。

當然 - 這是不是不使用日誌文件的藉口。

+0

這也是檢查違規行爲的好方法,但我最終選擇了不同的路徑。 – 2009-11-12 09:13:31