轉自：http://blog.sina.cn/dpool/blog/s/blog_94a5fb4501016pzt.html?vt=4
通信對象 System.ServiceModel.Channels.ServiceChannel 無法用於通信，因為其處於“出錯”狀態。
Hi,LiPei
這個錯誤好像以前有人遇到過。
如果客戶端代理建立以后，長時間不使用，就會出現出錯狀態，進而無法使用。
你在客戶端調用代理的時候做一個判斷，如果通道出錯，進行重新連接，。或者重新new一個客戶端代理。以前的銷毀掉。
試驗一下 Frank.Xu Lei--謙卑若愚，好學若飢
專注於.NET平台下分布式應用系統開發和企業應用系統集成
Focus on Distributed Applications Development and EAI based on .NET
老徐的博客：http://frank_xl.cnblogs.com
在補充一下：
我在做WCf安全編程的時候，發現也會有這個錯誤：The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in the Faulted state.
原因是我用戶名和密碼錯誤，安全驗證沒有通過，所以直接通到狀態為出錯，不可用。直接調用服務操作會出錯。
你在客戶端調用前，使用wcfServiceProxy.State來判斷一下，是否為Faulted狀態，然后在處理。
這個通道錯誤，目前來說知道的比較常見的原因就是一個是超時，一個安全驗證失敗。
其它原因也許會導致這個錯誤。繼續關注吧~
Frank.Xu Lei--謙卑若愚，好學若飢
專注於.NET平台下分布式應用系統開發和企業應用系統集成
Focus on Distributed Applications Development and EAI based on .NET
老徐的博客：http://frank_xl.cnblogs.com
xu lei，
你好，
我的程序最近又開始報這個錯誤。這個錯誤在我使用IE直接瀏覽時才會出現，當我用VS調試運行時就不會出現這個問題。
我的使用代理的代碼是這樣寫的，請你幫我看看吧。
public static List GetArticleCatalogInfos()
{
using (ArticleCatalogServiceProxy ACSProxy = new ArticleCatalogServiceProxy())
{
if (!enableCaching)
{
if (ACSProxy.State != CommunicationState.Opened)
{
ACSProxy.Open();
}
return ACSProxy.GetArticleCatalogInfos().ToList();
}
string cacheKey = 'ArticleCatalog_GetArticleCatalogInfos';
List ACInfoList = (List)HttpRuntime.Cache[cacheKey];
if (ACInfoList == null)
{
if (ACSProxy.State != CommunicationState.Opened)
{
ACSProxy.Open();
}
ACInfoList = ACSProxy.GetArticleCatalogInfos().ToList();
AggregateCacheDependency acd = DependencyFacade.GetArticleCatalogDependency();
AddToCache(cacheKey, ACInfoList, acd);
}
return ACInfoList;
}
}
做最好的自己
Hi,
不要使用靜態static的方法，這樣連接會再加載類庫的時候就實例化了，長時間肯定通道出錯.~
--------------------------------------------------------------------------------------------
日記：
說明：
①啟動任務時出現了URL不合理的錯誤提示。
②啟動時就會出現在serviceModel中找不到協定錯誤提示。
③從另一方收到未進行安全處理或安全處理不正確的錯誤。有關錯誤代碼和詳細信息，請參閱內部 FaultException。(無法處理消息，因為操作“http://tempuri.org/IMessageService/GetCustInfo”無效或無法識別。)
④在獲取很大數據時會出現傳輸內容要小於配置參數大小，設置MaxReceiveMessageSize和MaxbufferPoolSize屬性為：int.MaxValue大小.r /> ⑤在手工創建服務對象時出現③錯誤提示，如果把綁定類型改成BasicHttpBinding后會出現客戶端與服務器不匹配的錯誤提示。出現這種提示的原因有可能是多種。請見后面說明。
①服務地址必須要加上http://規范的IP地址，因為客戶端綁定服務時會配置服務協議
有多種請見參考。
②服務對象不能在定義成員變量中進行對象實例化。因為在實例化對象時無法找到這個服務對象的地址，這個對象的地址是后台代碼綁定，並不是通過配置文件參數來訪問服務地址的。
③這種現象與⑤這種情況都屬於客戶端與服務器端兩端建立的參數不一樣才會出現這種類似錯誤提示。此項目是如果是手工創建服務對象時，注意：客戶端的配置文件記錄的屬性參數是無效的，此服務與編寫代碼中的終端地址相關聯，如果只是在客戶端更新服務是不夠的，還是將服務發布到手工編寫中的地址，如果沒有發布，保是更改代碼綁定類型，在調用這個服務對象方法時會出現客戶端與服務器不匹配的錯誤提示。
這跟真實需求中對傳輸的性能、質量、事務、安全以及異構的情況有關。
WCF服務編程中有一些介紹。一點理解請參考：
BasicHttpBinding 采用Http/Https協議，Text/MTOM編碼，主要用於與舊的ASMX Web服務協作，但無法傳遞事務且無法使用WS*協議的優勢。
NetTcpBinding 采用Tcp協議, 二進制編碼，支持事務、安全且性能較好。
WSHttpBinding 采用Http/Https協議，Text/MTOM編碼，但可以傳遞事務。
還有其它綁定，如對等網、雙工等，可以參考一些書籍和資料。
這個錯誤的原因，在異常信息里有部分信息：可能綁定不匹配導致的錯誤。
①客戶端和服務器安全模式不同，例如客戶端啟用安全，而服務器沒有啟用安全；
②客戶端和服務器編碼模式不同，導致無法匹配錯誤信息。
③客戶端和服務端SOAP版本不同。也可能導致問題。
④客戶端和服務端事務設置不同等等。